Brooks’s Law
Adding people to a late project makes it later, because new people cost more in onboarding and coordination than they add in output before the deadline arrives.
What Is It?
Brooks’s Law states that adding manpower to a late software project makes it later. Fred Brooks proposed it in The Mythical Man-Month, drawn from his own experience managing IBM’s OS/360 project.
The mechanism, not just the aphorism: a new person doesn’t arrive ready to contribute. They need onboarding time from people who are already behind, which subtracts capacity from the project before it adds any. And communication overhead grows faster than headcount does, since every new person adds a new set of coordination links to everyone already on the team, not just one more worker.
Why Does It Matter?
“Throw more people at it” is one of the most reflexive responses to a slipping deadline, and it’s usually wrong for exactly the reason it feels right. The instinct treats a project like a ditch that digs faster with more shovels. Most real project work isn’t that. It requires shared context that takes real time to transfer, and the people best positioned to transfer it are the same people the deadline pressure was already squeezing.
Adding people often feels like increasing capacity. In reality, it temporarily redistributes capacity away from the work that was already behind.
What Changes Once You See It?
You stop assuming more people always increase capacity. Instead, you ask what kind of work is actually late. Work that can be divided into largely independent pieces, work with low coordination needs and little shared context to transfer, can often absorb more people without the penalty. Work that’s tightly coupled, where everyone needs to understand the same evolving picture, usually can’t.
Picking strawberries is the case Brooks’s Law doesn’t cover. A new picker needs a few minutes of instruction, not weeks of context handed off by someone who’s already behind, and row 47 doesn’t need to know what row 12 is doing. Add ten pickers and you get roughly ten times the picking, because there’s almost no coordination surface between them. A software feature, a strategy document, or a merger integration sit at the other end of the same spectrum: the work is entangled with decisions already made and context already built up in other people’s heads, and getting it out of those heads is exactly the time the deadline was already squeezing. The law scales with how coupled the work is, not with the domain it happens to live in.
You also start noticing the timing problem specifically. Adding people early, before deep coordination debt has built up, costs less than adding them once a project is already deep into a crunch, because the onboarding tax gets paid by people who have the least slack to pay it.
Common Misunderstandings
- Brooks’s Law is not a blanket argument against ever adding headcount. It’s a claim about late projects specifically, where onboarding cost and deadline pressure collide.
- It doesn’t mean more people never help. Work that’s genuinely parallelizable, with minimal shared context required, doesn’t reliably show the same effect.
- It isn’t really about software, even though that’s its origin. The mechanism, onboarding cost plus communication overhead scaling faster than headcount, applies to any tightly coupled collaborative work.
Diagnostic Question
Is the work we’re behind on something more hands can actually divide, or does it require shared context that adding people will cost us before it gives anything back?
Explore Further
Field Notes
None yet.
Origin
Fred Brooks proposed the law in The Mythical Man-Month (1975), drawing on his experience leading IBM’s OS/360 operating system project in the 1960s, one of the most famous case studies in software project management of a large, well-resourced team still running badly behind schedule.