Learn & Understand

Brooks's Law: Why Adding People Makes a Late Project Later

The capacity calculator multiplies team size by hours and availability, a clean linear model: double the people, double the capacity. For steady work it is a reasonable approximation. But the instant a project is already late and a manager reaches for the obvious lever, throwing more people at it, that linear intuition breaks down catastrophically. The classic warning is Brooks's law, and it explains why capacity does not scale the way the multiplication suggests.

The Law

Fred Brooks, reflecting on a massive software project, distilled his hardest-won lesson into a single sentence: adding people to a late project makes it later. Not "helps less than you'd hope", actually later. This is deeply counterintuitive against the calculator's linear model, where more heads can only mean more hours. The resolution is that the model omits two costs that grow with team size and swamp the added capacity.

Cost One: The Communication Explosion

The number of communication links between people does not grow with headcount, it grows with the square of it. A team of three has three pairwise channels; a team of ten has forty-five. Every added person must coordinate with everyone already there, and that coordination consumes real hours that the raw "team size times hours" figure counts as productive. Past a certain size, so much of each person's day goes to keeping everyone aligned that additional people add more overhead than output.

Cost Two: Ramp-Up Steals From the Experienced

The second cost is that new people are not instantly productive. They must be brought up to speed on the project, and the only people who can teach them are the experienced members, who must therefore stop doing productive work to do it. So a newcomer not only contributes little at first, they actively subtract from the output of the people the project could least afford to slow down. On a late project with no time to spare, this is precisely the wrong trade.

What the Availability Factor Really Hides

The calculator's availability percentage, meant to discount for meetings and time off, is where these effects can be smuggled in, but only if you set it honestly. As a team grows, its effective availability for real project work falls, because coordination eats an ever-larger share of the day. A big team modeled at ninety percent availability is usually fiction; the true figure drops with size. The linear formula is safe for stable teams and treacherous as a plan for rescuing a slipping one.

To see whether planned work already exceeds this capacity, feed the result into the Resource Allocation Calculator; to convert capacity into a sustainable delivery rate, the Sprint Velocity Calculator.