Why Busy Teams Are Slow Teams
Utilisation and speed are opposites past a certain point. This is the queueing argument that explains why adding people to a loaded system makes everything later, and what to do instead.
There is a conversation that happens in almost every delivery organisation, usually in the third week of a slipping quarter. Someone senior observes that the teams look busy. Everyone is working hard, the boards are full, nobody is idle. And yet things are arriving late. The conclusion drawn is almost always that there is not enough capacity, and the remedy is almost always to add people.
This is the single most reliable way to make a late programme later.
The reason is not motivational, cultural or managerial. It is arithmetic. Knowledge work is a queueing system, and queueing systems have a property that is deeply unintuitive to anyone who has spent a career thinking about resource efficiency: as utilisation approaches one hundred percent, wait time approaches infinity. Not linearly. Asymptotically.
The shape of the curve
Consider a road. At twenty percent occupancy, adding a car changes nothing — everyone still travels at the speed limit. At sixty percent, adding a car slightly slows things. At ninety percent, adding a single car can collapse the flow of the entire carriageway into stop-start crawling. The relationship between how full the road is and how long your journey takes is not a straight line. It is a hockey stick, and the elbow sits a lot lower than people expect.
Software delivery behaves the same way, with one additional cruelty: the variability in knowledge work is far higher than the variability in car lengths. Two stories that look identical at planning can differ by an order of magnitude in effort. High variability moves the elbow of the curve further to the left. In practice, this means a team running at what looks like a comfortable eighty-five percent loading is already deep into the non-linear region.
Where the time actually goes
Map a single piece of work from the moment it was accepted to the moment a customer could use it. Mark every period where somebody was actively working on it, and every period where it was sitting in a state waiting for something — a review, an environment, a dependency, a decision, a release window, another team's sprint boundary.
Almost nobody does this exercise and likes the result. In most organisations that have not deliberately attacked the problem, the ratio of touch time to elapsed time — flow efficiency — sits somewhere between five and twenty percent. Which is to say: the overwhelming majority of the calendar is queue.
This reframes the entire improvement conversation. If a change takes nine weeks to reach production and only four days of that is work, then making the work twice as fast saves you two days out of sixty-three. Making people type faster, hiring more of them, or exhorting them at a town hall is an intervention aimed at the smallest term in the equation.
The large term is the waiting. And waiting is created by structure: how much work is in flight at once, how many handoffs a change must survive, how big the batches are, and how many queues a change must pass through before it counts as done.
Why adding people makes it worse
Three mechanisms, all of them well understood and all of them routinely ignored.
Onboarding consumes the scarce resource. The people who can ramp a new joiner are the same senior people who are currently the constraint. For the first few months, new capacity is negative capacity.
Communication paths grow quadratically. A team of five has ten pairwise channels. A team of ten has forty-five. Coordination cost does not scale with headcount; it scales with headcount squared, which is why splitting into well-bounded teams matters far more than the raw number of people.
More people means more work in progress. This is the decisive one. New people are given work so that they are not idle. Work in progress rises. Every item in flight competes for the same review capacity, the same environments, the same deployment windows. Cycle time rises for everything, including the items that were already nearly finished.
Little's Law states the relationship plainly: average cycle time equals average work in progress divided by average throughput. If throughput is capped by a constraint you have not addressed, then increasing work in progress increases cycle time proportionally and delivers nothing. You have not bought speed. You have bought a longer queue with more expensive people standing in it.
The counter-intuitive intervention
The fix for a slow system is usually to put less work into it.
This is close to unsayable in most corporate environments, which is precisely why it remains available as an advantage. Reducing work in progress produces an immediate, measurable drop in cycle time with no change to team composition, tooling or process ceremony. It is the cheapest intervention in delivery management and the least frequently attempted, because it requires someone senior to say "we are not starting that yet" and mean it.
Three moves, in order of how quickly they pay back:
- Cap work in progress explicitly. Per team, per state, per person if necessary. When the cap is hit, the rule is to help finish something rather than start something. This will feel wrong for about two weeks and then feel obvious.
- Attack the biggest queue, not the biggest team. Find the state where items sit longest — usually code review, environment availability, or an approval — and fix that one. Everything downstream improves for free.
- Shrink the batch. Smaller changes move through queues faster, fail less catastrophically, and are cheaper to diagnose when they do fail. Batch size is the lever with the widest reach, and it is covered in its own article.
What this looks like as a measurement
Stop reporting how busy people are. Start reporting these four, weekly, per team:
| Measure | Definition | What a bad number looks like |
|---|---|---|
| Work in progress | Items started but not finished | Rising while throughput is flat |
| Cycle time | Start to done, per item, as a distribution | A long right tail, not a bad average |
| Throughput | Items finished per week | Flat or falling as headcount rises |
| Flow efficiency | Touch time ÷ elapsed time | Below fifteen percent |
Note the phrase as a distribution. Reporting an average cycle time hides exactly the information you need. What matters for forecasting and for customer trust is the eighty-fifth percentile — the number you can actually promise against. Averages are a summary of the past; percentiles are a commitment you can keep.
What to do on Monday
Pick one team. Count the items currently in flight. Divide by the number of people. If the answer is greater than one, you have found your first intervention without needing a consultant, a framework or a tool.
Then set a cap at roughly two-thirds of the current number and hold it for four weeks. Measure cycle time before and after. In our experience this single change produces a larger improvement in delivery predictability than any ceremony redesign, tooling migration or reorganisation that could be attempted in the same period — and unlike those, it costs nothing and can be reversed on a Friday afternoon.