← All posts

Why Hiring More Engineers Can Slow Your Startup Down

Why Hiring More Engineers Can Slow Your Startup Down

The fastest way to slow your startup down is to hire more engineers.

That runs against every instinct. You raised money to grow. More engineers means more output, more roadmap, more of everything you're behind on. So you hire, and somehow the team gets slower. Not a little. Noticeably.

I've watched this happen, and the founder almost never sees the real cause, because the real cause is them.

The story

One founder I worked with set out to grow the engineering org. The plan was sound on paper: more funding, bigger ambitions, so bring in more people to build faster. They hired.

And delivery slowed down. The new engineers were good. The roadmap didn't move any quicker. If anything, things that used to ship in a week now took two, and nobody could quite say why.

The founder's read was that the new hires weren't pulling their weight. That's the natural conclusion, and it's almost always wrong.

What actually changed

Here's what nobody warns you about when you scale a team.

With a small team, you ran everything through yourself. You handed out the work. You talked to each engineer directly. You knew every decision because you were in every decision. At four people, that works beautifully. You're the fastest router of information in the company, and the team is small enough that you can keep up.

At twelve people, the exact same behaviour quietly kills you.

Because every decision still routes through one person. You. The team sits waiting on your call, and you cannot context-switch fast enough to feed all of them. One engineer waits an hour for an answer that takes you thirty seconds, except you're in three other conversations, so the hour becomes half a day. Multiply that across twelve people and the whole team spends more time waiting than building.

You've become the bottleneck. Without meaning to, and usually without seeing it. The bigger the team gets, the worse the jam, because you've added more people who all need the same scarce resource: your attention.

Why it's so hard to see

The cruel part is how it feels from the inside.

It never feels like you're the bottleneck. From where you sit, you're working flat out, answering questions as fast as they come, making decisions all day. You feel like the hardest-working person in the building. What you can't see is the queue forming behind every one of those decisions.

So the problem presents itself as the opposite of what it is. It looks like the new hires are slow. It looks like they need more direction, more oversight, more of your input. And the natural response to that, gripping tighter and inserting yourself into more decisions, is precisely the thing making it worse. You double down on being the bottleneck at the exact moment you need to stop being one.

How it usually ends

The founder I worked with couldn't let go. They'd built the company by being across every detail, and that instinct had always served them. Handing decisions to other people felt like losing control of the thing they cared about most.

Eventually the frustration won. They cut the team back to a handful, because a small team they could personally run at least felt productive again. And it did feel better. It felt safe, familiar, back in control.

It was also a dead end. They'd optimised for how it felt to run the company rather than for the company being able to grow. Shrinking the team resolved the discomfort and capped the business at whatever one person could personally coordinate.

That's the trap in full. The bottleneck is invisible, the symptoms point at the team, and the fix that feels safest is the one that guarantees you never scale.

The actual fix

Growth isn't a hiring problem. It's an org problem, and it's one you solve before you hire, not after.

The core move is to get decisions flowing without you in the middle. That means a few concrete things.

Decide which decisions genuinely need you and which don't. Most don't. The ones that do are usually about direction and priorities. The ones that don't are the day-to-day technical and delivery calls that you've been holding onto out of habit, not necessity.

Give people clear ownership of an area, and the authority to make calls within it without checking with you first. Ownership without authority is just delegation theatre, and engineers see through it immediately.

Make the priorities clear enough that people can make good decisions without you in the room. Most founder-bottlenecks aren't really about the founder hoarding decisions. They're about the founder being the only person who knows what actually matters this week. Fix that and half the queue disappears.

Do this before you hire. Adding people to an org that still routes everything through one person doesn't buy you more capacity. It buys you a longer queue.

Or don't hire at all

There's a version of this where the honest answer is that you don't need a bigger team yet.

Sometimes the slowness founders try to fix with hiring is really a coordination problem, and more people make coordination harder, not easier. If your current team is fast when you're out of their way and slow when you're in it, hiring won't help. Fixing how decisions flow will.

The uncomfortable truth is that a bigger team is often a way of avoiding the harder work of building an organisation that doesn't depend on you. Do the harder work first. Then, if you still need the people, hire into a structure that can actually absorb them.

The point

If you scale your team and everything slows down, resist the instinct to blame the hires. Look at how many decisions still route through you.

The bottleneck is rarely the people you brought in. It's usually the one you can't see, because you're looking out from inside it.

Working through a technical decision like this?

Book a fit call