Why adding engineers can make a scaling problem worse

The instinct is understandable: velocity is down, the roadmap is slipping, so hire more engineers. It's the lever every board understands and every founder can pull without admitting anything uncomfortable about the system underneath. It's also, past a certain point, the lever that makes the problem worse — not because the new engineers are bad, but because you're adding throughput to a pipe that was never the bottleneck.

Before you open six reqs, it's worth being specific about which of these you actually have.

1. A coordination problem, not a capacity problem

If the real constraint is that every feature touches the same three services, and every PR against those services needs review from the two people who understand them, adding engineers increases the number of PRs waiting on those same two people. Throughput didn't go up. Queue depth did. The fix is decoupling the architecture or spreading the knowledge — not hiring into the queue.

2. A decision-latency problem

Teams that feel "slow" are often teams that are fast at writing code and slow at deciding what to write. If product requirements bounce twice a sprint, or nobody can approve a scope cut without a founder in the room, more engineers means more people idle at the same decision bottleneck, just billed at a higher burn rate.

3. An onboarding-tax problem

Every new engineer is, for the first two to four months, a net draw on the senior engineers' time — reviewing their PRs, answering their questions, explaining the parts of the system that aren't written down anywhere. If you hire five people into a team of twelve, you've temporarily reduced the effective capacity of your best people during the exact window you needed them most. This is normal and recoverable. It's just not immediate, and boards that expect it to be immediate get a false read on whether the hire "worked."

4. An actual capacity problem

Sometimes it really is this — the backlog is well-scoped, decisions are getting made promptly, the architecture supports parallel work, and there simply aren't enough hands. This is the good case. It's also, in my experience, the least common of the four when a founder first raises "we need to hire more engineers" as the fix.

How to tell which one you have

Look at where work actually sits idle, not where it's being worked on. Pull the last ten tickets that took longer than expected and ask what they were waiting for at each stage — a review, a decision, a piece of context that lived in one person's head, or genuinely just an available engineer. Coordination and decision-latency problems show up as long waits between short bursts of work. A real capacity problem shows up as continuously busy engineers with a backlog that only grows.

If the diagnosis is unclear, that's usually worth an outside read before the reqs go out — the hiring decision is expensive to reverse and the wrong one buys you a bigger version of the same bottleneck. See how a quality architecture engagement is scoped, or the ongoing advisory retainer if this is a recurring pattern rather than a one-time diagnosis.

Subscribe: RSS