Brooks’s Law: Why Adding Developers to a Late Project Makes It Later

TL;DR: Fred Brooks’s famous rule says that adding people to a late software project usually makes it later, not sooner. New hires need time and attention from the very people already doing the work, and every extra person adds more communication paths to manage. If a project is behind, cutting scope or moving the deadline is almost always a safer fix than throwing more engineers at it.

Picture a team called Atlas. They’re building the new checkout flow for an online store, and it’s three weeks behind schedule. The launch date is fixed because it’s tied to a big marketing push. The engineering manager looks at the burndown chart, feels the pressure from above, and does the thing that feels obvious: she asks for three more engineers to join the team next week.

It feels like simple math. Five people are producing X amount of work per week. Add three more people, and you should get more than X. But two months later, Atlas ships even later than the original estimate before the new hires joined. This isn’t bad luck. It’s a well-known and well-documented pattern, and it has a name.

The Law, and Why It Sounds Wrong

In 1975, a software engineer named Fred Brooks wrote a book called The Mythical Man-Month, based on his experience managing a massive, late IBM project. His core observation is now known as Brooks’s Law: adding manpower to a late software project makes it later.

It sounds wrong at first. If a task is taking too long, adding more hands should speed it up, the same way a second painter can help finish a fence faster. The problem is that software work usually doesn’t split apart that cleanly. A fence can be divided into sections that two painters can work on independently, with almost no need to coordinate. A checkout flow can’t be divided the same way. The payment logic, the inventory checks, and the order confirmation screen all depend on shared decisions, shared code, and a shared understanding of how the system is supposed to behave. That shared understanding lives in people’s heads, and it takes time to transfer.

Where the Extra Time Actually Goes

When a new engineer joins a project, they don’t start being useful on day one. They need to set up their laptop, get access to repositories and services, read through code that has months of undocumented decisions baked into it, and ask questions. And here’s the part that catches people off guard: those questions get answered by the existing team members, the same people who were already behind schedule.

Every hour an existing engineer spends explaining how the payment retry logic works is an hour they’re not spending fixing the actual bug that’s blocking launch. In the short term, adding people doesn’t just fail to speed things up. It actively slows the existing team down, because the team’s total capacity gets redirected from “finishing the project” toward “training new people to eventually help finish the project.”

A rough picture of where a team’s time goes right after new people join a late project.

On the Atlas team, this played out almost exactly like the diagram above. In the first two weeks after the new engineers joined, the team shipped less working code than they had the two weeks before, even though the headcount had grown by 60%. Onboarding and coordination ate into the budget that used to go straight into features.

The Math Behind the Mess

There’s a second reason adding people backfires, and it’s about communication, not training. As a team gets bigger, the number of people any one person might need to sync with grows much faster than the team size itself.

Here’s the simple version. If you have n people on a team, the number of possible one-on-one communication pairs is n(n-1)/2. A team of 5 people has 10 possible pairs. Add 3 more people to make a team of 8, and the number of pairs jumps to 28. The team got 60% bigger, but the number of relationships that might need a conversation, a Slack thread, or a meeting to stay aligned almost tripled.

This is why bigger teams feel slower even when everyone on them is skilled and hardworking. Nobody is being lazy. There’s just more coordination to do per person, and that coordination competes directly with the time spent writing and reviewing code.

What Actually Helps a Late Project

If more people usually isn’t the answer, what is? It depends on how much runway is left and how divisible the remaining work actually is.

Where the three common responses to a late project tend to land on speed and risk.

Cutting scope is usually the fastest, lowest-risk move, because it reduces the amount of shared understanding anyone needs to build. Extending the deadline is safe but slow, and it only works if the business can actually absorb the delay. Adding people sits in the risky corner, because it trades a small, uncertain chance of long-term speedup for a near-certain short-term slowdown.

A useful rule of thumb: only consider adding people if the project has months of runway left, not weeks, and if the remaining work can genuinely be split into pieces that don’t depend heavily on each other. A three-week crunch is exactly the wrong time to add headcount, because there isn’t enough runway left to absorb the onboarding cost before the deadline arrives anyway.

If You Do Add People, Do It Deliberately

Sometimes adding people is still the right call, usually for a project with a long horizon rather than a short deadline crunch. When that’s the case, the mistake to avoid is dropping a new hire straight into unsupervised, high-stakes work. That maximizes the coordination tax without giving them a real chance to become productive.

A deliberate ramp-up path costs time up front but pays it back instead of stealing it from the whole team indefinitely.

A better pattern looks like the board above: get the environment working first, then pair the new person with someone experienced on real tickets, then let them take small, low-risk tasks solo, and only then hand them ownership of a meaningful piece of work. It’s still an investment of the existing team’s time. The difference is that it’s a bounded, planned investment instead of an open-ended drain that shows up as constant interruptions for the rest of the project.

When Atlas eventually recovered, it wasn’t because the new engineers suddenly became productive overnight. It was because the manager stopped treating headcount as the lever to pull and cut the launch scope instead, shipping the core checkout flow on time and following up with the extra features two weeks later. The new engineers joined the follow-up work once they’d had real time to ramp up, and by then, they helped.

The Takeaway

Brooks’s Law isn’t an argument against ever hiring or ever growing a team. It’s a warning about timing. A late project is, by definition, a project that’s short on time, and the two costs of adding people, onboarding and communication overhead, both cost exactly the thing the project doesn’t have any more of. Next time a deadline is slipping, ask whether the fix is more hands or less scope. Most of the time, it’s the scope.