Everyone Busy, Everything Waiting

The appeal of doing both

“Let’s do both at once. We’ll finish sooner.” It’s a tempting idea. Divide the work across the team, give everyone an initiative and watch several things move forward. Nobody is idle. Every calendar looks reassuringly expensive. Working together on fewer things can look less orderly. People may pair, help outside their specialism or occasionally have spare capacity. That can be uncomfortable when we’ve learnt to judge productivity by how thoroughly we occupy everyone.

So we spread the work and the question is whether more things moving means more things finishing?!

The pieces keep changing

Parallel work can make sense when activities are sufficiently independent and understood. In a busy kitchen, different people can prepare different parts of a meal. They know what they’re making and how the pieces need to come together.

Software often involves discovering those things as we go. One team learns something that changes an assumption. Another continues building on the original assumption. Both report progress. Their work becomes increasingly incompatible. “We’ll bring it all together later”, sounds sensible until later arrives, then it becomes a meeting series.

The risk grows when we separate work that needs frequent shared learning. We create dependencies, delay feedback and leave integration to reveal misunderstandings that nobody could see from their individual piece.

Finish something together

When work is closely connected or uncertain, concentrating the team on a small, useful increment can be more effective. People develop a shared understanding. They notice how their decisions affect one another. They integrate frequently and discover problems while there is still relatively little to undo.

This might look less efficient at the level of individual assignments. Two people might work on one problem. Someone might pause to help a colleague finish. A specialist might have room in their day to respond when needed.

That spare capacity can help work move through the team. Filling it immediately with another initiative may simply create another thing that will eventually need everybody else.There’s a limit to how much progress we can make by increasing the number of unfinished things.

Parallel work needs a reason

The lesson isn’t to put everyone on every task or forbid work happening simultaneously. Some work can proceed independently. Sometimes parallel exploration helps us compare options. The choice depends on dependencies, uncertainty and the cost of bringing the results together. I’d want to understand those conditions before treating an available person as an invitation to start something else. Having an afternoon free is not exactly a staffing emergency.

Things I’d listen out for

• “Everyone needs their own ticket. We can’t have three people working on the same thing.”
• “The integration can wait until both teams have finished their parts.”
• “Since they’re free, they should pick up that chunk of work.”
• “Can we parallelise this? I think we’ll move faster.”
• “Once we get to that point, we’ll pull the pieces together.”

I’d ask how independent the pieces really are, when we’ll test them together and how we will know whether starting more work will help us finish what matters (see Littles’ Law).