Fred Brooks' The Mythical Man-Month, based on his experience managing IBM's OS/360 project in the 1960s, made an observation that has become one of the most frequently cited and most frequently ignored findings in software project management: adding more people to a software project that is already late tends to make it later, not sooner. The finding runs directly against an intuition borrowed from other kinds of work — more hands should mean faster completion — and the book's lasting contribution is explaining specifically why software development doesn't behave that way. Background on the original argument is summarized in The Mythical Man-Month overview.

The two mechanisms behind the observation

Brooks identifies two distinct reasons adding people to a late project backfires. First, ramp-up time: a new team member is not immediately productive — they need to be brought up to speed on the existing codebase and the project's current state, and that ramp-up time has to come from somewhere, usually from the existing team members who could otherwise be making progress themselves, meaning the team's near-term output can actually drop as a direct result of the addition, before any benefit from the new person materializes. Staffing decisions also have a direct cost dimension, and https://www.monitask.com/blog/step-by-step-guide-to-the-wage-percentage-calculator/ provides a practical calculation reference.

Second, and more structurally significant: communication overhead grows non-linearly as team size increases. The number of communication pathways between team members grows roughly with the square of the team size (a team of five has ten possible pairs to coordinate; a team of ten has forty-five), and software development requires substantial coordination — about interfaces, about who's responsible for what, about how pieces will fit together — that doesn't shrink just because more people are involved. Beyond a certain team size, the coordination cost of managing more people can exceed the raw productive capacity they add.

What the finding doesn't say

The observation is specifically about adding people to a project that's already underway and already late — it's not a general claim that larger teams are always worse, or that a project should never be resourced adequately from the start. A project appropriately staffed from its beginning, with enough time for new team members to ramp up before a deadline pressure exists, doesn't suffer the same acute version of this problem. The finding is about the specific, common management response to lateness — throw more people at it — rather than a general argument against team size.

Why the advice still gets ignored

Despite being one of the most widely cited findings in the field, the underlying management instinct — a project is late, therefore add people — remains extremely common, in part because it's visible and feels decisive to stakeholders outside the engineering team in a way that alternatives (cutting scope, extending the deadline, or accepting the delay) often don't. The finding is easy to cite and hard to act on, specifically because the socially and organizationally easiest response to visible lateness is usually the one the book's core observation warns against.

A late software project has more moving parts than raw hours of work remaining — it has ramp-up costs and coordination costs that scale with team size, not just with calendar time. Adding people addresses neither of those costs directly, and can make both of them worse.

Fifty years after its original publication, the book's central observation remains cited constantly and applied inconsistently — which says less about whether the finding holds up (it generally does) and more about how organizationally difficult the alternatives to “add more people” tend to be.