Thank you for visiting this site. This article covers one of the most famous lessons in project management: “Brooks’s law.”
Facing a project about to miss its deadline, most people reason: “if we’re short-handed, reinforcements will get us there.” In software development, this move routinely backfires. Brooks’s law is the counterintuitive rule that “adding manpower to a late software project makes it later.” More people, yet slower — how can that be? This article unpacks the reasons from three angles. There is a great deal here about how work actually works.
What Is Brooks’s Law?
Brooks’s law is the rule of thumb that “adding manpower to a late software project makes it later.”
It comes from Frederick Brooks, the engineer who led development of a mainframe operating system, in his 1975 book The Mythical Man-Month. Out of the bitter experience of running an enormous project, he put words to the field truth that “the more people you throw at a delay, the worse things get.”
At first hearing, this sounds absurd. If the amount of work is fixed, more workers should mean faster completion — plowing a field with twice the hands takes half the time. But in work that builds one thing with many minds, like software, this simple arithmetic collapses. Why? Three clear reasons. Let’s take them in order.
Reason 1: New People Take Time to Become Productive
First: a newcomer is not immediately a contributor.
Someone joining a project midstream cannot sprint from day one. They must first absorb the history, the system’s architecture, the conventions and tools. That ramp-up takes real time.
The vicious part: the people who must teach the newcomers are the veterans already carrying the project. Onto an already overloaded team, “onboarding” lands as additional work. The teachers stop their own tasks to explain. In other words, calling in reinforcements ties up the hands of exactly the people who produce the most. Until the newcomers come up to speed, total team output actually drops. That is the first mechanism by which adding people fails to add speed.
Reason 2: Communication Overhead Explodes with Headcount
The second reason is the law’s very heart: as headcount grows, the burden of communication and coordination balloons faster than intuition expects.
Count it out. A team of 2 has 1 line of communication. At 3 people, 3 lines. At 4, 6 lines. At 6, 15 lines. Double the team and the number of pairwise channels nearly quadruples — an unavoidable consequence of everyone needing to stay mutually informed.
Every channel consumes meetings, confirmations, alignment — time that is not the work itself. The more people you add, the more each person’s productive hours get eaten by coordination. When the coordination cost of the added hands exceeds the value they produce, the whole slows down. Parkinson’s law described officials multiplying regardless of workload; Brooks describes the sibling trap — “the more people, the more time dissolves into talking to each other.”
Reason 3: Some Work Cannot Be Divided
Third: some work simply cannot be split up.
Brooks left the immortal illustration: “nine women can’t make a baby in one month.” A pregnancy takes about nine months, and no amount of added personnel compresses it. Work that is inherently sequential, or must proceed as one integrated whole, cannot be parallelized by adding hands.
Software development is full of such indivisible cores — shaping the overall architecture, building the deeply interlocked pieces. These resist division among many people; a small, focused group usually finishes them faster. Some work speeds up with people; some doesn’t. Misjudge that distinction, reach for human-wave tactics, and Brooks’s trap closes.
What to Take Away
So what should we do when the project is late? Brooks’s law does not merely say “don’t add people.” Its lessons are more practical.
First, internalize that “when you’re late, added headcount is no miracle cure.” Rather than panic-hiring, it is usually more effective to cut scope, reorder priorities, and redraw the deadline realistically. This connects to Murphy’s law’s “plan for the worst”: at the first signs of slippage, revisit the plan before you call for bodies.
Second, if you do add people, do it early. Early in a project there is time for ramp-up and structure-building. “Panic-adding at the end” is the worst case; “starting with the right number” is the ideal. I feel the pull myself — deadlines loom and hands look like the answer — but remembering this law has trained me to reach first for “subtract and focus” before “add.”
Common Questions About Brooks’s Law
Does It Apply to Every Kind of Work?
No — it bites hardest in some kinds and barely in others. The law applies most strongly to work that is densely interdependent, deep in specialized knowledge, and hard to partition — software being the canonical case. Work that is simple and cleanly divisible (handing out ten thousand flyers, say) speeds up honestly with more hands. Understand Brooks’s law as a trap specific to “many minds building one thing,” and you will apply it in the right places.
Why Is the ‘Man-Month’ a Myth?
A “man-month” is a unit meaning “one person working one month,” as in “a ten man-month job.” Brooks branded it a “myth” because the unit smuggles in the false premise that “people and time are interchangeable.” Ten man-months reads as “10 people × 1 month” or “1 person × 10 months,” take your pick. But as the chapters above showed, adding people explodes communication and some work cannot be divided — so the exchange fails. A convenient unit that lures managers into the staffing trap: seeing through it is exactly what earned the book its title.
Does a Half-Century-Old Law Still Hold?
Yes — it is considered as valid as ever. The law dates to 1975, but its roots — ramp-up takes time, communication scales badly, some work resists division — do not change with better tools. Modern chat, remote collaboration, and automation do shave some coordination costs. But the essence — “more people does not simply mean faster” — applies to today’s projects unchanged. That the book is still read and quoted is the proof.
Related Laws
See “Parkinson’s law” (work expanding to fill time), “Murphy’s law” (planning for the worst), and “the Peter principle” (people rising to their level of incompetence).
Summary
This article covered “Brooks’s law.”
Add people to a late software project, and it gets later. The counterintuitive law rests on three legs: newcomers take time to become productive; communication overhead explodes with headcount; and some work cannot be divided. “Nine women can’t make a baby in one month” captures the essence in one stroke.
The lesson: casual staffing-up is no cure for lateness. Before scrambling for bodies, narrow the scope and reorder the priorities. If people must be added, add them early, not at the end. Some work accelerates with hands and some doesn’t — and just being able to tell the two apart makes steering a project far easier. When the urge to hire your way out strikes, this is the law to remember.
To return to the full list of laws, follow the link below.
Thank you for reading. We hope to see you in the next article.
📚 Series: Famous & Fascinating Laws (6/25)
