As Fred Brooks was leaving IBM, the company’s chief, Thomas Watson Jr., asked him a question. Brooks had run the hardware side of the IBM System/360. Then he had run the software side. So what, Watson wanted to know, was the difference between running the two?
It was a pointed question. The hardware became IBM’s most successful mainframe. The software was another story. Its operating system, OS/360, was hard to write and it was late. By the time Brooks stepped in, more than 1,000 programmers were working on it.
Brooks said the question was too hard to answer on the spot. He would think about it.
His answer, when it came, was a book.
The obvious rescue
A launch is slipping. The work is real, the deadline is real, and the team is tired. So you ask for help, and two good people are moved onto the project.
It feels like the responsible thing to do. It is also one of the most common. A UK study cited by the software writer Steve McConnell found that about half the managers of runaway projects tried to bring them under control by adding staff.
Then the next two weeks play out. Your strongest person spends their mornings explaining the codebase, the client and the history of every odd decision. The weekly meeting runs longer, because there are more updates to hear. The newcomers are sharp and keen. Nobody is slacking.
The date slips again.
Nine women, one month
Brooks first put the rule in print in December 1974, in the magazine Datamation, and in his book The Mythical Man-Month the next year: “Adding manpower to a late software project makes it later.”
He also gave it an image that nobody forgets. “The bearing of a child takes nine months, no matter how many women are assigned.”
The title names the mistake. A “man-month” is the unit managers used to size a job: one person working for one month. The unit quietly assumes that people and months can be swapped. If a job is 12 man-months, then 4 people should finish it in 3 months, and 12 people in 1. That holds for work like picking cotton, where ten people really are ten times as fast as one. Brooks’s point was that most projects are more like the baby.
Three bills
Two cooks make dinner faster than one. Ten cooks in the same small kitchen spend the evening saying “behind you.”
A late project pays three bills when you add people.
Some work won’t split. When a task has to happen in sequence, more people don’t make it go faster. Brooks pointed at debugging, which in software tends to run one step after another.
New people have to learn. Someone has to teach them how the project works. That someone is one of the few people who already know, and their time is exactly what a late project is short of.
Everyone has to stay in sync. Every pair of people who need to coordinate is a line of communication. If everyone has to coordinate with everyone, three people have 3 such lines. Ten people have 45. The headcount grows one person at a time. The talking grows much faster.
Your two-week rescue paid all three. The plan counted hands and forgot the cost of connecting them.
Where the law bends
Brooks knew his rule was a simplification. Twenty years on, he still called it “the best zeroth order approximation to the truth.”
McConnell disagreed in 1999. Most late projects, he argued, are much later than their managers think: not three weeks from done but six months. With that much runway, new people have time to become useful. Even McConnell agreed that every project reaches a point where more people make it slower. The fight is about where that point sits, and it turns on how cleanly the work splits and how much teaching the newcomers need.
That is why the teams that climb out of the hole usually change something other than headcount. They cut scope, so less work has to pass through the people who know. They move the date and say so early. Or they hand the new people a piece of work that stands on its own, with its own inputs and its own finish line.
Ten agents in ten seconds
The extra hands have changed. Ten AI agents start in seconds, and none of them needs months to learn the codebase. They look built to break Brooks’s Law. Each still has to be handed the project’s background, its tools and its rules before it can do useful work, so the onboarding bill changes shape. It doesn’t disappear.
The communication bill stays too. In a study published in December 2025, Google researchers tested 180 combinations of agents, models and tasks. On a financial analysis job that split into independent parts (revenue here, costs there, competitors over there) a coordinated team of agents beat a single agent by 80.9%.
Then they tried a planning task where each step depended on the one before. Every multi-agent setup they tried did worse, by 39 to 70%. The researchers’ explanation sounds like Brooks: the agents spent so much effort talking that the reasoning itself got chopped into pieces. And when agents worked independently and their results were only combined at the end, errors were amplified 17.2 times. With a coordinator checking the work, that fell to 4.4 times.
On the task that couldn’t be split, a single agent working alone beat every team the researchers built.