When delivery slips, the reflex is to hire — but the arithmetic of coordination usually says that will make things worse, not better.
When a delivery date is at risk, the instinct in most leadership rooms is the same: add people. It's an understandable reflex — it worked in manufacturing, where more hands on a line generally means more output. But a delivery system built on knowledge work doesn't behave like an assembly line, and treating headcount as a proxy for capacity is one of the most expensive mistakes a leadership team can make.
The Fifty-Year-Old Finding Everyone Rediscovers
Fred Brooks ran IBM's OS/360 project in the 1960s, watched it fall behind, added engineers to catch it up, and watched it fall further behind. He wrote up what he learned in *The Mythical Man-Month* in 1975, and the core observation — now known as Brooks's Law — has held up for fifty years: adding manpower to a late software project makes it later. Brooks identified three reasons. New people need time to become productive before they contribute anything (ramp-up time). Existing team members have to stop and train them, which is a real cost paid immediately in exchange for a benefit that arrives later, if at all. And some work simply can't be split among more people no matter how badly you'd like it to be — a task with sequential dependencies doesn't go faster because nine people are staring at it instead of one.
Why the Math Turns Against You
The mechanism behind Brooks's Law is arithmetic, not opinion. Brooks showed that the number of communication pathways in a team grows by the formula n(n−1)/2, where n is team size. A team of 5 has 10 possible pairs who might need to coordinate. Grow it to 10 and that number is 45. Grow it to 20 and it's 190. Team size doubles; the coordination burden roughly quadruples. Every new hire doesn't just add their own output — they add a growing number of new relationships, handoffs, and status updates that someone has to maintain, and none of that shows up in a capacity plan.
Exhibit 1
New hire joins the team
Ramp-up and onboarding drag begins
New communication pathways open across the team
Existing team members re-explain context instead of delivering
Coordination time crowds out delivery time
Net throughput gain arrives months later — if it arrives at all
Why headcount and throughput move on different timelines.
Capacity is not a headcount. It's a system's ability to convert people into finished, valuable work — and that system has its own physics.
What the Data Actually Shows
This isn't just a 1970s anecdote. Quantitative Software Management (QSM), which maintains a database of thousands of completed software projects, has published a series of studies spanning 1997 to 2018 — by researchers Doug Putnam, Don Beckett, and Kate Armel — covering roughly 2,500 projects between them. The pattern repeats across every study: smaller teams consistently outperform larger ones on the same class of work. In one dataset, best-in-class projects delivered five times faster and used fifteen times less total effort than worst-in-class projects, with teams running over four times smaller on average. In another, large teams (nine or more people) delivered projects only 30% faster in calendar time than small teams (under four people). They paid for that speed with 350% higher cost and 500% more defects that then had to be found and fixed.
Exhibit 2
Cost of staffing the same 100,000-line project two different ways
QSM's analysis found the eightfold staffing increase bought roughly one calendar week of schedule reduction and produced over five times as many defects.
Source: QSM, "Overstaffing for Schedule Compression in Software Development," qsm.com.
Task Divisibility Is the Hidden Variable
The reason more staff buys so little schedule is that most delivery work isn't a pile of identical, independent tasks — it's a network of dependencies, where some pieces can run in parallel and others can't start until earlier ones finish. Brooks's original observation was that the number of months a project takes depends on its sequential constraints, while the number of people you can usefully add depends on how many independent subtasks exist. You cannot substitute one for the other. Software estimation has a name for the part this leaves out: the "ninety-ninety rule," attributed to Tom Cargill of Bell Labs and popularized in Jon Bentley's 1985 *Communications of the ACM* column, holds that the first 90% of a system takes 90% of the time — and the remaining 10% takes another 90%. The hardest, most sequential, least divisible part of the work is usually what's left when the deadline is closest, which is exactly when more headcount helps least.
Amazon's Counter-Model: Split, Don't Stack
Amazon's well-known "two-pizza team" rule — teams kept small enough to be fed by two pizzas, generally cited around five to eight people — is a structural answer to the same physics Brooks described. Rather than growing a single team past the point where coordination overhead outpaces added output, Amazon's approach is to split into a new, independently accountable team once a group outgrows that size. The lesson isn't that ten or fifteen people can never work together productively — it's that beyond a certain size, more capacity has to come from adding coordinated units, not from stacking more people onto one already-strained team and hoping the org chart absorbs the difference.
Ramp-Up Isn't Instant, Either
Even when new headcount is genuinely warranted, it isn't available on day one. Industry survey data — including a Swimm survey of more than 80 engineers and engineering managers across company sizes — puts full ramp-up to productive contribution at roughly three to nine months, depending on the complexity of the system a new hire is joining. A hiring decision made to hit a deadline six weeks out won't show up as capacity until well after that deadline has passed — and in the meantime, the existing team is paying the training cost Brooks described, out of the same limited capacity that's already under pressure.
The Better Question
None of this means capacity is never the constraint — sometimes it genuinely is, and the fix genuinely is more people, structured well. The failure mode is treating "add headcount" as the default answer to any delivery slip, without first asking whether the system is capacity-constrained or coordination-constrained. Those require opposite interventions. One is solved by hiring. The other is made worse by it.
