What Doubles When You Double Headcount

Two people join the same team four months apart. They never sit in a meeting together. Neither reads the other’s work before shipping. In their third week, both build the confirmation flow for the same feature, from two different assumptions about what “done” means, and neither one is wrong exactly, they just answered a question that was never actually decided. Nobody notices until a third person, onboarding six weeks later, opens both and asks which one is current.

That’s not a hiring problem. Read separately, both hires look reasonable, maybe even good. The pattern only shows up once you stop looking at the individuals and start looking at the decision.

Why More People Doesn’t Mean More Speed

Here’s what I think is actually happening, and I want to be upfront that this is reasoning rather than something I’ve measured directly. Growth plans get built around headcount. Ten more engineers, five more designers, a PM per pod. What they rarely account for is that every new hire isn’t just adding capacity, they’re also adding a new person with standing to make an existing, unresolved call. If the call was never actually made, and it usually wasn’t, adding people doesn’t distribute the work. It multiplies the number of times that specific decision gets made differently.

The Math Nobody Runs

A team of five carrying one open question has a small, contained problem. Whoever hits it next probably guesses close enough to what the last person did, because there aren’t many other people around to guess differently. A team of thirty carrying the same open question has an expensive one, not because the question got harder, but because there are now thirty people who might answer it, and some meaningful fraction of them will. Nobody chose to make the problem six times worse when they made the sixth hire. It just followed from not deciding the thing the first time.

What the Hiring Plan Never Prices

This is where I’d expect most growth plans to be quietly wrong. They price the cost of a hire in salary and ramp time. What they don’t price is the number of live, unresolved decisions that hire is now empowered to answer on their own, because nobody assigned that cost to anyone. It shows up later, in a sprint that takes longer than it should for reasons nobody can quite name, or in a procurement call where two screens of the same product answer the same question two different ways.

The instinct, once this becomes visible, is usually to add process. More review, more sign-off, another meeting where decisions get checked before they ship. I’d expect that to make it worse, not better, because it adds friction to every decision instead of removing the need to make the contested ones more than once. The fix I’d argue for is smaller and less satisfying to announce: find the handful of decisions that actually get remade most often, decide them once, put the answer somewhere anyone new can check without asking, and stop there. Not a full system. Not a governance committee. The three or four calls that are currently being answered a different way by whoever’s in the room that week.

What that buys, if the reasoning holds, isn’t speed. It’s that headcount stops being the thing that quietly prices in how slow the product already was. Ten new hires into a team with its real decisions made once behave like ten new hires. Ten new hires into a team still carrying open questions behave like ten new arguments waiting to happen, on a schedule nobody can predict and a bill nobody assigned to the hiring plan.

Worth checking before the next round of hiring lands: how many of your current decisions would two people, asked separately, actually answer the same way.