Brooks's Law: Adding People to a Late Project Makes It Later

A project is behind schedule. The deadline is fixed. The obvious response is to put more people on it.

Fred Brooks, who managed a very large software project in the 1960s and wrote about what he learned, put the result in one sentence: adding people to a late software project makes it later.

This is counterintuitive enough that it gets rediscovered constantly by managers who assume it cannot apply to their situation. It usually does, and the reason has nothing to do with the new people being unhelpful.

Two things happen at once

New people need to learn before they contribute. They must understand what is being built, how the existing pieces work, what conventions the team uses, and where the traps are. Someone has to teach them.

The people qualified to teach are the experienced team members — who are also the people producing the work. So the immediate effect of adding someone is that output falls, because experienced hands move from producing to explaining. If the project is already late, this arrives at the worst possible moment.

Coordination costs grow faster than the team. This is the part people underestimate. With three people there are three possible pairs who might need to coordinate. With six, fifteen. With ten, forty-five. The number of relationships grows roughly with the square of the team size, while output grows at best linearly.

At small sizes this is invisible. Past a certain point, a meaningful share of everyone's day goes to meetings, status updates, and resolving misunderstandings — work that exists purely because there are more people, and produces nothing directly.

Put the two together and a late project given more people spends a period producing less than before, and then produces slightly more with substantially higher overhead. The recovery may not arrive before the deadline it was meant to save.

Where the law does not apply

Brooks was careful, and the sentence is often quoted more broadly than he intended. Two conditions matter.

The work must be tightly coupled. If a task genuinely divides into independent pieces — different features, separate components, work with clean boundaries — extra people can work in parallel without much coordination. Brooks's own example of divisible work was harvesting a field: more workers, more harvested, minimal coordination.

Most complex engineering is not like harvesting. The pieces interact, decisions in one area constrain another, and the parts must fit together. That coupling is what makes coordination expensive.

There must be time to absorb the newcomers. Adding people early in a project, when there is room for them to learn before the crunch, works fine. The law describes adding them late, when there is no time for the investment to pay back.

So the useful version is narrower than the slogan: adding people to a late project with tightly coupled work makes it later. Those conditions are common, which is why the law feels universal — but they are conditions, not always the case.

This also connects to Conway's Law: how you divide people determines how the system gets divided. Adding people forces new boundaries in the work, and those boundaries end up in the architecture whether or not they belong there.

What to do with a late project instead

Since the intuitive lever makes things worse, the alternatives are worth knowing.

Reduce scope. Usually the only genuinely effective response. Ship less, on time, and add the rest later. This is unpopular because it means admitting the original plan was wrong, but it is the one lever that reliably works.

Move the deadline. Sometimes possible, often not. Where it is, doing it early is far better than doing it late — an honest revision three months out costs less trust than a missed date.

Remove obstacles rather than adding people. Whatever is slowing the existing team — waiting on decisions, unclear requirements, a flaky test environment, too many meetings — can often be fixed without changing headcount. This is the theory of constraints again: find what is actually limiting throughput rather than adding capacity somewhere else.

If you must add people, give them something separable. A distinct piece with a clean interface, ideally something the existing team was going to do later anyway. This minimises the coordination and training burden.

Plan the team size before starting, not during. The right time to add capacity is at the beginning, when there is time to onboard. Staffing decided in a panic is staffing decided at the worst moment.

Brooks's underlying observation generalises past software: people are not interchangeable units of production, and effort is not additive when the work requires coordination. Nine people cannot produce a baby in one month, as the well-worn line goes — and a surprising amount of project planning is built on the assumption that they can.