Brooks's Law

Adding people to a late software project makes it later.

“Adding manpower to a late software project makes it later.”
— Fred Brooks, The Mythical Man-Month (1975)

Doubling a team from three to six people multiplies the communication paths fivefold, from three to fifteen.

To an executive

Adding people to a late project usually makes it later, because newcomers slow down the experienced staff. Cutting scope or moving the date is often the faster fix.

To an engineer

Before adding people to a late project, count the onboarding cost and coordination paths. Prefer cutting scope, or splitting work along truly independent boundaries.

The idea

In The Mythical Man-Month, drawing on his experience managing IBM's System/360 and OS/360 projects, Fred Brooks stated what became known as Brooks's Law: adding manpower to a late software project makes it later.

He gave three reasons. New people need time to ramp up, and the experienced people who train them stop delivering while they do. Work has to be repartitioned to give the newcomers something to do. And communication overhead grows quickly: with n people there are n(n−1)/2 possible pairs who may need to coordinate. Some work simply cannot be divided. As Brooks put it, a pregnancy takes nine months however many people are assigned to it.

Why it works

People and months are not interchangeable. Effort only divides cleanly when tasks are independent. Software tasks share design decisions, code and context, so splitting them adds coordination work.

Ramp-up costs come first; benefits come later. On a late project, the time left is often shorter than the time new people need to become productive, so the net effect is negative.

Coordination grows faster than headcount. Doubling a team from three to six people increases the possible communication paths from three to fifteen. Meetings, reviews and misunderstandings grow with them.

Where it applies

Rescue plans for late projects, when the first instinct is to add contractors.
Migration and modernisation programmes, where much of the knowledge sits with a few people.
Team and architecture design, to decide where work can be made genuinely parallel.
Conversations with sponsors, to explain why more budget will not buy the date back.

How to apply

Check divisibility. Ask whether the remaining work splits into independent pieces with clear interfaces, or depends on a shared design.
Estimate the ramp-up cost honestly, including the time experienced people will spend onboarding and reviewing.
Prefer scope or date changes on a late project. Cutting features is usually faster than adding people.
Design for parallel work early. Modular boundaries and well-defined contracts let more teams contribute later without constant coordination.

Example scenario

A data-platform migration was three months behind schedule. The sponsor doubled the contractor headcount to recover. Senior engineers spent most of their days onboarding newcomers, answering questions and reviewing unfamiliar code, and delivery slowed for the next quarter.

On a later programme, the architect proposed a different response to slipping: drop two low-value data sources from the first release and split the remaining work along clear service boundaries. Two new people joined only where a boundary let them work independently, and the revised date held.

Questions to ask

Can this remaining work really be split, or does it depend on a few people and a shared design?
How long will new people take to become productive, and who will train them?
Could we cut scope or move the date instead of adding people?

When not to use it

Early in a project, when there is time for new people to ramp up and the architecture can be shaped for parallel work.
Genuinely independent work, such as migrating many separate applications, where extra teams can take whole pieces without much coordination.

How it misleads you

Concluding that teams should never grow. Brooks's Law bites hardest on late, tightly coupled work; modular systems with clear ownership scale teams far better. It can also become an excuse for never asking for help, even when a specialist with the right knowledge would shorten the path.