Adding people to a late, tightly coupled project makes it later, not sooner

What it is

Brooks's law holds that adding more people midway into a task that is already behind schedule and highly interdependent will not shorten the remaining timeline proportionally, and often lengthens it instead. The observation originated in software project management, but it is not limited to software: any tightly dependent collaborative task requiring heavy alignment can show the same backfiring effect if expanded hastily near a deadline. It corrects an intuitive error — treating "person-months" as an interchangeable unit, as if ten people working one month equals one person working ten months.

Why it happens

Before a new person can make a net contribution, they must first understand the task's current state and build common ground with existing members, and that learning and communication investment falls on the existing team, whose time was previously spent advancing the task itself. When a task is highly interdependent and coordination cost already dominates total effort, the division-of-labor gain from added headcount gets offset by two things at once: the newcomer's own ramp-up period, and the time existing members are pulled away to mentor and align with them. If the sum of these two exceeds the net output the newcomer can provide, the team's total effective progress actually falls, and an already tight timeline stretches further.

Studying it

Historical project archives support regression analysis: controlling for task size and dependency complexity, one can compare the change in actual progress rate before and after a late-stage headcount increase, testing whether expansion correlates with the degree of delay. Team interviews can also reconstruct the added mentoring, repeated explanation, and rework events that follow an expansion, estimating how much of existing members' working time those hidden costs consumed. This kind of study is inherently observational — the decision to expand a team often occurs precisely when a project has already run into trouble, making it hard to rule out "the project itself got harder" as a confound, so the direction of causation needs careful interpretation.

Where it stops holding

The conclusion holds only where coordination cost already dominates, task interdependence is high, and a newcomer needs considerable time before contributing independently. When a task is highly decomposable and a newcomer can immediately take on an independent sub-module with little need to align with existing members, expansion can still shorten the timeline. Early in a project, before dependencies have solidified and while there is ample time to absorb a newcomer's learning cost, the negative effect of expansion is also far smaller than adding people hastily near a deadline. The law therefore describes an effect under a specific combination of conditions, not a general rule that more people always means slower.

Applying it

• Before deciding to add people mid- or late-project, assess the current task's dependency complexity and the newcomer's expected time-to-independent-contribution, rather than linearly extrapolating headcount from remaining workload.
• If people must be added, assign them to the sub-tasks with the fewest dependencies and clearest boundaries, avoiding parts tightly coupled to core logic that need frequent coordination.
• Explicitly budget existing members' time for mentoring newcomers and deduct it from the team's original output expectation, rather than assuming output is unaffected.
• After adding people, track the team's overall effective progress rate rather than just the new hire's individual output; if the overall rate falls, adjust the plan promptly instead of attributing it to the newcomer's competence.

Related

• Same group: V1.06.1 Net benefit of collaboration equals division-of-labor gain minus coordination cost · V1.06.2 Coordination cost grows faster than output as headcount rises · V1.06.3 Task decomposability sets the floor on coordination cost · V1.06.5 Tools can only lower coordination cost, not remove the task's own dependencies
• Nearby: V1.02 Granularity of Collaboration · V6.01 Task Assignment
• Search terms: Brooks's law · mythical man-month · ramp-up cost