Everyone knows that adding people to a late project makes it later. It's one of the oldest results in software, almost fifty years old now, and it's still true, and we still ignore it. The reason we ignore it is that the intuition runs the other way. More hands should mean more work done. With physical labor that's roughly true. With building, it's roughly false, and understanding why tells you a lot about how to actually ship things.
The problem is that the work of a team isn't just the work. It's the work plus the coordination. And while the work grows linearly with the number of people, the coordination grows with something closer to the square. Three people have three relationships to keep in sync. Six people have fifteen. The output you added is linear; the overhead you added is quadratic. At some point the second curve overtakes the first, and every new person you add makes the team slower.
What this looks like from the inside is subtle, which is why it fools people. Nobody is lazy. Everyone is busy. The calendars are full. But a growing share of that busyness is the team talking to itself — meetings to align, documents to hand off, status updates to keep everyone current. The work of building gets crowded out by the work of staying coordinated, and the strange thing is that it feels more professional, not less.
A small team avoids almost all of this, and the savings are larger than they look. Three people who trust each other can hold the entire system in their heads at once. They decide things in the hallway. They don't write the document because they don't need the document; the knowledge is already shared. What a big team schedules a meeting to resolve, a small team resolves in a sentence, and then keeps moving.
I think the reason this is underrated is that the costs of a big team are invisible and the costs of a small one are visible. When a small team is overloaded, you can see it: things are waiting, people are stretched, the backlog is obvious. When a big team is slow, the slowness is distributed and deniable. Everyone is working hard. The org chart looks healthy. It's just that nothing ships, and no single person is responsible for the nothing.
There's a temptation, when a small team is struggling, to fix it by hiring. Sometimes that's right. But often the struggle isn't a shortage of hands, it's a shortage of focus, and adding people makes focus harder, not easier. You've traded a problem you can see for one you can't. The honest move is frequently to do less, not to hire more — to cut the scope until the small team can hold it.
The practical lesson is to stay small far longer than feels comfortable, and to treat every new hire as a real cost and not just a benefit. Before you add someone, ask what coordination they'll create, not just what work they'll do. The best early teams I've seen were almost suspiciously small for what they produced, and they guarded that smallness on purpose, because they understood it was the source of their speed.
None of this means small is always better. At some scale you genuinely need more people, and the coordination cost is worth paying because the work simply can't be done by three. But that point arrives later than anyone's instinct says, and most teams cross it not because they had to, but because growing felt like progress. Headcount is the easiest metric to move and the easiest to mistake for momentum.
If you want to ship fast, the cheapest lever is almost never another person. It's fewer people who share more context, pointed at a smaller problem. That's an unsatisfying answer, because it can't be bought, only built. But it's the one that holds up, year after year, against every reorg that promised the square root of the truth.