More engineers is not more output. Every experienced engineering leader knows this. Most CEOs and boards don't believe it until they've lived through a hiring binge that produced nothing — or worse, a hiring binge that shipped something that broke everything.
The relationship between engineering headcount and engineering throughput is not linear. It curves, peaks, and then reverses. The chart exists. I've reconstructed it from every organisation I've led or advised, and the shape is always the same.
The Curve
The throughput-versus-headcount curve for an engineering team looks roughly like this:
From 1 to 5 engineers, throughput scales close to linearly. Every person added is a genuine multiplier. Coordination is trivial; everyone knows what everyone else is doing; the system is small enough to hold in one head.
From 5 to 10, you start to see coordination overhead. You need standups, alignment meetings, code reviews, PR queues. The marginal throughput per new hire drops — but it's still positive. This is the "managed growth" zone.
From 10 to 20, the curve flattens sharply. Communication paths grow quadratically (n(n-1)/2 connections for n people). Every addition increases coordination cost. The 18th engineer might add 20% of the throughput of the 5th engineer at the same salary.
Beyond 20, the curve frequently inverts. New engineers spend more time in onboarding, review cycles, and alignment than they contribute in shipping. Senior engineers, who carry disproportionate throughput, get pulled into mentoring and unblocking, reducing their own output. Velocity drops. Bugs increase. The organisation is paying more to go slower.
Why This Keeps Happening
If the curve is this well-documented, why do organisations keep hiring into it? Three reasons, all structural.
The Headcount Signal Problem
Revenue, growth rate, and headcount are the three numbers most commonly cited as signals of startup success. Headcount is the most easily gamed and the least informative — but it looks like ambition. It impresses investors who don't look closely. It gives the CEO something concrete to point to in board meetings.
"We grew engineering from 12 to 35 this year" sounds like progress. It might be the most expensive mistake the company made all year.
The Deadline-As-Hiring-Trigger Fallacy
A product deadline is missed. Leadership's instinct: we need more engineers. The diagnosis is almost always wrong. Missed deadlines are rarely caused by insufficient headcount. They're caused by unclear requirements, excessive scope, technical debt that slows every change, poor prioritisation, or a delivery process that generates more interruptions than it prevents.
Adding engineers to a late project makes it later. Brooks' Law, articulated in 1975, is still violated daily by companies who should know better.
Headcount is a lagging solution to a process problem
Every time I've been called in to diagnose a "we need to hire more engineers" situation, the actual bottleneck has been scope discipline, requirements clarity, or technical debt — not raw headcount. Hiring into a broken delivery process just scales the chaos.
The Manager Incentive Problem
Engineering managers are often evaluated on team size. A team of 8 can feel less prestigious than a team of 15. Managers advocate for headcount because headcount, in many organisations, is the primary signal of impact and influence. This is a governance failure, not a malice problem — but the outcome is the same: teams grow beyond their optimal size because the incentives reward growth, not throughput.
What the High-Performers Do Differently
The organisations that get the most engineering output per salary euro share five practices that consistently separate them from the median.
1. Team Topology Over Headcount
Instead of asking "how many engineers do we need?", they ask "what is the optimal team structure for this product surface?" They run stream-aligned teams of 5–8 engineers, each owning a clearly bounded product domain with end-to-end accountability — from design to deployment to on-call. Coordination is minimised by architecture, not managed by process.
This is Team Topologies applied as operating principle, not as a book club discussion.
2. Senior Leverage Over Junior Volume
A team of 6 seniors consistently outperforms a team of 14 juniors. The senior team ships faster, produces less rework, makes better architectural decisions, and requires less management overhead. The fully loaded cost difference is smaller than it appears on the org chart — because the senior team's throughput-per-euro is dramatically higher.
The counterargument is that juniors grow into seniors. True. But growing juniors into seniors requires senior bandwidth to mentor — bandwidth that is frequently the scarcest resource in the organisation. Hiring juniors at scale without senior capacity to develop them is expensive in ways that don't show up until 18 months later.
3. Treat Technical Debt as a Headcount Cost
Every percentage point of velocity lost to technical debt is a hidden headcount cost. If your team is operating at 60% velocity due to debt — and most established engineering organisations are — you are effectively paying for 40% of your engineers to run in place.
The organisations that understand this invest 20–30% of engineering capacity in debt reduction as a standing practice, not as a quarterly sprint after someone complains loudly enough. A team of 8 operating at 90% velocity ships more than a team of 14 operating at 50%.
4. Measure Throughput, Not Activity
The organisations that grow headcount without results often lack visibility into what good throughput looks like. They count PRs merged, tickets closed, story points burned. These are activity metrics. They measure motion, not progress.
The metrics that matter: cycle time (from "work starts" to "in production"), deployment frequency, change failure rate, and mean time to restore. These are DORA metrics — well-documented, vendor-neutral, and genuinely correlated with business outcomes. Teams that improve their DORA metrics get more done with the same headcount, consistently.
5. Hiring Freeze as a Forcing Function
The most productive quarters I've overseen were often quarters with a hiring freeze. When you cannot add people, you are forced to ask: what is actually slowing us down? The answer is almost never "we don't have enough engineers." It's process overhead, unclear ownership, excessive WIP, or a system that's hard to change safely.
Fixing those things delivers more throughput than a hire would — permanently, not temporarily.
The Headcount-to-Outcome Table
| Engineering Org Size | Common Failure Mode | What Actually Fixes It |
|---|---|---|
| 1–5 | Too much context in one person's head | Documentation, on-call rotation |
| 6–12 | Delivery process not formalised | CI/CD, clear ownership, DORA metrics |
| 12–25 | Coordination overhead growing faster than output | Team topology redesign, Conway's Law alignment |
| 25–60 | Managers optimising for headcount, not throughput | Incentive redesign, DORA adoption, senior leverage ratio |
| 60+ | Platform engineering absent; everyone maintains infra | Dedicated platform team, internal developer experience |
The Conversation to Have With Your Board
The headcount debate usually starts when a CEO or board asks why engineering isn't going faster. The right answer is almost never "we need to hire more." But "we need to fix our processes" is hard to say to a board that is accustomed to headcount as a proxy for investment.
The framing I use: throughput per engineer. If your team is shipping 2 features per engineer per quarter and the industry benchmark for comparable organisations is 5–7, the gap is not headcount — it's process, architecture, or technical debt. Hiring more engineers at the current throughput rate costs 2× as much to achieve the same output you could get by fixing the underlying constraints.
That is a board-level argument. It respects their instinct to invest while redirecting toward the right lever.
The best engineering leaders I know are constantly reducing headcount needs
Not by cutting people — by making each person dramatically more effective. Better tooling, less technical debt, clearer scope, faster feedback loops. The goal is to do more with the same team, not to justify the team you already have. That's what senior engineering leadership actually looks like.
A Framework for the "Do We Hire?" Decision
Before approving any engineering headcount, run through this decision sequence:
- Is delivery slow because of scope, not capacity? If you cut 30% of the roadmap, would the remaining work get done faster? If yes, the problem is prioritisation.
- Is there a process bottleneck? Where is WIP accumulating — design handoff, code review, testing, deployment? Fix the bottleneck before adding capacity behind it.
- What is current velocity versus theoretical maximum? If cycle time is 3 weeks and 60% of that is waiting (blocked, in review, in QA), you can double throughput without a single hire.
- What is your senior-to-junior ratio? If it's below 1:2, adding juniors creates more work for seniors than it relieves.
- After all of the above — if throughput is still capacity-constrained, then hire. But hire against a specific bottleneck, not against a vague sense that more would be more.
The decision logic as a flow:
The curve doesn't lie. Engineering output per head decreases as teams grow. The exception is when growth is accompanied by deliberate team topology design, strong technical debt management, and process investment. Most organisations do none of the three. They hire, watch velocity drop, and blame the engineers.
The chart ends the debate. The question is whether you're willing to act on what it shows.
Engineering effectiveness — throughput, team design, technical debt strategy — is one of the areas I focus on directly with founding and executive teams. If you're spending more on engineering salaries than you're comfortable with for the output you're seeing, let's talk — book a 30-minute discovery call.