Headcount is not momentum

We've worked inside big product organizations — the kind with real budgets, real process, and a room full of smart people for every decision. Good things get built there. Some of the best software we've ever touched came out of exactly those rooms, and we're not going to pretend otherwise.

But somewhere past a certain size, a strange accounting takes over. Adding people to a project starts to feel like progress in itself. Twelve people sounds twice as serious as six, and twice as serious must surely be twice as fast. Anyone who has actually lived it knows the arithmetic runs the other way.

Where the time actually goes

It goes to synchronization. Every person on a project carries a small tax on everyone else: another calendar to find room in, another handoff to document, another person who quite reasonably asks to be looped in before something becomes final. None of this is malicious, and at scale almost none of it is optional. Big organizations aren't slow because the people are slow — they're slow because coordination at size genuinely requires machinery, and machinery has mass.

A four-person team pays almost none of that tax. Decisions happen inside the same conversation where the problem was noticed. The designer was there when the developer explained the constraint, so nobody has to write the constraint up, schedule a review of it, and defend it three weeks later to someone meeting it for the first time.

• —No status meetings about other status meetings.
• —No handoff documents for people sitting in the same call.
• —No waiting two sprints for a decision that takes one honest hour.
• —No translating between what sales promised and what the ticket says.

Small only works when it's senior

Here's the catch, and it's real: a small junior team is just as slow as a big one, for different reasons. Small teams have no slack for learning on the job. Every person has to be someone whose judgment you'd trust unsupervised, because unsupervised is the whole arrangement.

Senior speed isn't typing faster. It's the shorter distance between seeing a problem and knowing which of the five plausible solutions will still look right in six months. The biggest schedule win available in software is the mistake you don't make, and that win compounds quietly for the entire life of the product.

What this buys you

The same people from the first call to the release build. Decisions in hours, not sprints. A team small enough that nobody can hide, senior enough that nobody needs to. That's not a philosophy — it's just what's left when you delete everything that only exists because a team got too big to talk to itself.