Category Archives: Software Development

Some More Management Roles

Agile, Engineering, Organizing Systems, Software Development

A few years ago, I talked about some management roles, specifically how the traditional ‘Team Lead’ role could be de-convolved into five different roles:

Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

At the time, while I’d been running important teams in my organization, it was still a relatively small organization (each CEO knew me by name), so the role and significance of each team was more clear (or at least had been justified by someone before me).

Since then, I’ve learned a little more about what is important in a large organization, and I have some more roles to add. The above management roles have more to do with day-to-day management of a team, and assume that managing upwards and managing long-term are taken care of elsewhere. (Theoretically, they are probably most likely part of the ‘Product Owner’, but most likely they would be part of the ‘reserve power‘, and would devolve to whomever was considered ‘highest’ in whatever organizational hierarchy was present.)

I had also been blessed with excellent technical leads on all of my teams at all of the places I’ve worked, enough so that I didn’t think to explicitly call out ‘Technical Lead’ as one of the ‘traditional’ management roles.

(So now, we have six):

Technical Lead (Software Architecture & Implementation Decisions)
Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

(There are also some questions about the exact line between ‘roles’ and ‘skills, for example: ‘Running a Meeting’ ‘Presenting engaging presentations’), so I will include them for completeness, even though they bleed into many of the other ‘roles’.

As mentioned above, the roles below would fall under some combination of:
– ‘Product Owner’ (because they involve working with people or groups outside/above the team in question)
– ‘Scrum Master’ (because the team would notice that they were blocked or impeded by not paying attention to a certain type of issue, and might be perceptive enough to up-level the discussion to a more general/role-based one)
– ‘Reserve Power’ (roles or tasks that are automatically put under a traditional ‘Team Lead’, but no one really considers them separately, even though they take real time and effort)

Anyways, here are some other longer-term and/or more upward-facing roles to add to the above:

Milestone setter
Team Vision & Planning
Recruiting, Interviewing, & Hiring
Team compositions planning/Team Development (this is development of the team as a whole)
Building relationships (travel, phone, random 1:1s)
Running Meetings
Preparing & presenting engaging presentations
Tech architect (Longer-term decisions about code structure)
Code reviews (this would likely fall under ‘Tech Lead’ above, but ‘what is good enough’ would likely fall under the next line, ‘Quality decision-making’)
Quality decision-making (how good is ‘good enough to ship’?)
Quality Assurance & testing
Asking for resources
Team Champion, in charge of Dog & Pony shows[1] (Why is the work that the team does important?)

Some of the above roles are systematized, automated, or otherwise circumscribed by processes in larger organizations, for example, they may have specific processes for project planning, or for recruiting or development conversations.

But still, there are a lot of these. This suggests that either teamwork is super-complex, and requires too many different things to easily handle without tools[2], or there must be some way of grouping them into meaningful ‘roles’.

So, how do we group them? We could group them into the familiar Agile ‘Technical Lead’, ‘Scrum Master’, and ‘Product Owner’, but that just really puts us back where we started, shoehorning roles into boxes that don’t quite fit, or with a bunch left over.

Fundamentally, all of the above roles are some combination of tasks and making different kinds of decisions.

I’ll do what I can to define, codify, and group them tomorrow.

[1] I am somewhat flip in my naming here, but in any large organization, any team should have a story for how they are planning to remind the management structure of why they are important. This serves a number of functions:
0) The obvious ‘remember who we are and what we do’
1) It’s a good check-in, to make sure that what they are doing is actually perceived as important
2) It’s good practice for the inevitable re-orgs in any large organization, or even if one’s boss changes because they leave for another position or organization

[2] Like checklists, or more advanced tools like JIRA and wikis.

On the Importance of ‘Technical Debt’

Agile, Economics, Engineering, Organizing Systems, Programming, Software Development

A couple of years ago, I was talking with a good friend of mine, we were talking about the difficulties of prioritizing the maintainability of software in a large organization development context.

And so, logically, the concept of ‘Technical Debt’ came up. Interestingly, he had never heard the term before[1], although as soon as he heard it, he grasped the importance.

(I remember it as being a really inspiring conversation, but sadly, my notes from that day don’t well capture what I found so inspiring about it. 🙁 )

Although the concepts of ‘clean up after yourself’ and ‘do it the right way’ are likely as old as human civilization, it was likely only after systems reached a certain level of complexity that the concept of ‘Technical Debt’ was really useful. There is a limit to how complex a mechanical system can get[2], and most other systems are amenable to human factors and psychological safety solutions.

It’s also interesting to think about what is different about software, that makes it: A) possible to make a working product with large (including conceptual) defects, B) Useful to ‘go into debt’ to get a product out the door faster (or more cheaply).

One wonders how much it is the sheer complexity of software systems, the number of interacting modules, or perhaps the number of layers involved, from OS to dev_tools, to language, to standard libraries, to 3rd party libraries, to user-made helper functions. Perhaps it is just that one can ‘go into debt’ in the uppermost layer, because there exists a good foundation.

It could also simply be that software is an automation of so many smaller tasks, that any human system as complex would have similar useful concepts of debt[3].

Doing a little bit of digging, it seems that the concept was first termed ‘debt’ sometime in 1992[4], but it was not until later that it was termed ‘Technical Debt’.

Articulating the concept of ‘Technical Debt’ has a number of important benefits:

1) It puts a name on the category of ‘things we want to clean up in our code’, adds an urgency, and calls out more precisely why this is important.

2) It links the concept of ‘do things the right way’ with ‘Business’ concepts of money. This enables much better CTO-CFO conversations, allows better and more informed project funding decision making, and (hopefully) enables better and more structured funding for Technical Debt reduction[5].

3) It enables conversations in the moment, during architecture conversations and code reviews (and everything in between), where the parties involved can directly weigh/balance the time/resource costs of proper implementation with the opportunity costs of delaying time to market (or MVI/MVP[6]).

It will be interesting to see how organizations (and organizational decision-making) change as this concept spreads from ‘pure’ software companies.

[1] We theorized that this was because he had grown up in Hardware companies.

[2] I am not a Mechanical Engineer, and I’m happy to hear counterexamples, as well the conceptual frameworks used to address this… 🙂

[3] Such as ‘Organizational Debt‘.

[4] https://www.martinfowler.com/bliki/TechnicalDebt.html “As far as I can tell, Ward first introduced this concept in an experience report for OOPSLA 1992. It has also been discussed on the wiki http://wiki.c2.com/?ComplexityAsDebt.”

[5] My favourite label for this is the ‘FBI’ list[7], as in ‘Can you F****** Believe It?’, passed down to me by an executive from a famous Canadian software company.

[6] ‘Minimum Viable Increment/Minimum Viable Product‘, from various implementations of Agile theory.

[7] Things that might linger on a list like this include things filed ‘Too Dangerous to Fix’, which are often interesting memoir fodder.

One Way to Run a Hackathon

Engineering, Internet Culture, Organizing Systems, Software Development

A place that I used to work ran periodic ‘Hackathons[1]’. After trying to describe them to various people it became clear that there were a number of different definitions of what a ‘Hackathon’ could (or should) be, so here’s my description, with some thoughts as to why structuring it this way might be a good idea.

Definition?:
What is a ‘Hackathon’? It’s a lot of different things to different people. Most definitions I’ve seen see it as an opportunity to spend a day (often 24 hours, or a weekend) building something that they wouldn’t normally build. The thing built is not necessarily a ‘thing’. It could be a website, and app, some other type of computer program, it could even be an organization. The important thing here is that whatever is created/built is taken from the concept stage to working prototype with at least some useful feature(s) by the end of the hackathon.

Purpose:
Why do you want to have a Hackathon? The ones that I’ve been involved with were an opportunity for people in a software organization to try something a little different for a day. Some reasons they did it:
– Learning a new skill or programming language by building something ‘real’
– ‘Scratching that itch’, solving some problem that they never quite get the time or priority to solve in their day-to-day
– Working with people that they don’t normally work with
– Building a full product (instead of working on a tiny piece of a huge system)
– Building a visualization tool
– Doing something totally different

Those involved generally seemed to greatly enjoy the experience, the chance to work on something different, to push themselves in a new and different direction, and perhaps the chance to receive the acclaim of their peers.

How did it work?:

There was a committee formed to organize the Hackathon. They were responsible for:
– Publicity
– Getting buy-in from management (this had already happened, so this part was relatively easy)
– Convincing judges to judge the competition (These were usually senior people in the organization who were not part of a ‘hack’)
– Organizing the various parts of the event
– The ‘pitch’
– The presentations
– The prizes
– The voting for the ‘Audience Choice’
– A/V and some method for telling presenters their time was up (we used a stop light)
– Finding sponsors for any ‘Sponsored Hacks’
– All of the various other small things required to run an event like this
– Buying the pizza for the party after the presentations

How often did they happen?
– The Hackathons happened once per quarter, generally in the middle of the week

Schedule:

During the weeks before:
– Publicity, book rooms, perhaps plan food, plan A/V, location, etc.

A couple of days before:
– Run the ‘Pitch Session’
– Provide a place (usually a wiki page) for people to join groups following the pitches

The first day of the hackathon (The hackathon would run noon to noon, with presentations 3-4pm the following day):
– Start the hackathon, giving any support where necessary

The second day of the hackathon:
– Collect presentations, so they can be presented in a timely manner
– Collect the judges, so they can judge the competition
– Run the presentations
– Run the ‘Audience Choice’ vote
– Count the ‘Audience Choice’ votes
– Distract the people with pizza while the judges are deliberating
– Help the judges present prizes

Some more details:

A ‘Pitch Session’ is:
– Each person gets one minute to talk about their idea, in the hopes that they can attract a group of people to work on it with them. There was a rule that teams had to pitch something if they wanted to win ‘best hack’, to encourage them to participate in the pitches and include others

How are teams formed?
– Teams can be of any number of people, but we never saw a team of more than 12 people or fewer than 1 person[2].
– To encourage different parts of the organization to work together, each team would be awarded points for each group represented in the team. Including someone from ‘Customer Experience’ or ‘Marketing’ would be worth three points, while including people from Engineering (the expected default for a hackday) would be worth 1 point
– Teams, once formed are added to the hackday webpage, for posterity, and so people can coordinate (and so the organizers can coordinate collecting all of the presentations)

What happened during the 24-hour Hackathon period?
– During the 24 hours of ‘hacking’, people generally put their project work aside and work on their hacks. Some people were given more or less time to do so, depending on their particular management chain and the urgency of their specific work at hand. Of course, if a production issue cropped up in the middle of the day, that would have priority.

How did presentations work?
– Each team was given 3 minutes to present. Luckily, we had a traffic light that was repurposed to give an easily visible signal to presenters when they were running short of time.
– There was generally an audience, of the other people hacking, the judges, and whoever else wanted pizza later

How were they judged?
– ‘Best Pitch’ (a friend of mine routinely won this part, due to his uniquely hilarious presentation style)
– This was generally awarded based on presentation originality and style
– ‘Most Productizeable’ (Which hack was easiest to productize for customers, either internal or external?)
– ‘Best Hack’ (this is the ‘best overall’ category)
– Not necessarily the one that won any other category, but the best overall
– ‘Best Presentation’
– Similar to ‘Best Pitch’, but generally a higher level of polish (and humour) is expected
– ‘Best Sponsored Hack’
– This is like ‘Best Hack’, but restricted to the specific sponsored category
– Hacks would be graded on the criteria above by the judges, IIRC on a 1-10 scale. (There may have been other criteria which were then rolled up into the categories above. That would be up to any event organizers, should someone wish to take these instructions and run with them.)

How did ‘Sponsored Hack’ work?
– This was a later innovation after some people saw the power of the various hacks that had taken place.
– A person or persons within the company would put up money for prize(s) for the best hack that would fulfill certain criteria. There was one hack to link a system to a particular enterprise solution, and one hack to use a new internal API that had been developed
– There was generally only one ‘Sponsored Hack’ per hackathon, and it was a bidding contest to determine which one would be the official ‘Sponsored Hack
– We found that having super-clear criteria about what constituted a ‘successful hack’ was extra important when the prize money for ‘Sponsored Hack’ greatly outweighed the prize money for ‘Best Hack’

What were the prizes?
– Generally gift cards of some type, glory, and a trophy
– The gift cards would be in the $50-100 range for first place. The glory was the really important part.
– Part of the trophy process was the expectation that each group would modify the trophy in some way before presenting it to the next team at the next hackaton
– We had some issues with one of the sponsored hacks when the prize money reached into the hundreds of dollars, because we had not clearly defined ‘When is a hack good enough to be considered a successful hack?’, and the difficulty of the particular hack

What types of ‘hacks’ did you see?
– There were a number of visualizations of various parts of the system
– There were a number of creative front-end interfaces for various parts of the system
– There was a one-line fix to a bug, in a effort to win ‘most productizeable’ by already being in production
– There was a musical number
– Once, the entire team of interns worked together on a hack
– We had an issue with not being able to tell whether our non-bookable meeting rooms were occupied, so one group made some lights with door sensors to quickly communicate down the hall that a room was occupied or not
– And many others…

Pleaes drop me a line if you want to run one of these. They’re a lot of fun, and can really help people get to know others and build an ‘esprit do corps’ in an organization.

[1]Unrelated: ‘Stupid Hackathons‘, which have a *totally* different ethos…

[2]Even the ‘Automated PowerPoint Presentation’ hack required someone to give the presentation.

How do you Run A Good Retrospective Meeting?

Agile, Organizing Systems, Software Development

I’ve written before about some techniques that I think help to run a good meeting[1].

Recently, I made the decision to delegate[2] the running of most of our team meetings to my reports. Typically, we have daily five[3]-minute standups, bi-weekly Sprint Planning, the occasional brainstorm, and a weekly meeting with stakeholders.

We now do a rotation, with each member of the team (including the interns) running the daily standups and bi-weekly Sprint Planning meetings in turn.

I’ve had to learn some things about delegating, but that’s a story for another post.

For today, I wanted to talk about some of my observations about how to run (what I think is) a good retrospective.

Normally, our retrospective is sandwiched in the middle of our Sprint Planning meeting thus:

1) Adjust any tickets which have changed status since the daily standup[4]
2) Close the Sprint
3) Retrospective
4) Choose a name for the new Sprint (Generally the most difficult[5] part)
5) Add items to the new sprint, prioritizing and estimating as we go[6]

It wasn’t until I watched others running a Retrospective that I understood a lot of the small things that I do that make a difference.

The (way I see) steps to a Retrospective are as follows:

1) The Facilitator draws the visualization[7] to start people thinking:

The facilitator writes something akin[8] to the following diagram on the board:

  
  Went Well       Not So Well
*---------------*----------------*
|               |                |
|               |                |  In Our Control
|               |                |
*---------------*----------------*
|               |                |
|               |                |  Not In Our Control
|               |                |
*---------------*----------------*

The point of this is to help the group think about and distinguish things that are in their direct control and out of their direct control. Many groups will come up with a definition for this after their first argument, often placing the line of ‘direct control’ at the edge of the group in the meeting/team in question. There are also many ways to write ‘Not So Well’, which I won’t get into, except to say that I prefer the hopeful phrasing. 🙂

Overall, you can think of your group process as bringing issues from ‘Not So Well/Not In Our Control’ to ‘In Our Control’, then ‘Went Well’, then noting new issues and starting the cycle again. We had one retrospective a while back where basically everything was ‘Went Well/In Our Control’, or ‘Not So Well/Not In Our Control’, so we ended up brainstorming ways to get things under our control, or at least influence, so we could fix them.

It’s not necessarily the worst thing in the world if most items are in the ‘Went Well/In Our Control’ category, but this may also mean that there are underlying issues that you may need to ferret out in your one-on-ones (You *are* having one-on-ones with your team, right?). One such issue came up recently in a one-on-one, and when it was brought up in the Retro., I hijacked the meeting for half an hour to have a specific brainstorm on that topic, to make sure it was covered in depth.

2) The facilitator asks the team to write things went well or did not go well on sticky notes and to put them on the board:

Each member of the team writes happenings from the past two weeks on sticky notes and posts them on the diagram. We use standard-sized sticky notes, and sharpies, so that the notes can be (mostly) read from across the room. My understanding of why this is done with sticky notes is so that people feel some measure of safety and anonymity, and therefore are more likely to express what they really think.

When running this part, I ask people to think along process lines. It’s helpful (and sometimes nice!) to talk about the fact that a particular project went well or poorly, but it’s often more helpful to talk about the parts of our process or other teams’ process that affected the outcome. Identifying process issues and fixing them is what really makes the difference here.

3) The facilitator clarifies each of the posts:

In some order, the facilitator goes through each (group of) post(s) and invites the author to clarify anything ambiguous, such that the whole group understands what each post means (often caused by my handwriting… :/ ). This should only take a few minutes. As they go, the facilitator will often do step 4). Along the way, some problems may be resolved simply by bringing them up, but some may require more thought/brainstorming. Those conversations are shelved until a later step by the facilitator.

As far as ordering, we generally talk about what went well first, probably for psychological safety reasons.

4) The facilitator de-duplicates the posts:

This is more of an art than a science. In some serious brainstorms, the facilitator will call a break at this stage, because it is non-trivial to get correct, while being quite important.

The goal is to group the posts into groups that are likely to have similar solutions. I don’t have good advice here, but it is often a good call for the facilitator to ask the group if two things go together, if they seem to sound similar. More insight on this will come with experience[9].

5) The facilitator decides whether to continue:

The facilitator decides whether any of the posts require a more in-depth conversation. This will likely have become obvious in step 3). You can always check in with the group, if you’re unsure.

6) The facilitator invites dot voting to determine the order for further discussion:

If there are multiple items to address, the facilitator invites the team to come up and ‘dot vote'[10] on which items they think are most important. A good number to choose seems to be 1/3 to 1/2 the number of items to be voted on. If people complain about the number of dots, you can change this, or remind/tell them that they can put multiple dots on items.

7) The facilitator counts the dots and orders the items in dot priority order from highest to lowest

8) The facilitator brainstorms solutions in descending priority order:

Starting with the item which had the most dots:
a) Make sure everyone understands what the issue is. If this is really unclear, you can brainstorm a list of ideas to try to get to the root cause[11].
b) Brainstorm solutions. Some of these will have obvious actions and owners. For things which are not so obvious, you may want to dot vote again.
c) Make sure you clearly write down (and perhaps make into tickets) any actions which arise.

d) Continue until no items with dot votes are left, you run out of time, or your group becomes unengaged.

That’s it! You’ve now run your first Retrospective. Let me know what you think in the comments below!

[1]Wow, I write a *lot* about meetings…

[2]Stay tuned for a post about ‘Power to the Edge’!

[3]Our daily standups are trending to the long side these days, perhaps up to 10 minutes, but people seem to find them useful, specifically the conversations to solve problems that can more easily be initiated when you know people are already interrupted.

[4]It’s always nice when people update their tickets as they’re doing things, but it’s not necessary. We’ve had success with doing it in our daily standup.

[5]I am not joking. Try it with your team and see for yourself. I went to an auction at a gaming convention during my youth, and the item which went for the largest amount of money was a book to assist people in making character names. Making good names is *difficult*.

[6]’Just-in-time’ planning. This also feels like a separate topic for a post.

[7]This is a whole topic. I like this particular visualization, but you could see that many others could work just as well. The following [8] is another.

[8]There are a number of ways to draw this. It’s sometimes good to change it up, to help people think about things differently. Another popular diagram is a ‘speedboat’ diagram, with wind, anchors, obstacles, and goals as the four categories. It’s not an exact mapping to the above, which has it benefits and drawbacks.

[9]I should write about this, too.

[10]’Dot Voting’ is where you give each person a number of ‘dots’ that they can place on the things they’re voting on. In this context, we use it to choose which thing(s) to talk about next. Some people insist on only one dot from each person per topic, some are more flexible.

[11]’Getting to the root’ in a Brainstorm is a really interesting topic. It’s non-trivial, and deserves its own write-up.

Interview Questions: Types of Coding and Algorithm Questions

Machine Learning, Organizing Systems, Programming, Software Development

Part of a continuing series on Interviews and Interview Questions.

Today, we’re going to look at types of coding and algorithm questions. As discussed before, these can be divided up into ‘Problem Solving’ and ‘Knowledge’ questions.

As mentioned before, ‘Knowledge’ questions are very close to ‘human glossary’ questions. ‘What is the Big-O order of QuickSort? Average case? Worst case?’.

But there are some questions which straddle the line between knowledge and problem solving, answers that few but an expert in that topic would be able to exactly recall, like ‘what exactly happens between when you type google.com into your browser and the page appears?’, or ‘compare and contrast various sorting algorithms’.

For those questions, you have to be as widely read as possible, they tend to select for those who are more naturally inquisitive for things outside their specific area of expertise.

Now, for coding questions. There seem to be a few different types, which I’ll try to separate out by data structure[1]:

Arrays and Strings – Any data structure where any element is addressable in O(1) time, where elements are allocated together in memory.

Linked Lists, Stacks, and Queues – Data structures in linear form, where elements far away from the origin are O(N) difficult to access.

Trees – Data structures arranged in a tree form, with a clear root and directionality. Often sorted.

Graphs – Data structures with nodes and edges, where the edges can connect the nodes in arbitrary ways. Home to at least the plurality of the known NP-Complete problems. Note that Graph problems are a superset of the above.

Search and Optimization – Problems where you’re trying to find an optimal (or close to optimal) solution in a large multidimensional tensor or vector field. Many in this category are easily mappable to Graph Theory questions, but many are not, such as 3-D Protein Structure Prediction. Most interviews would likely not ask questions in this category, at least not very complex ones.

Machine Learning and Statistics – Somewhat related to Search and Optimization, problems dealing with how one trains a computer to solve a problem. Likely to become more and more important.

Hashes – Data structures where space is traded for speed. Generally assumed to have 0(1) insertion and retrieval

[1]Hat tip: developer.com

Interview Questions: Behavioural and Situational

Agile, Organizing Systems, Software Development, Thoughts on Thoughts

Balancing factors. Persuading people.

Yesterday, I talked about three types of interview questions:

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.

‘Situational’ questions ask ‘Given this situation, how would you solve it?’

‘Technical’ questions ask ‘Solve this defined problem for me.’

Today, I want to talk about the ‘Behavioural’ and ‘Situational’ questions.

First, how are these questions similar?

Both of these are asking you to describe a solution to a problem, a problem from a surprisingly narrow set of options.

Two (or more) factors that you need to balance[1].

Helping people work together when they disagree[2].

The two factors might be technical, like how you would balance ‘Reliability’ and ‘Performance’, or they might be human, like Legal disagreeing with Marketing. Already, you can see these options blurring together. Really, these questions are really asking about how you balance things and make decisions.

The follow-up is often ‘So, once you made this decision, how did you implement it? How did you convince people that this was the correct route?’

Balancing factors. Persuading people.

So, how are these questions different?

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.

‘Situational’ questions ask ‘Given this situation, how would you solve it?’

‘Behavioural’ questions ask you to tell a story about something you’ve done. You want to look at all the things you’ve done (especially everything you put on your resume), and think about what kinds of problems each of them were. What factors were you balancing there? How did you persuade people to work together and solve the problem?

An interviewer may ask you this question from a number of different directions. It’s up to you to fit one of your stories into the narrative question they’ve created (or to rephrase it such that your story fits).

‘Situational’ questions ask you how you would solve a hypothetical situation. An interviewer would present a situation with multiple factors to balance, where people disagree, and you would need to mediate, make a decision, get buy-in for your decision.

In this case, it again can be calling on your experience, but be careful that you’re actually trying to solve the problem presented, not a different problem that you’ve encountered before[3].

Summing up:

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.
‘Situational’ questions ask ‘Given this situation, how would you solve it?’

In both of these:

Balance factors.
Persuade people.

To answer:

‘Behavioural’, fit a story from your past into the question.
‘Situational’, put yourself into their story, and tell them how you would resolve it.

Next time, we’ll look at the more ‘technical’ side of interviews. Stay tuned!

[1]If you didn’t need to balance between two things, you would just choose one of them, and really, no decision is required.

[2]If people are in agreement, what decision is required?

[3]Or something from your childhood, natch.

Mastery and Starting Anew

Organizing Systems, Software Development, Thoughts on Thoughts

Earlier, I had written about the new flows and new structures which confront you whenever you change jobs or organizations.

Today, I was reading an article about feelings of ‘mastery’ (and actual ‘mastery’), and how they vanish when you change careers.[1]

Interestingly, it ended up becoming a story about transferable skills, and how you develop blind spots as you become entrenched in your 10-year or 20-year (or more) career.

For me, I discovered that I had learned how to look at a software project, see the flow, find the risks, and then work to route around and/or mitigate them. Perhaps more relevantly, I found this was an uncommon skill. Interestingly, being new and not knowing the project in as much detail probably helps me more easily see the bigger picture.

I haven’t noticed any new blind spots, but I’ll continue to watch. (I also try to ferret them out whenever I see them in myself, but I have no idea how well I do at that.)

In the article, the author says:

”
In radio, information is not your goal. Someone can talk and talk and talk, but unless they talk in the right way the tape is useless to you. If they are distracted, or overly theatrical, it won’t work. (That was the problem with the first oil guy we interviewed: he was always putting on a show.) The aim is to get them to relive all the emotions they felt at the time, which will translate in their voice. This can be achieved only if you are patient and open, and take the time to establish a real connection.
”

about how she learned to give people space in an interview, to help them stop ‘putting on a show’ and actually express their inner emotions.

For me, this quote best captures why I think changing things up can be such a powerful tool:

”
Then there’s the larger matter of how you practice. In “So Good They Can’t Ignore You,” author Cal Newport says that what makes ridiculously successful people so successful is they’re experts at practicing — they can push themselves to the exact limit of their skillset and thus expand their abilities day after day. If you’re not expanding yourself in such a fashion — called deliberate practice in the org psych lit — you’ll never be ridiculously successful.
”

[1]For those who have not heard of the ‘10,000 hour rule’, it’s from Malcom Gladwell’s book ‘Outliers’. There are also some who dispute the magnitude of the importance of the rule.

New Job, New Flows, New Structures

Agile, Idle Speculation, Organizing Systems, Software Development

So you’re moving to a new organization. You know that what you will be doing will be different, you may even have read up on it.

But there are going to be all kinds of unexpected differences, and they’re likely going to come from the most unexpected directions.

Each organization has its own flows (I’m going to talk about software, as those are the flows I know best).

When an organization is writing software, there is generally some sort of version control-coding-testing-release pipeline. However, there are many different pieces of helper software for each of these steps.

There’s the flow of information as clients are using software. Information supplied by the clients, information supplied by your organization, and these all have to work together smoothly to solve whatever the client’s problem is.

The way that feedback from clients is turned into actionable items can be vastly different between organizations.

On the transition line between flow and structure, the way that teams are divided often reflect historical decisions made in antiquity, often the division of labour of the first few people writing the code for the first iteration of the product.

Information will be flowing through this system while the software is running, effectively handing off from team to team.

There will be structured and unstructured information flows in the organization. Many people are at their most effective when they receive all of their new information before it arrives through official channels.

Even the structured flow of information can be very different, for example in a very flat organization such as Valve.

So, be mindful, and watch for the different flows. You may be surprised at how different each organization is (or how similar).

What do Numerical Software Development Estimates Actually Mean?

Agile, Organizing Systems, Software Development

What do numerical software development estimates actually mean?

What do they mean for you?

(I’m talking especially about team-based estimation, such as that in ‘planning poker‘, but I’m guessing whatever conclusions we may have would hold for other methodologies.)

I see the general objective here as coming up with a number for each task, and a number for how much your team can typically do in an amount of time, such that these numbers are reasonably fungible.

Traditionally, estimates would be given in ‘programmer days’, or ‘wall clock time’, depending on whether you had read ‘The Mythical Man-Month‘ or not[1].

More recently, there has been a back-and-forth between ‘amounts of time’ and some sort of dimensionless unit called ‘complexity points’.

Various teams that I had been a part of struggled with ‘complexity points’. In their strictest definition, something which was simple and repetitive would be worth few ‘complexity points’, even though it would take many hours of some attention or nursemaiding to finish the task.

Strict ‘amounts of time’ are no better, because each person does each task at a different rate.

We had the most success with ‘relative complexity’, or taking some small and large tasks, assigning them numbers, then rating each of the other tasks with respect to these goalposts.

Even this has its limitiations, though. Fundamentally, they question you’re asking when you’re deciding to put something into a sprint is ‘can we still accomplish everything if we include this?’. Because of limiting reagents (specific people who are bottlenecks for many tasks) and interdependence between tasks, this can be problematic. The standard way of getting around this is to insist that all tasks are independent and small.

This worked reasonably well, it’s just that sometimes you need to rewrite or refactor an entire application.

What are your experiences? How have you dealt with this question? How many points would it be worth to research and present on this topic?

(This post came out of a fb conversation with D about what estimation numbers mean, and have meant at various times.)

[1]One of the upshots of this is an observation made by someone at work (I think F) which was that Gantt Charts are excellent for deriving dependencies, but terrible for estimation.

New Divisions of Five Management Roles

Agile, Idle Speculation, Organizing Systems, Software Development

Yesterday, we talked about five management roles:

Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

In a traditional corporate structure, these five roles are combined in one person (your boss).

However, there are many ways to divide these roles, and many reasons to do so (the simplest being that different people are good at different things).

Valve famously has an incredibly flat structure, where each person has a set of peers (the rest of the company) who handle performance management, and all of the rest of the roles are performed by each person themselves. As they say, occasionally teams will form with people splitting off into roles, but that’s all dynamically allocated by the people involved.

Your standard ‘Scrum‘ Agile shop will tend to put the ‘Performance Management’ and ‘Development Management’ into a ‘People Manager’. ‘Estimation’ is done by the team as a whole, the ‘Scrum Master’ or ‘Obstacle Remover’ is traditionally not the people manager, but is a separate role. The ‘Product Owner’ can be the ‘People Manager’, or someone else, sometimes an external product or project manager, but is generally not the same person as the ‘Scrum Master’.

I would argue that this tension between prioritization and removing obstacles is one of the reasons the system works better than many.

There seems to be a growing trend to separate Performance from Development[1], with some companies having separate reviews in different parts of the year for each of these. This can be especially helpful as many people are unlikely to be relaxed enough to think about how to take beneficial risks in the future when they’re tied up in knots about whether their boss wants to fire them.

I think it might make sense to push this to its logical conclusion, and have separate people for these separate roles in a company. The ‘Development’ role feels almost like a traditional HR thing, but I feel like to best serve employees, it would really need to be a separate department, called ’employee growth’ or something similar.

What do you think? What have you heard about how different organizations split these roles? How do you think they should be split?

[1]Development as in ‘where is your career going?’