In 1987, Fred Brooks observed something every project manager had felt but none had named: adding engineers to a late software project makes it later. He published it as Brooks's Law. The observation was not new. Naming it was. Once it had a name, teams stopped arguing about whether it applied in their specific case and started asking the better question — what part of Brooks's Law is operating here, and what can we do about it?
That is the function of a named law (L6, in the engineering laws framework). It does not tell you what to do. It tells you which constraint to expect, so you can design with it instead of against it.
The Observation
The project is three weeks late. The obvious move is to add people. A senior engineer gets reassigned to help. Six weeks later, the project is four weeks late.
This is not because the new engineer was incompetent. Brooks's Law predicts exactly this outcome with a competent engineer. The lateness is structural — it comes from three mechanisms that activate the moment you add a person to an in-flight project.
Mechanism 1: Onboarding Consumes Existing Capacity
A new engineer cannot contribute on day one. Someone has to explain the codebase, the deployment process, the failure history, the unwritten conventions. That someone is an existing engineer — the one who was, until now, making progress on the late project.
Before: [Eng A] [Eng B] [Eng C] → 3 units of progress
Add D: [Eng A] [Eng B] [Eng C → onboarding D] [Eng D → learning]
→ 2 units of progress, for several weeks
The team did not gain a worker. In the near term, it lost one and a half: the new engineer produces nothing yet, and an existing engineer is now half-consumed teaching. Capacity goes down before it goes up.
Mechanism 2: Communication Overhead Grows Non-Linearly
This is the mechanism that makes Brooks's Law a law rather than a complaint. Communication channels in a team do not grow with headcount — they grow with the square of headcount.
N engineers produce N(N−1)/2 communication channels.
3 engineers → 3 channels
5 engineers → 10 channels
8 engineers → 28 channels
12 engineers → 66 channels
Going from 8 to 12 engineers — a 50% headcount increase — more than doubles the communication channels. Every channel is a place where context must be synced, decisions must be aligned, and misunderstandings can form. The same shape appears in Metcalfe's Law for networks: value, and overhead, scale as O(n²).
This is why a team that spends two hours per engineer per week in coordination is not a minor inefficiency. For every ten engineers, that is roughly six months of engineering time per year spent purely on alignment — and adding people makes the per-person coordination cost worse, not better.
Mechanism 3: The New Engineer Is a Drag Before an Asset
There is a crossover point. Before it, the new engineer costs the team more than they contribute — questions asked, reviews needed, mistakes corrected. After it, they are a net positive. On a project that is already late, the deadline often arrives before the crossover point. You paid the entire cost and collected none of the benefit.
contribution
│ ____ net positive
0 ├───────────/──────────────── time
│ ____/
│ ____/ ↑
│/ crossover point
↑
deadline often lands here
The Tradeoff Underneath
Brooks's Law is, at its core, AT3 — Simplicity vs Flexibility — playing out in an organisation. A small team is simple: few channels, shared context, fast decisions. A large team is flexible: more parallel capacity, more specialisations covered. But the flexibility is bought with coordination complexity that grows quadratically. Past a point, adding flexibility (people) actively destroys the simplicity (shared context) that made the team fast.
Knowing the type of law matters here. Brooks's Law is a human-behaviour tendency, not a mathematical constraint. A mathematical constraint cannot be circumvented — you work within it. A tendency can be mitigated. Treating Brooks's Law as iron fate ("never add anyone, ever") is as wrong as treating it as an opinion ("it won't happen to us").
The Mitigation
You cannot repeal Brooks's Law, but you can route around its mechanisms.
Do not add engineers to the critical path late in a delivery cycle. This is the direct instruction. The critical path is exactly where onboarding cost and communication overhead do the most damage.
Onboard new engineers on parallel, non-integrated work. Give the new engineer a separate track with no dependency on the late project's critical path until the current cycle closes. They become productive without taxing the engineers racing the deadline.
Invest in documentation and tooling before you need it. The onboarding cost in Mechanism 1 is not fixed — it is a function of how legible the system is. A well-documented codebase with reproducible setup shrinks the capacity drain. This investment must exist before the crisis, because making it during the crisis is itself a tax on the critical path.
Where It Goes Wrong
The failure mode is treating headcount as the universal lever. A project is late; the instinct is to add people; the law guarantees it gets later; the response is to add more people. Each addition compounds the communication overhead in Mechanism 2. This is FM5 — latency amplification — at the organisational level: each new coordination hop adds delay, and the delays multiply across the team graph.
The deeper error is diagnostic. "Late" is a symptom. The cause might be unclear requirements, a hard technical problem, or scope that grew silently. None of those are fixed by headcount. Adding engineers to a project that is late for a non-capacity reason pays the full Brooks's Law cost and addresses nothing.
The One Sentence
Adding an engineer to a late project costs you onboarding capacity now, quadratic communication overhead permanently, and a contributor who will not break even before the deadline — so the only safe time to grow a team is when it is not under deadline pressure. Name the reason the project is late before you reach for headcount; if the reason is not "not enough hands," more hands will not help.