The Coordination Tax
Thirty two people finished a 100,000 line system six days faster than four people did. It cost seven times the labour and shipped five times the defects. This paper works through why the cost of a team grows faster than its output, why the real risk in a software budget hides in a fat tail that averages conceal, and what we build instead of a big team.
Every proposal you have ever received answers the same question. How many people can we put on this?
It is the wrong question, and the industry has had the evidence for forty years. We keep asking it because headcount is the only variable a buyer can see, the only one a vendor can invoice, and the only one that makes a slide look serious. This paper is about what that question actually costs, and about the number that replaces it.
1. Eight times the team, six days sooner
In 2005 the software measurement firm QSM went through 564 information systems projects completed since 2002 and pulled out the ones that were roughly the same size, near 100,000 equivalent source lines of code. Then they split them by how many people had worked on them.
The small teams averaged four people. The large teams averaged thirty two.
The small teams finished in 9.12 months. The large teams finished in 8.92 months.
Six days. Eight times the headcount bought six days.
Then the bill arrives. The four person teams spent 24.5 person months of effort. The thirty two person teams spent 178. Same system, same quarter, seven times the labour. At a blended rate of ten thousand a month that is the difference between a quarter of a million dollars and one point eight million, and the expensive version shipped five times as many defects.
Nobody in that data set was incompetent. The large teams were not full of bad engineers. They were full of ordinary engineers in a structure that spent their time on each other instead of on the software.
2. The mechanism is arithmetic, not culture
Fred Brooks published the explanation in 1975 and people still quote it as folklore rather than as maths. In a team of n people, the number of pairs who may need to reach agreement is n(n-1)/2.
Four people have six such pairs. Thirty two people have 496.
Eight times the people. Eighty two times the connective tissue.
Output, meanwhile, is linear at absolute best. One more engineer writes at most one more engineer's worth of software. So you are buying a linear gain with a quadratic cost, and the only question is where the two curves cross. QSM's answer, across four separate studies spanning two decades of their database, is that the crossing happens embarrassingly early. Teams of three to seven people delivered the best results on medium sized systems. Past nine, the effort curve stops behaving.
None of this is about talent, motivation, or how good your standups are. Every link in that mesh is a place where a decision has to be explained a second time, a context has to be rebuilt in somebody else's head, an assumption has to be checked because two people quietly held different ones. A well run large team is a large team that pays the tax gracefully. It still pays it.
Coordination is not the price of building software with other people. It is most of the price.
3. The average overrun is the least interesting number
Bent Flyvbjerg and Alexander Budzier at Oxford analysed 1,471 IT projects and found an average cost overrun of 27 percent. Read as a single figure, that sounds survivable. Budget a third more and sleep well.
The single figure is a trap. One project in six in their sample was what they called a black swan: an average cost overrun of 200 percent and a schedule overrun of nearly 70 percent. The distribution has a fat tail, which means the average tells you almost nothing about your exposure. You are not signing up for 27 percent. You are signing up for a lottery in which roughly seventeen tickets in a hundred triple your budget.
The larger study points the same way from a different angle. McKinsey and the University of Oxford looked at more than 5,400 IT projects and found that large ones ran 45 percent over budget, 7 percent over schedule, and delivered 56 percent less value than predicted. Seventeen percent went badly enough to threaten the existence of the company running them.
Sit with the shape of those three numbers, because it is the most useful sentence in this paper. Budget blows out by 45 percent. Schedule slips by only 7 percent. Value collapses by 56 percent.
That is not a project that ran late. That is a project that defended its date by throwing people and money at it, and then quietly shipped something thinner than the thing it promised. Section one measured exactly that trade in a controlled way. Section three is what it looks like when it happens to you at scale, in public, with your name on the contract.
4. What a system actually is
We say the industry does not lack talent, it lacks a system, and it would be fair to ask what that word is doing.
A system is the set of decisions you do not have to make again.
That is the whole definition. Every decision a delivery organisation has already made, written down, and made unavoidable is a decision that never again consumes a meeting, never again gets made differently by two people in the same week, and never again shows up as a defect six weeks later. It removes links from the mesh in section two. That is the only lever that actually moves the numbers, because the alternative levers, working harder and hiring more, are the ones we just watched fail.
Concretely, a system is: how work is broken up, who is allowed to decide what, what has to be true before a stage is called finished, how a change of mind is priced, what gets automated so nobody has to remember it, and who is on the hook when it goes wrong. Most firms have opinions about these things. Very few have answers that survive a Tuesday afternoon.
5. Small units, thin seams
If coordination cost is quadratic in team size, there is only one way to build something bigger than four people can build. Do not grow the team. Add another team, and make the seam between them narrow enough to describe on one page.
Take twenty four people. As one team, that is 276 possible pairs. As four pods of six with the pod leads coordinating, it is fifteen pairs inside each pod, sixty in total, plus six between the leads. Sixty six.
A quarter of the connective tissue, same headcount. The saving is not free and we should be exact about where it comes from: it comes from the interface. Every seam between pods has to be a real contract, an API with a schema, an agreed data shape, a signed off design, something that can be checked by a machine or by a gate rather than by a conversation. If the seam is vague, the links come straight back through the side door and you have all of the overhead of separate teams and none of the benefit.
This is also why we cap what one pod owns rather than capping what a client can buy. A pod that is asked to hold six unrelated products is a large team wearing a small team's name.
6. What this costs us
Three honest disadvantages, because a paper that lists only upside is marketing.
Small units absorb shocks badly. If scope doubles in week three, a thirty person team reshuffles and a six person pod stalls. We handle that by pricing change explicitly instead of pretending it will not happen, which some buyers experience as inflexibility.
Seams need an owner. The interface between two pods belongs to nobody by default, and by default nobody maintains it. Somebody senior has to hold the architecture across pods, and that person is expensive and hard to replace.
Small teams concentrate key person risk. Four people who know a system well are four people, and two of them leaving is a real event. The countermeasure is documentation discipline and paired ownership, both of which cost real hours that a buyer never sees on a feature list.
We think that trade is obviously worth making. We would rather say what it is than pretend it does not exist.
7. What to ask a vendor instead
If headcount is the wrong question, here are five that are not. Every one of them is answerable in a sentence by a firm that has a system and answerable only in a paragraph of fog by a firm that does not.
- How many people will actually touch this code, not how many are assigned to the account?
- What has to be true before you call a stage finished, and who checks it?
- Who decides when the client and the engineer disagree, and how fast?
- What did you automate so that no human has to remember it?
- When it goes wrong, whose name is on it?
The last one matters most, and it is the subject of the rest of this library.
8. Conclusion
The evidence is old, consistent, and almost entirely ignored in the way software is bought. Adding people to a project buys days and costs multiples. The mechanism is arithmetic, not attitude. The risk lives in a fat tail that averages conceal. And the only lever that reliably moves any of it is the boring one: decide things once, write them down, make them checkable, keep the executing unit small, and put a single name on the outcome.
That is what we mean when we say we sell a system rather than a set of people. The people are the best part of it. They are not the product.
References
- QSM, team size analysis of 564 information systems projects completed since 2002, and four related studies of the QSM database, summarised at qsm.com
- Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975
- Bent Flyvbjerg and Alexander Budzier, Why Your IT Project May Be Riskier Than You Think, Harvard Business Review, 2011, dataset of 1,471 projects, preprint
- Michael Bloch, Sven Blumberg and Jürgen Laartz, Delivering large-scale IT projects on time, on budget, and on value, McKinsey and the BT Centre for Major Programme Management, University of Oxford, 2012, mckinsey.com
- Consortium for Information and Software Quality, The Cost of Poor Software Quality in the US: A 2022 Report, it-cisq.org