Brooks's Law
Brooks's Law: Adding people to a late software project makes it later. New team members require time to ramp up (during which they slow others), and communication overhead grows with team size (nΒ² connections for n people). The short-term cost of adding people exceeds the short-term benefit β making the late project even later.
What Is Brooks's Law?β
Fred Brooks formulated this law while managing the development of OS/360 at IBM in the 1960s β one of the largest software projects of its era. He observed that when projects fell behind schedule, the instinctive response (adding more programmers) consistently made things worse. In 1975, he codified the observation in The Mythical Man-Month.
The mechanism operates through two interacting effects:
Ramp-up time: A new programmer on a complex project requires weeks to months to become productive. During this period, they need guidance from existing team members, who must spend time explaining the codebase, architecture, and decisions rather than building. The new person is a net negative to throughput in the short term.
Communication overhead: In a team of n people, there are n(n-1)/2 communication channels. Add one person to a 5-person team (6 total) and channels increase from 10 to 15 β a 50% increase for a 20% increase in headcount. The overhead grows quadratically with team size. Beyond a certain size, much of the team's time is spent coordinating rather than building.
The result: on a late project, adding people increases short-term load (training new people, managing more communication channels) while adding near-term production capacity only after the project was already supposed to be done.
Three Real-World Examplesβ
IBM OS/360 (1960s)β
Brooks's first-hand account from OS/360 is the canonical example. When the project fell behind, IBM added programmers. The added programmers needed extensive onboarding, consuming time from senior developers. The larger team created more coordination requirements, more interfaces between components, more meetings. The project didn't finish faster β it finished even later than a smaller team would have.
This experience directly motivated the aphorism and the book. The Mythical Man-Month remains one of the few books in software engineering that has not been superseded β because the mechanism it describes (communication overhead, ramp-up cost) is fundamental to knowledge work.
Startup Engineering Teams Under Investor Pressureβ
A funded startup is behind on a product deadline. Investors push the founders to hire faster. The founders hire 5 engineers in 2 months. For the first 6 weeks, all 5 new engineers are in onboarding, asking questions, and receiving code review from the existing 3-person team. The 3-person team's output falls to near zero as they mentor and onboard. The product is now later than it would have been with 3 people.
This is not a failure of the hiring decision per se β the team needs to be larger eventually. The failure is the expectation that near-term hiring solves a near-term deadline problem. Brooks's Law predicts it won't.
The "Crunch" in Game Developmentβ
Game development famously involves "crunch" β periods of extreme overtime near ship deadlines. Some studios add contractors near ship to increase capacity. The contractors require onboarding, are unfamiliar with the specific engine and codebase, introduce new bugs during their ramp-up period, and require QA attention that was already maxed out. Crunch productivity research consistently shows diminishing returns; contractor additions near deadlines often produce net-negative throughput effects.
When to Use Itβ
β Apply Brooks's Law when:
- A project is late and stakeholders are considering adding headcount
- Planning team growth timelines relative to delivery schedules
- Setting expectations about when new hires will contribute to throughput
- Designing project recovery strategies
β Exceptions:
- If the tasks are genuinely parallelizable and new people can work independently without coordination, the law applies less strongly
- Long-runway projects where ramp-up time is small relative to the remaining timeline
| Pairs well with | Why |
|---|---|
| Theory of Constraints | Brooks's Law is a special case of adding capacity at the wrong constraint |
| Diminishing Returns | Team size has sharply diminishing marginal returns in knowledge work |
| Parkinson's Law | Both challenge the naive linear relationship between resources and output |
Common Misuses and Limitationsβ
Treating it as an absolute prohibition on adding engineers. Brooks's Law is most true for complex, tightly-coupled tasks with high coordination requirements on a project that is already late. Adding engineers to a late project with modular, independent work streams and good documentation can work. The law is a strong prior, not a universal rule.
Ignoring the time horizon. New engineers become productive after a ramp-up period β typically 1β3 months for junior hires, 1β6 months for senior hires on a complex codebase. Brooks's Law says that adding people makes a project later in the short term. Over a 2-year horizon, adding engineers now may be correct. The question is whether the project can absorb the short-term slowdown.
Using it to resist all hiring. Some engineering leaders invoke Brooks's Law to resist headcount growth even when the team is not late on a project. The law applies specifically to late project rescue; it says nothing about steady-state team growth with proper onboarding.
Applying it outside software. The law is derived from software development, where tasks are cognitively intensive and tightly interdependent. Manufacturing, customer support, and many operational roles have much better scaling properties when adding people β the "ramp-up tax" and "communication overhead" are lower.
Related Modelsβ
| Model | Relationship |
|---|---|
| Theory of Constraints | The bottleneck in a late project is often not headcount but a specific capability or decision |
| Diminishing Returns | Brook's Law is diminishing β and eventually negative β returns to labour on complex tasks |
| Scale Effects | Brooks's Law shows that communication overhead diseconomies offset any scale advantages in software |
| Parkinson's Law | Both describe how software projects resist simple resource-based fixes |
Frequently Asked Questionsβ
Why does adding engineers to a late project make it later?
Two compounding effects. First, ramp-up cost: new engineers don't contribute immediately β they need to learn the codebase, architecture, and team norms. During ramp-up, they consume senior engineer time that was previously going to productive work. Second, communication overhead: in a team of n people, there are n(n-1)/2 communication channels. Adding 5 people to a team of 10 increases channels from 45 to 105 β more than double the coordination complexity. Both effects reduce short-term output even before the new engineers become net contributors.
What should you do instead of adding people to a late project?
Brooks recommends: (1) reduce scope β cut features rather than trying to build everything on schedule; (2) improve process β identify and remove bottlenecks in the workflow; (3) add people to independent tasks only β if there are genuinely parallel work streams that new hires can own without requiring senior engineer time, limited additions can work; (4) defer additions β add people now for future projects, not the current one.
Has Brooks's Law been empirically validated?
It has been studied repeatedly with mixed but generally supportive results. The strongest evidence supports the law for knowledge-intensive, highly interdependent tasks (core feature development, architectural changes) and weakens for more modular, documentation-heavy, or testing work. A 2014 meta-analysis of software project studies found that adding team members late in a project increased project duration in most cases, with exceptions for projects with good modularity and strong documentation. The underlying mechanism (ramp-up cost + communication overhead) is well-established; the magnitude varies by context.
Further Readingβ
- Brooks, F.P. (1975). The Mythical Man-Month: Essays on Software Engineering β the source of the law
- DeMarco, T. & Lister, T. (1987). Peopleware β the human factors that make software teams hard to scale
- Boehm, B. (1981). Software Engineering Economics β quantitative models of software project estimation
Apply with AIβ
π Plan your team growth and project recovery with MindMax β
Further Readingβ
- Fred Brooks, The Mythical Man-Month (1975, anniversary edition 1995) β Essential reading for anyone managing software projects.
This page is part of the MindMax Mental Models Knowledge Base.