Stop Hiring. Your Team Size Is Killing Your Product.

You’re in your third meeting of the day. The stand-up ran 40 minutes, and no one knows what the other team is doing. You haven’t shipped a line of code in weeks. And leadership just announced another round of hiring—because clearly, the problem is we don’t have enough people.

Sound familiar? We’ve all been there. The bigger the team, the slower everything moves. It’s not your imagination. It’s the coordination tax. Every new person adds a node to the communication graph, and that graph grows quadratically while your velocity grows linearly—if you’re lucky.

We’re told that adding headcount is how you go faster. That’s why Amazon famously caps teams at two pizzas. But the two-pizza rule isn’t about pizza—it’s about communication. Yet we keep staffing up, especially in big companies.

But here’s the uncomfortable truth: it’s not the number of people that kills your product—it’s who controls the information and the money.

When a few people hoard decisions, they become the bottleneck. Every change needs their sign-off. Every proposal needs their budget approval. Every API modification needs their blessing. That’s the real killer.

So why do we keep hiring? Because headcount is a proxy for status, not a strategy for shipping. A bigger org chart means a bigger empire. Managers get promoted based on team size, not on how fast they deliver. So they hire more, even when it slows the product.

I’ve seen it firsthand: a product with 15 engineers where the CTO had to approve every API change. He was a nice guy, but he was the bottleneck. The team could have shipped twice as fast if they had autonomy. But then the CTO would have felt less important.

So let’s stop pretending the problem is \”size.\” The problem is power. And until we reward leaders for shipping great software instead of commanding large armies, this will keep happening.

If you’re leading a team, ask yourself: do you need more people, or do you need to decentralize? If you’re an engineer, stop blaming the team size. Start questioning who controls the information.

The best software is built by small, trusted teams with real ownership. The rest is just a coordination tax that inflates your org chart and sinks your product.