Brooks's Law: Why Adding Engineers Slows Delivery

"Adding manpower to a late software project makes it later." Fred Brooks wrote that in 1975, and half a century later engineering leaders still relearn it every time a hiring wave makes the roadmap slip. This guide covers what Brooks actually claimed, the three mechanisms behind it, what modern large-scale data says, whether AI changes the equation - and how to see the law operating in your own Git history.

What Did Brooks Actually Write in 1975?

Fred Brooks managed the development of IBM's OS/360, one of the largest software projects of its era, and distilled the experience into The Mythical Man-Month (1975). Chapter 2 contains the sentence that became the law: "Adding manpower to a late software project makes it later." Brooks was careful about its status - he called it an "outrageous oversimplification" in the same breath. The chapter's real target is the man-month itself: the accounting fiction that people and months are interchangeable, so a 12 person-month project can be done by 12 people in one month.

That trade only works when a task divides perfectly and the workers need no communication - harvesting a wheat field, in Brooks's example. Software is the opposite case: sequential constraints, shared state, and constant coordination. The law is less a prophecy than a warning about what happens when managers treat schedule slippage as a headcount problem.

Why Does Adding Engineers Slow Delivery?

Brooks identified three mechanisms, and all three are still recognizable in any scaling team.

Ramp-up time. A new engineer produces little in their first weeks and consumes the time of the people training them. The team's most productive members - the obvious mentors - are exactly the ones whose output drops. Net output falls before it rises, which is why adding people to a project that is already late is the worst case: the productivity dip lands precisely when there is no slack to absorb it.

Communication overhead. Channels grow quadratically: n(n-1)/2. As Brooks put it on page 17, "Three workers require three times as much pairwise intercommunication as two; four require six times as much as two." A team of 5 has 10 channels; a team of 10 has 45. Every channel is a standing tax of meetings, reviews, and misunderstandings. Amazon institutionalized the countermeasure as the two-pizza team - if two pizzas cannot feed the team, the team is too big.

Task divisibility. Some work partitions cleanly; most software work does not. When a task is sequentially constrained - design before build, build before integrate - extra hands cannot compress it. Brooks's darker version: bearing a child takes nine months, no matter how many people are assigned.

Headcount is a lagging investment, not an instant input. The question is never "will new engineers help?" - it is "when will they help, and who pays the ramp-up cost in the meantime?"

What Does Modern Data Say?

Brooks wrote from one project's experience. The mechanisms have since been measured at scale, and they hold up well.

The Zhou and Mockus study quantifies the ramp-up mechanism: project size, not developer talent, drives how long "fluency" takes. QSM's 491-project analysis quantifies the overhead mechanism at team level. And Scholtes, Mavrodiev and Schweitzer found it in the open source record at repository scale - per-capita output falls as contributor count rises, consistent with what Ringelmann observed in rope-pulling experiments a century earlier. Three datasets, three eras, one shape.

Does AI Repeal Brooks's Law?

AI assistants attack the first mechanism directly. In a randomized controlled trial, Peng et al. (2023) found developers with Copilot completed a task 55.8% faster. Cui et al. (2025, Management Science), studying 4,867 developers across three field experiments, found roughly 26% more completed tasks - with the largest gains for less-experienced developers, exactly the population Brooks's ramp-up mechanism punishes. DX's enterprise benchmark (September 2025) reports daily-AI engineers reaching their 10th merged PR in 49 days versus 91 days without - a vendor benchmark, but directionally consistent with the experiments.

The other two mechanisms are untouched. AI does not reduce the number of communication channels, and it does not make sequentially constrained work parallel. The DORA 2024 report supplies the counterweight: a 25% increase in AI adoption correlated with 1.5% lower delivery throughput and 7.2% lower delivery stability. Individuals code faster; delivery systems do not automatically ship faster. If anything, AI raises the volume of code flowing into an unchanged review and integration pipeline - which moves the bottleneck squarely onto coordination, Brooks's home turf.

How Do You See Brooks's Law in Your Own Git Data?

The law's mechanisms leave fingerprints in version control, which means you can manage them instead of guessing. Three signals cover most of it.

Onboarding ramp. Time from start date to first merged PR, and the slope of PRs merged over the first 90 days, measured per cohort. If your last three hires took twice as long to their tenth PR as the three before them, your codebase or onboarding process got harder - Zhou and Mockus's finding, in your own data. Our guide to measuring onboarding with Git data walks through the cohort method.

Review-load concentration. Ramp-up cost lands on mentors, and mentors show up in review data: a handful of seniors doing most of the reviews for new hires' PRs. When review load concentrates, those seniors' own cycle time and output fall - the invisible half of Brooks's ramp-up tax made visible.

Cycle time vs headcount. Plot PR cycle time against active contributor count by quarter. Growing teams should expect a temporary rise after each hiring wave; a permanent rise is the n(n-1)/2 term telling you a team needs to split. This is also why headcount planning should model throughput from delivery data rather than assuming output scales linearly with seats - and why forecasting from actual throughput beats man-month arithmetic.

CodePulse computes all three from your GitHub history - first-PR timelines by developer, review-network concentration, and cycle time trends against team size - so the Brooks conversation happens with charts instead of anecdotes.