Brooks's law
mythical man-month
Adding people to a late project makes it later. Fred Brooks stated it in 1975 from managing IBM's OS/360, and the cause is that communication paths grow faster than headcount while new people consume the time of the people who already know the work.
In practice
Two more people join the delayed project and the delivery date moves further out, because the person who could have finished it is now explaining it.
The common mistake
Reading it as a rule against hiring. It applies to a project that is already late, where the ramp-up cost lands inside the deadline. The same hire made three months earlier is usually correct.
Fred Brooks managed the development of IBM's OS/360, which was enormous and late, and wrote The Mythical Man-Month in 1975 about what he learned. The central claim: adding manpower to a late software project makes it later.
The two mechanisms
Ramp-up is paid by the people who are already productive. A new person cannot contribute until somebody explains the work, and the only people who can explain it are the ones currently doing it. So the immediate effect of adding a person is to reduce output.
Communication paths grow quadratically. Three people have three pairs. Ten people have forty-five. Every additional person adds more connections than the last, and coordination consumes a growing share of everyone's time.
Brooks's underlying target was the "man-month" itself — the assumption that people and time are interchangeable. They are interchangeable only when a task can be partitioned with no communication between the parts, which is true of picking cotton and false of almost all knowledge work.
What it does and does not license
It does not say teams should be small in general, and it does not say hiring is bad. It says the ramp-up cost is real and lands immediately, so the arithmetic only works when there is time for the new person to become productive before the deadline.
Which means the actual decisions are these.
Hire before you are late. The same hire that is destructive in month five is correct in month two.
If you are late, change the scope. The only levers on a late project are scope, quality and date. Headcount is not one of them, and reaching for it is how a late project becomes a failed one.
Reduce what has to be communicated. Clear interfaces between parts of the work is what allows more people to contribute at all, which is why Conway's observation about organizations and systems matters here.
The general form beyond software: diminishing returns on headcount arrive early and turn negative faster than intuition suggests, because coordination is a cost that scales with the square of the thing you are adding.
Concept web
Open the full webQuestions
What is Brooks's law?
That adding people to a late software project makes it later. Fred Brooks stated it in 1975 based on IBM's OS/360, citing ramp-up time taken from productive people and communication paths that grow faster than headcount.
Why does adding people make a project later?
Because new people must be brought up to speed by the people currently doing the work, which reduces output immediately, and because every additional person adds more communication paths than the last.
Does Brooks's law mean you should not hire?
No. It applies to projects already late, where ramp-up cost falls inside the deadline. The same hire made months earlier is usually right. On a late project the only real levers are scope, quality and date.