Pattern/Aphorism/No. 0119
Brooks’s Law
Brooks’s Law is the observation that adding people to a late software project can delay it further. Named for Frederick Brooks, it describes how training and coordination costs can exceed new staff’s contribution before a deadline, rather than a universal rule about team size.
- Evidence
- Useful, modest evidence
- Read
- 6 min
- Links
- 11 connections
01You've seen this when…
- at work
A release slips, so management transfers four developers onto the team. The people who were fixing the hardest bugs now spend their mornings answering questions and reviewing unfamiliar code.
- in life
You’re late finishing a website for your sister’s wedding. A friend volunteers to code, and you spend the evening explaining the unfinished pages instead of fixing them.
- out in the world
A city’s permit portal misses its launch date. The contractor announces a larger software team, but the launch moves again while newcomers learn the system and their changes get integrated.
02The idea
When a project falls behind, adding people looks like the obvious repair. More hands should finish the remaining work sooner. Newcomers need preparation before they can work independently.
Newcomers need explanations, access, practice, and feedback. The people best qualified to provide those things are often the same people the deadline depends on. Adding help can therefore reduce productive capacity before it increases it.
Frederick Brooks summarized the danger this way: “Adding manpower to a late software project makes it later.”
The useful version is conditional, not absolute: adding people can delay a late project when the cost of bringing them in exceeds their contribution before the deadline. The new team might become stronger eventually and still miss the immediate release by more.
The mistake is treating people and time as interchangeable. Ten people working for one month and five people working for two months can produce different results.
03Why it happens
- Training borrows time from the existing team. Documentation rarely contains every architectural decision, hidden dependency, or production constraint. New people need answers from experienced people. That borrowing matters most when the experts are already the bottleneck.
- Coordination grows with the team. As more contributors agree on interfaces and review changes, they have more opportunities to make conflicting assumptions. The number of possible person-to-person connections grows faster than headcount. That growth helps explain why enlarging a team can create disproportionate overhead, even if each person talks to only some colleagues.
- Some work is too interdependent to divide usefully. An unresolved design decision or a difficult integration problem may block everything else. Adding people to parallel tasks can leave the critical path unchanged. Division of labor helps only when the pieces can actually proceed separately.
- Interruptions and rework consume the expected gain. An expert switches between debugging and teaching. A newcomer makes a reasonable change that violates an undocumented assumption. The resulting task-switching costs, review, and repair can outweigh the work completed.
Late projects are especially exposed because there is little time left to recover the initial investment in new staff. The same hire who helps over six months may hurt over six days.
04A worked example
Imagine a six-person team building a dispatch system for a delivery company. Launch is four weeks late. Most screens work, but drivers’ phones sometimes lose updates when they reconnect after being offline. Management adds four developers and sets a new launch target ten days away.
What it looks like The team has grown from six people to ten, so the remaining work should move much faster. The new developers immediately start closing smaller bugs.
What’s actually going on The release depends on the synchronization problem, which only two existing engineers understand well. Those engineers now explain the data model, arrange test environments, and review incoming changes. Some changes touch the same synchronization code, creating extra integration work. The bug count falls, but the launch-blocking problem receives less uninterrupted attention.
The newcomers are capable, but they face a learning curve, and its cost exceeds what the project can absorb on its critical path right now.
What would have helped Protecting the two specialists’ time and assigning newcomers bounded work with clear acceptance tests. An experienced tester could reproduce the failure and build a regression test. Another developer could handle an independent reporting feature. If no useful independent work exists before launch, the release needs a plan that fits its current capacity. Reducing scope or changing the date may be more honest.
05How to spot it
06What to do about it
- Find the constraint before changing headcount. Identify what actually prevents completion: missing capacity, an unresolved decision, a dependency, or a technical unknown. Extra people solve only some of these problems.
- Count the onboarding cost explicitly. Estimate both the newcomer’s ramp-up time and the existing team’s teaching and review time. Compare those costs with the newcomer’s expected useful output within the time left before the deadline.
- Give new people separable assignments. Favor work with a clear interface, limited dependencies, and testable results. Modularity makes staffing changes less disruptive because fewer people need to coordinate every change.
- Protect scarce expertise. Batch questions and, where possible, assign an onboarding contact so newcomers share a route to answers. Preserve uninterrupted blocks for the people doing launch-critical work.
- Change the commitment when capacity cannot arrive in time. Cut optional scope, stage the release, or revise the date. A larger team still needs a feasible plan.
- Build capacity before the emergency. Cross-training and documentation cost time too, but paying that cost earlier gives the team time to benefit from it.
07When it isn’t a staffing mistake
Adding people can help when work is independent or when onboarding costs are manageable: newcomers already know the system, or the deadline leaves enough time to recover those costs. Bringing in a specialist who removes a particular obstacle can also help immediately. Adding one well-matched person and doubling a team are different interventions.
Brooks’s law focuses on staffing changes during a project, while diseconomies of scale describes the broader problem of getting less efficient as an organization grows. Brooks’s warning includes a transition cost: even a sensible future team can be the wrong team to assemble during a deadline crisis.
Amdahl’s law explains why a portion of work that cannot run in parallel limits speedup. Brooks’s law adds another possibility: introducing people can create work and temporarily make progress slower.
Both principles leave the ideal team size undetermined. Brooks’s aphorism calls for inspecting the work before deciding whether added help will be useful.
08Roots
At IBM in the 1960s, Frederick Brooks managed development of OS/360, the operating system for the System/360 computer family. IBM promised a compatible family of machines that could use the same software across models. Delivering that promise required a large, tightly interdependent software effort.
The experience exposed a weakness in the way managers planned software. A person-month looked like a convenient unit: multiply workers by months and obtain an amount of work. But the arithmetic ignored how much developers depended on one another, and how much teaching each staffing increase required.
Brooks turned those lessons into The Mythical Man-Month in 1975. Its memorable staffing rule traveled far beyond mainframe development because managers kept encountering the same temptation: rescue a slipping schedule by increasing the number of people assigned to it.
Later researchers, including Tarek Abdel-Hamid and Stuart Madnick, modeled software projects with interacting effects such as training, staffing, and rework. Those models helped explain how an attempted schedule rescue could backfire. Brooks’s warning remains conditional, and its value lies in examining the costs that a headcount calculation leaves out.
09How solid is this?
Software-project experience and models of training, coordination, and rework support a practical warning. A universal claim goes beyond that evidence. There is no general headcount threshold at which adding staff must increase delay.
10Connections
- Countered by Modularity
- Can follow fromTask-Switching Cost, Tight Coupling
- Part ofDiseconomies of Scale
- See alsoBottleneck, Amdahl's Law, Critical Path, Division of Labor, Learning Curve, Conway’s Law, Hofstadter’s Law
+ 1 more in the list
11Origin and sources
Frederick P. Brooks Jr., The Mythical Man-Month (1975), drawing on his experience managing IBM’s OS/360 development in the 1960s.
- [1]Brooks, F. P., Jr. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
- [2]Abdel-Hamid, T. K., & Madnick, S. E. (1991). Software Project Dynamics: An Integrated Approach. Prentice Hall.
Suggest an edit· Updated 2026-10-02