Coordination cost
A Socratic walk-through of coordination cost — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why does adding people to a project that is already late often make it later?
The instinct barely feels like a decision: the project is behind, so put more people on it. Work is work; hands are hands. And yet the claim attached to this move — Fred Brooks's, in The Mythical Man-Month in 1975 — is that adding people to a late software project makes it later. Not "helps less than you hoped". Later.
That is a strong claim, and it cannot be true of everything: digging a ditch goes faster with more diggers. So what is different about the work where it holds?
Reasoning it through
REASONING #Ask first what the new arrival does on day one. Not the work — they cannot yet. They ask questions, and the people answering are precisely the people who were producing. So the immediate effect of adding a person is to remove part of an experienced person for a while. That alone is only a temporary dip, and if it were the whole story you would pay the dip and come out ahead. Brooks's point is sharper: on a late project the remaining time may be shorter than the dip.
Now the second effect, which does not go away. Count the connections. Two people have one relationship to maintain. Three have three. Ten have forty-five, since each of ten pairs with nine others and each pair is counted twice — ten times nine, halved. Twenty have a hundred and ninety. Fifty have one thousand two hundred and twenty-five.
Sit with the shape of that. Going from ten people to twenty doubles the hands, but takes the pairs from forty-five to a hundred and ninety, more than four times. Work done grows at absolute best in proportion to headcount; the number of ways two people can hold incompatible assumptions grows with the square of it. Somewhere those curves cross.
Be careful, though, because the formula is an upper bound on possible channels, not a measurement of what anyone experiences. Nobody on a fifty-person project maintains twelve hundred relationships; they would get nothing else done. Organisations respond by cutting channels — teams, interfaces, documented contracts, a designated point of contact — and they pay for the cutting in meetings, documents, slower decisions, and the errors that come from people acting on a version of the plan that has moved. Read n(n-1)/2 as the pressure the structure has to absorb, not as the cost itself.
Now the third and deepest effect. Some work partitions and some does not. If a task splits into independent pieces with clean boundaries, extra people work in parallel and coordination stays small — this is the ditch. If the pieces interlock, every division creates an interface, and every interface is an agreement two people must keep in step as both sides change. Brooks's line for the extreme case is that bearing a child takes nine months however many women are assigned.
Put the three together and the paradox dissolves. Adding people costs training time now, adds coordination load permanently, and helps only in proportion to how divisible the remaining work is. A late project is typically late because what remains is the tangled, interdependent, sequential part — integration, debugging, reconciling — which is exactly the part that partitions worst. The help arrives where it cannot be used and the cost arrives everywhere.
The analogy
THE ANALOGY #Think of a small kitchen at the height of service. One cook is behind, so you send in four more. They need to be told where things are, they need the same counter, and each new plate now has to be checked against what the others are doing so that the same table's dishes arrive together. The chopping — the part that splits — goes faster. The plating, the timing, and the single pass window do not, and they were the bottleneck.
A kitchen's constraint is physical and visible, so everyone can see that the pass is full, whereas a project's coordination load is invisible and shows up only as vague slowness — which is precisely why the mistake keeps being made by people who would never crowd a kitchen.
Clarifying the model
THE MODEL #Now the honesty this topic badly needs. Brooks's law is a heuristic drawn from one man's experience of one very large project — IBM's OS/360 — written up in an influential book. It is widely believed and only partly studied. The empirical work that exists, including simulation studies and a small number of field investigations, broadly supports that late additions can hurt, but finds the effect depends heavily on when people are added, how much they already know, and how modular the work is. It is not a law in the sense that a measured relationship is a law, and Brooks himself later called it an "outrageous oversimplification" while standing by its direction.
Two consequences follow. A counterexample is not a refutation: a project where new people helped is usually one where the remaining work partitioned cleanly, or where the additions came early enough to repay their training. And the practical lever is rarely headcount at all. If the coordination term is what hurts, the useful moves cut channels — smaller autonomous teams, stable interfaces so people work against a contract rather than against each other, decisions written down so they need not be transmitted person to person. Brooks's own proposal, a small "surgical team" with one designer and supporting specialists, is a channel-cutting design rather than a staffing level.
A caution on the arithmetic, too: n(n-1)/2 is exactly right about pairs and says nothing directly about hours.
A picture of it
THE PICTURE #How to readThe bars are the number of distinct pairs on a team of that size, n(n-1)/2, and the line is simply the headcount, plotted on the same axis so the two can be compared directly. Read left to right and watch the gap open: at three people the bar and the line are the same height, at ten the bar is already four and a half times the line, and by fifty the line has flattened into the axis. The line is the best case for how much work gets done; the bars are how many ways two people can be out of step.
What became clearer
WHAT CLEARED #Adding people buys capacity that grows at best in proportion to headcount, while paying a coordination cost that grows with the square of it and a training cost that lands immediately. On a late project the remaining work is usually the interdependent kind, so the capacity cannot be spent and only the costs land. The real question is never how many people, but how cleanly the work divides — and the useful interventions cut the number of connections rather than add to the number of hands.
Where to go next
ONWARD #- Conway's law: why a system's design tends to mirror the communication structure of the organisation that built it.
- What actually distinguishes partitionable work from the tangled kind, and whether it can be designed for in advance.
Key terms
TERMS #| Term | What it means |
|---|---|
| Brooks's law | the heuristic that adding manpower to a late software project makes it later. |
| Communication overhead | the effort spent keeping people's understanding of the work aligned, which grows faster than headcount. |
| Partitionable work | work that divides into independent pieces with few interfaces, and so does speed up with more people. |
| Ramp-up cost | the output lost while experienced people bring new arrivals up to speed. |
Every term the collection defines is gathered in the glossary.