Definition
Brooks's Law says that adding people to a project that is already behind schedule makes it finish even later. American software engineer Fred Brooks put it forward in his 1975 book The Mythical Man-Month, drawing on his experience developing an IBM operating system. It is a rule rooted in experience, and it points sharply at how people and time relate on complex work: a paradox of managing organizations.
Why does hiring more people make the work slower?
Say a job takes one person ten months of steady effort. The simple math says ten people could finish it in one month. But that's not how it plays out. Nine pregnant women can't have a baby in one month. Every job takes real time, and some of it is work that has to happen step by step, in order.
A new teammate can't work smoothly on day one. Someone already on the team has to stop what they're doing and explain the project's goals, how the system is built, and where things stand. That eats into the time of your best, most experienced people.
So before the newcomers learn the ropes and start pulling their weight, the time spent on training and getting up to speed has already pushed the project's deadline clock even further toward "late."
Communication paths explode
Another big problem with a bigger team is communication. With two people, there is just one line of conversation. With four people, there are six lines. With eight, there are 28. With ten, there are a whopping 45.
As the team grows, chat channels get messier, meetings drag on, and people spend huge amounts of energy just checking what everyone else is doing. The time left for the real work shrinks, while the time stuck in meeting rooms keeps growing.
Merging and coordinating everyone's output means communication costs snowball. The team's productivity doesn't rise in step with headcount, and in bad cases it even drops.
A more precise take
Brooks's Law is not an extreme claim that hiring is always pointless. For simple labor with clearly divided tasks and no need to consult each other, like carrying bricks or packing boxes, more people really do mean faster work.
Knowledge work is different: software development, design, complex planning. One line of code you write can instantly affect another person's screen, so people must constantly review and check each other's work. The more complex the job, the more the benefit of adding people shrinks.
So when a schedule has already gone sideways, pouring in new people without a plan is rarely the answer. Common alternatives are to keep only the core features and cut the scope, or to renegotiate the deadline itself so it's realistic.
Common misconceptions
Adding people to a busy project is always a mistake.
If you bring people in early with plenty of time to get up to speed, or if the work is simple and can be split into fully independent pieces that need no back-and-forth, extra people help a lot. The trouble starts when you try to rush a tangled, complex job at a point when the project is already late.
Where you meet it
A game team two weeks from launch added five new developers. The veterans spent their time on handoffs instead of fixing existing bugs, and the release slipped another month.
A report was due soon, so several support teams were thrown at it. Now everyone was in all-nighters just to unify the writing style and formatting and line up the content.
In one sentence
Adding people to a late project can make it later, because of training time and communication costs.