The asado is running late. The guests have arrived, the snacks are gone and the grill master is alone at the grill. Then the obvious solution shows up, which is going over to lend a hand. One person rearranges the coals, another flips the sausages, a third has opinions on how done the flank steak is. Twenty minutes later the asado is just as late, the grill master is in a bad mood and nobody knows who took the blood sausage off too early.
Fred Brooks wrote it down in 1975, in The Mythical Man-Month, after managing one of IBM's biggest software projects of the era. Adding people to a late software project makes it later. That's Brooks's law, and he summed it up with a line people still repeat fifty years later: nine women can't have a baby in one month.
It sounds counterintuitive. If there's too much work and too few people, adding people should help.
But new people show up with questions. Someone on the team has to explain the context to them, walk them through the code, review their first PRs. That someone is almost always one of the people who knows the most, who happened to be the ones pushing the project forward. During the first few weeks, the people who were already there have to split their time between moving forward and helping the newcomers.
Then there's communication. With three people there are three possible conversations; with six, fifteen; with ten, forty-five. Not everyone has to talk to everyone, but each person who joins adds connections to coordinate. I wrote recently that communication is a trade-off: building things stopped being expensive and agreeing on things is still very expensive. Brooks saw it half a century earlier.
And some work simply can't be split. If a task needs another one to be finished, adding people doesn't shorten that wait. Those are the nine-months-no-matter-what tasks.
With a late project you have three knobs: scope, date and people. The people knob is the slowest one, because it takes weeks to have an effect and at first it turns the wrong way. If the project is late, it's almost always better to cut scope or move the date than to add hands.
If you still have to add people, better early and on parts of the work that can be isolated, with clear boundaries, where someone can move forward without understanding the whole system. And someone who already knows the system ramps up much faster than someone brilliant starting from scratch.
If the people who know the project spend the day explaining it, they have less time left to finish it.
With AI agents a new version of the same question shows up. If adding people has this cost, what happens when you add agents that write code nonstop? I have no idea yet. I suspect the cost of agreeing on things doesn't disappear and just moves somewhere else, but we'll see.
In the meantime, if the asado is running late, ask the grill master what they need before grabbing the tongs.