Brooks's law: why adding people delays late projects
The project is running behind. The seemingly obvious fix: bring in more people. Fred Brooks, who led one of the largest software projects of his era at IBM, drew the opposite conclusion in his classic 1975 essay collection The Mythical Man-Month: adding people to a late project can make it even later.
The claim has become known as Brooks's law. The book draws on the experience of building the operating system for IBM's mainframes in the 1960s, but fifty years later it is still cited – because the mechanisms behind it apply to almost any work where people have to think together.
What does the research say?
The man-month of the title – today we would rather say person-month – refers to the habit of counting work as if people and months were interchangeable: ten people for one month equals one person for ten months. Brooks calls that a myth. The swap only works when the work can be split into completely independent parts that require no communication – and such work is rare in projects.
Two mechanisms eat up the gains from adding people. The first is onboarding: new team members don't contribute from day one, and while they are being trained they take time from the most experienced people – precisely those the project depends on most. The second is communication: the number of communication paths in a group grows much faster than the number of people, because each new person essentially needs to be able to talk to everyone else. More time goes into coordinating, less is left for actual work.
Brooks also points out that some things simply take the time they take, regardless of staffing – an idea captured in the oft-quoted image that nine women cannot deliver a baby in one month. He was careful to note that the law is a deliberate simplification, but as a warning flag it has held up remarkably well.
What does this mean for you as a project manager?
When someone proposes more people as the answer to a delay: calculate the full effect. Who will train the newcomers, how long will it take, and what happens to your key people's pace in the meantime? Sometimes the answer is still yes – but only after that calculation, not instead of it.
Review the alternatives before you scale up staffing. Cutting scope, moving the delivery date, or removing distractions for the existing team often delivers more impact faster than hiring – without the onboarding cost.
If you do bring in more people: do it early, not late, and give the newcomers well-bounded tasks that require as little coordination as possible. Appoint a clear mentor and accept that the mentor's own output will drop during onboarding – that is a cost you choose, not a surprise. The later in the project, the harder Brooks's law bites.
How to practise this
The hardest part of Brooks's law isn't understanding it – it's standing in the meeting where a stressed sponsor demands that you "just bring in more consultants". In Project-simulator you can rehearse that conversation in advance: explain why more hands don't automatically mean more speed, propose alternatives, and hold your ground under pressure. You get evidence-based feedback on your own words, and nothing can break for real. Try it free for a week.
In Project-simulator you practice these conversations against an AI counterpart and get feedback grounded in research like this.
Try free for 7 days