Learn it → Apply it → Save as Skill
Adding people to a late software project makes it later. New hires need time to become productive, and every additional person adds new lines of coordination to a team that is already behind. The fix for a late project is rarely just more hands.
The Dr. Wallace’s Favorite Mental Models is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.
Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.
When a project falls behind, adding staff feels like the obvious fix. But new people need time to learn the work, and every new person adds coordination links between everyone already on the team. Work that cannot be split into independent pieces gets slower before it gets faster.
Important: coordination links grow as n(n−1)/2. Adding 4 people to a 6-person team doesn't add 4 units of work capacity — it triples the number of relationships that must stay in sync.
The model is most useful the moment someone proposes adding people to catch up a late, tightly coupled effort.
Brooks's Law is a caution about timing and task structure, not a blanket rule against ever growing a team.
Decide whether the slipping work is genuinely divisible or whether it depends on shared context, like architecture, debugging or design.
Estimate how long new people need before they're net-positive, and who on the existing team will train them.
Count how many new communication links form and how much bandwidth they draw from people who were already productive.
Choose between adding people early enough to absorb ramp-up, restructuring the work into independent pieces, or accepting the new date.
Open a use case to see what the model changes.
Ask what the contractors need to learn before they can ship safely, and who will teach them. If the release date is weeks away and the work is tightly coupled, added people may cost more time than they save.
Coordination links grow with the square of team size. Consider splitting into smaller, more autonomous teams with clear interfaces instead of folding everyone into one larger group.
Separate the schedule problem from the staffing problem. If the bottleneck is unclear requirements or unresolved architecture decisions, more engineers will not resolve ambiguity faster.
New consultants still need ramp time on the client's context, data and stakeholders. Weigh that cost against the deadline pressure before agreeing to add headcount.
The same dynamic applies to any collaborative creative work. Late-joining members need catch-up time, and the group now has more handoffs to manage before the deadline.
Brooks's Law generalizes beyond software to any process with high coordination needs and limited ability to split the work cleanly, such as a complex changeover or a research effort on a deadline.
This is an illustrative example designed to teach the method.
Expand for the origin of the law and what it does and doesn't claim.
Fred Brooks led IBM's System/360 and OS/360 project in the 1960s, one of the largest and most famous software efforts of its time, which ran badly behind schedule. He described what he learned in "The Mythical Man-Month: Essays on Software Engineering" (1975), still one of the most cited books in software management.
His stated rule is narrow: "Adding manpower to a late software project makes it later." He also warned against treating a "man-month" as an interchangeable unit, noting that effort and progress are not the same thing when tasks require shared understanding or cannot be perfectly divided among workers.
Brooks studied software specifically, but the underlying mechanics, ramp-up time and communication overhead that grows faster than headcount, appear in any collaborative work with complex interdependencies. The strength of the effect still depends on how divisible the work actually is.
Some tasks split cleanly among more people. Deeply coupled work like architecture or debugging usually does not.
New hires are rarely productive on day one, especially on unfamiliar codebases or processes.
Coordination links grow roughly with the square of team size, not linearly with headcount.
Staffing changes made right before a deadline leave no runway to absorb ramp-up before it's needed.
More person-hours does not guarantee proportionally more finished, working output.
Adding people without dedicating experienced staff to onboard them slows down the whole team, not just the newcomers.
the task truly separates into independent, low-coordination units, such as parallel manual testing or independent content production.
there is enough runway left in the schedule to absorb ramp-up well before the deadline arrives.
the real cause of the slip is unclear requirements or scope creep. More people cannot resolve a definition problem.
This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.
Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to apply Brooks's Law, what questions to ask, what evidence to seek, what mistakes to avoid and how to structure its analysis.
Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.
No. It describes what happens when people are added to a project that is already late and tightly coupled. Growing a team early, with enough runway to absorb ramp-up, or on genuinely divisible work, does not carry the same penalty.
It's Brooks's term for the fallacy of treating effort (person-months) and progress (calendar time) as interchangeable. Some work can be split among more people; some cannot, no matter how many people are assigned to it.
Brooks's original account came from IBM's OS/360 project, but later software engineering literature, including Steve McConnell's "Rapid Development," has examined team size, communication overhead and productivity and generally supports the underlying mechanics. It is best treated as a well-supported heuristic grounded in real project experience, not a strict mathematical law.