The Cost of Coordination (Brooks's Law)

Adding People Slows You Down

Here's a counterintuitive truth: if a project is behind schedule, adding more engineers to it will usually make it even more behind schedule. This observation, known as Brooks's Law, was articulated by Fred Brooks in his 1975 book The Mythical Man-Month:

"Adding manpower to a late software project makes it later."

Why does this happen?

Because the cost of coordination grows quadratically — much faster than linearly — with team size. Every new person added to a team creates new communication channels that consume time. The formula for the number of unique communication channels in a team of n people is:

Channels = n × (n - 1) / 2

Team Size → Communication Channels
    2     →     1
    3     →     3
    5     →    10
    8     →    28
   10     →    45
   15     →   105
   20     →   190

A team of 5 has 10 channels to manage. A team of 20 has 190. You added 4x the people but created 19x the coordination overhead.

The Economic Impact:

Doubling a team from 5 to 10 engineers does not double output. Here's a realistic model:

5 engineers:
  - 10 communication channels
  - ~20% time in meetings/coordination
  - Effective capacity: 5 × 0.80 = 4.0 engineer-equivalents

10 engineers:
  - 45 communication channels
  - ~40% time in meetings/coordination/onboarding
  - Effective capacity: 10 × 0.60 = 6.0 engineer-equivalents

You doubled your payroll cost but only got 50% more output.

This phenomenon is called diminishing returns. At extreme team sizes, adding people can actually produce negative returns — the coordination overhead consumes more productivity than the new person adds.

The Fix — Architectural Solutions to an Economic Problem:

Keep teams small. Amazon's "Two Pizza Rule" — if a team can't be fed by two pizzas (~6–8 people), it's too big.
Decouple architectures. Microservices, well-defined APIs, and clear ownership boundaries let teams work independently. If Team A can deploy without coordinating with Team B, you've eliminated communication channels between them.
Invest in platforms. Internal Developer Platforms (IDPs) replace human coordination with self-service automation. Instead of filing a ticket and waiting 3 days for a database, an engineer provisions one in 5 minutes through a portal. The platform absorbs the coordination cost.

Interview Tip

If an interviewer asks "How do you scale an engineering organization?" don't just say "hire more people." Say: "Headcount scaling has diminishing returns due to coordination overhead — Brooks's Law. The more scalable approach is to reduce coordination requirements through architectural decoupling and self-service platforms. You want teams that can ship independently, not teams that need to synchronize constantly." This answer demonstrates systems thinking, not just people management instinct.

Key Point: Brooks's Law has a direct architectural implication that senior engineers must internalize: your system architecture will mirror your organization's communication structure — this is Conway's Law. If you want independent, fast-moving teams, you must first design systems with clean boundaries. Throwing money at headcount without fixing architecture is the most expensive mistake an engineering organization can make. The sequence matters: fix the architecture first, then scale the teams.

Adding People Slows You Down

This is one of 18 chapters