The instinct when a project is behind is to add people. Fred Brooks watched that instinct fail so reliably at IBM that he turned it into a law: adding manpower to a late software project makes it later. Fifty years on, it's still one of the most ignored findings in engineering management, usually right up until a founder learns it the expensive way.
Key Takeaways
- Adding people to a late project makes it later, Brooks's 1975 observation from managing IBM's OS/360 (The Mythical Man-Month).
- The cause is communication overhead: channels grow with the square of team size, so doubling the team roughly quadruples the conversations (Brooks's Law).
- New people also need ramp-up time from the very engineers you need shipping.
- The fix is to staff ahead of the crunch, not during it, and to add people in the right shape.
Why More People Can Mean Less Output
Brooks gave three reasons the law holds (Brooks's Law). First, ramp-up: a new engineer isn't productive on day one; they need weeks to learn the codebase, and that learning comes out of your existing engineers' time, the exact people who were already underwater. Second, communication overhead, the math that surprises people. The number of communication channels on a team grows with the square of the size, roughly n(n-1)/2. A team of 3 has 3 channels; a team of 6 has 15. Double the team and you quadruple the conversations, and every one is coordination time not spent building. Third, limited divisibility: some work just can't be split. Nine women can't make a baby in a month, and some engineering tasks are the same, sequential and immune to more hands.
Brooks learned this managing OS/360, where he added programmers to a slipping project and watched it slip further (The Mythical Man-Month).
| Team size | Communication channels |
|---|---|
| 3 | 3 |
| 5 | 10 |
| 8 | 28 |
| 12 | 66 |
A Concrete Version
A feature is three weeks late, so the founder throws two new engineers at it. For the first month, the two engineers who understood the project spend half their time onboarding the newcomers, answering questions, reviewing tentative PRs, and explaining context. Coordination that used to be a hallway chat is now a five-person planning problem. The project doesn't speed up; it slows down, exactly as Brooks predicted, and the founder is baffled because "we added resources."
The Honest Counterpoint
Brooks's Law isn't a reason never to grow a team; it's a reason to grow it at the right time and in the right shape. The law bites hardest when you add people late, into a project already in crunch, on tasks that can't be divided. It bites far less when you add senior people who ramp fast, when you add them before the crunch, or when the work genuinely splits into independent chunks with clean interfaces. The escape isn't "never hire." It's "don't panic-hire into a fire," and structure the work so new people can contribute without constant coordination.
What This Means for Staffing
Two practical lessons follow. First, add capacity ahead of the wall, not at it, since a hire you make today isn't productive for weeks. Second, seniority changes the math: an experienced engineer who gets productive in an unfamiliar codebase quickly imposes far less ramp-up tax, which is exactly the trait we screen for in how to verify a senior engineer. It's also why fast, pre-vetted senior capacity beats a slow panic hire, the whole point of how fast you can actually hire. See available engineers.
Frequently Asked Questions
What is Brooks's Law?
"Adding manpower to a late software project makes it later." Fred Brooks coined it in 1975 based on managing IBM's OS/360. New people need ramp-up time and add communication overhead, so they can slow a late project instead of speeding it up.
Why does adding people slow a project down?
Three reasons: new engineers need weeks to ramp (using your existing team's time), communication channels grow with the square of team size, and some tasks can't be divided among more people.
Does Brooks's Law mean I should never add engineers?
No. It means add them ahead of the crunch, not during it, and prefer senior engineers who ramp fast. The law bites hardest when you add people late to indivisible work.
How do I avoid Brooks's Law?
Staff before the deadline pressure hits, add experienced engineers who need less ramp-up, and structure work into independent pieces with clean interfaces so new people can contribute without constant coordination.
The Bottom Line
Adding people to a late project makes it later, because communication overhead grows with the square of the team and new hires ramp on your best people's time. The answer isn't to refuse to grow. It's to add capacity early, add it senior, and never treat a panic hire as a way to make up lost time.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
