Adding More People to a Late Software Project Makes It Later — Brooks' Law Explained

This article reflects professional analysis and industry research. Individual results vary.

The Brooks Law software project management myth is one of the oldest ideas in computer science. It is also one of the most proven. Fred Brooks framed it in The Mythical Man-Month in 1975. Adding manpower to a late software project makes it later. Years of project data show this is not just theory. It is a clear pattern, and it still hurts software work today.

The Myth: Hire More Developers and Speed the Project Up

When a software project falls behind, most bosses want to add more people. It feels like simple maths. More workers should mean more work done each week. The logic is easy to follow. Late in a software build, it is also almost fully wrong.

Brooks named the reason. New team members do not show up ready to help. They need onboarding from the people already on the job. Every hour a senior developer spends training a new hire is an hour lost. That hour is not spent on the work that is already late.

The Evidence Against It: Brooks and Fifty Years of Research

Fred Brooks published The Mythical Man-Month in 1975. It drew on his time running the IBM OS/360 project. That was one of the biggest software efforts of its era. The idea that became Brooks' Law came from what he saw. Adding staff to a project in trouble made it slower, not faster. The book is still in print. Software engineering courses treat it as required reading.

The maths here is simple. In a team of n people, the number of communication channels is n times (n minus 1) divided by 2. A team of 5 people has 10 channels. A team of 10 has 45. A team of 20 has 190. Each channel is one more chance for mixed signals, double work, clashing plans, and coordination overhead. So adding people does not raise output in a straight line. It raises coordination costs geometrically.

The Standish Group CHAOS Report has tracked software project outcomes since 1994. It offers some of the fullest data we have on success rates. The research keeps showing that bigger teams are not linked to higher success rates. Small, focused teams with clear scope and strong communication do better. Large teams with fuzzy roles do worse.

A 2014 study in the journal IEEE Transactions on Software Engineering looked at 166 software projects. Team size past the best range for a given scope was negatively correlated with on-time, on-budget delivery. In that study, the best team size for most software projects was six to nine people. Above that, the cost of coordination ate up the gains from extra people.

Brooks named one exception in the 20th anniversary edition, published in 1995. Say a project splits cleanly into fully independent pieces with no ties between them. Then adding teams to those pieces can speed up delivery. The key word is independent. Most late-stage software projects do not split cleanly. The work that is left is late because it is the hardest and most tangled work.

What Is Actually True: What Fixes a Late Software Project

Adding people is not on the list of things that reliably fix a late software project. The steps that do work look quite different:

None of these steps look as impressive as hiring. A new developer hire signals action. Cutting scope feels like giving up. That gap in how the two options feel is part of why Brooks' Law is still broken fifty years after it was published.

Frequently Asked Questions

Q: Is Brooks' Law always true, or are there genuine exceptions?

A: Brooks named the exception himself. It is fully partitioned work with no ties between the pieces. If a project truly has separate modules that other teams can build alone, parallel teams can help. Most late projects do not meet that test. The hard work left is usually the tangled core.

Q: If hiring is not the solution, what should an executive actually do when a project is late?

A: Start with diagnosis. Is the project late because of scope creep, a technical bottleneck, missing decisions, or team capacity? The answer points to the right fix. Cutting scope clears most schedule problems faster than any other lever. After scope, look at blockers. Adding people comes last, if at all. Save it for work that can truly be done on its own.

Q: What about Agile approaches that use multiple teams on the same product?

A: Large Agile frameworks like SAFe and LeSS run multi-team work with care. They set clear boundaries, defined interfaces between teams, and fixed coordination ceremonies. Those structures exist to manage the coordination overhead Brooks identified. They work when they are done well. They can still hit Brooks' Law snags when the teams' work is not truly independent.