The Math That Kills Teams

In 1964, IBM bet everything on OS/360.

It would be the most ambitious software project ever attempted. One operating system to run on every IBM computer. Fred Brooks led the effort with hundreds of programmers.

Then the schedule slipped.

Management did what managers do. They added more programmers. Hundreds more. The logic seemed obvious: more hands, faster work.

The project got later.

Brooks watched it happen in real time. Every new programmer needed training from the existing ones. Every new hire created new communication pathways. Every additional person meant more meetings, more handoffs, more coordination overhead.

The math was brutal: n(n-1)/2.

With 10 programmers, you have 45 communication channels. With 50 programmers, you have 1,225. With 100, you have 4,950 channels of potential miscommunication.

Productive capacity grows linearly. Add one person, add one person's worth of output. But coordination overhead grows quadratically. Add one person, add connections to everyone already there.

At some team size, the overhead exceeds the output.

You're slower with more people. Not because they're incompetent. Because the math doesn't care how talented they are.

Brooks published this discovery in 1975. He called it The Mythical Man-Month. Fifty years later, we're still making the same mistake.

Adding people to a late project makes it later.

Not sometimes. Mathematically.

This note connects to Momentum Engineering, the post exploring how organizational velocity is governed by physics, not effort.