The Efficiency Multiplier

You're in the quarterly board meeting. The roadmap is slipping. Someone — a board member, the CEO, occasionally you — says the clean thing: "We're at five engineers. Let's get to eight by end of quarter and unblock shipping." Heads nod. Recruiting gets a budget. The slide moves on.

Three quarters later, you're shipping less than you were at five. You cannot explain this on a spreadsheet without sounding defensive. That's the problem worth naming.

The Accounting Logic That Breaks in Code

Headcount math works for assembly lines because each worker's output is largely independent of the others. Software doesn't work that way, and it hasn't since Fred Brooks wrote The Mythical Man-Month in 1975. Brooks's original observation — adding people to a late project makes it later — has survived fifty years of refutation attempts because the underlying physics haven't changed. Coordination cost grows with the square of team size. Shared context doesn't transfer at hiring speed. The nine-women-one-baby line is a cliché for a reason.

The DORA research program at Google Cloud has spent a decade measuring what actually moves software delivery performance. Team size isn't on the list of high-performing indicators. Deploy frequency, lead time, change failure rate, and restore time are — and those are governed by architecture, tooling, and decision quality, not by how many seats are filled.

Put yourself in the chair of a senior engineer on a five-person team the week three new hires start. You're now the onboarding surface for three people who each need two months of context before their commits stop introducing regressions. Your own work slows by roughly a third. Your architectural throughput — the decisions that compound for years — drops closer to zero. You'd be the first person to tell the CEO this, if anyone were asking you.

Where Seniority Actually Shows Up

Will Larson's writing at StaffEng documents the specific shape of senior engineering impact: multiplier moves rather than linear ones. A staff engineer who spots a one-line change to a shared library that eliminates a whole category of production bugs has produced a quarter's worth of team output in an afternoon. That's not hypothetical — it's the category of work Larson spends most of his book cataloguing, because it's the category junior engineers structurally can't do yet.

At Brandfolder, the platform that Smartsheet acquired for $155M in 2020, asset search latency was the pattern that gated the product. The team's early architectural decisions around indexing and retrieval drove 40% team efficiency gains and 90% faster asset lookups — numbers that shipped to customers, not just dashboards. None of that came from adding engineers. It came from one or two people making the right calls early, and the rest of the team inheriting compounding leverage from those calls for years.

The same pattern shows up in the inverse. Martin Fowler has written for two decades about what bad early architecture does to a codebase: every subsequent feature takes longer, every new hire takes longer to become productive, and eventually the team is spending most of its time servicing the debt rather than shipping. The team didn't get slower. The substrate did.

The Leverage Gap

Here's the pattern we'd give you a handle for: the leverage gap. The difference between a senior and a junior engineer isn't speed on the same task — it's whether the task they choose to do has any leverage at all. A junior engineer asked for "real-time collaboration" builds a WebSocket server. A senior engineer asks which library the rest of the industry uses for this exact problem, finds Yjs or similar, and ships in days what the greenfield version would have taken months to stabilize. Same ticket. Different choice of task.

The gap is hardest to see because it lives in the work that didn't happen: the service that wasn't built from scratch, the race condition that was spotted in review rather than in production, the API that was designed for three future consumers rather than one current one. You can't put "problems avoided" on a velocity chart. Which is part of why leadership teams routinely stop paying for the engineers who produce that output, and routinely overpay for the engineers who produce the opposite.

Charity Majors has a line worth sitting with: engineering management is a career, not a promotion. The same is true one rung down. Staff engineering isn't "senior engineer but more so." It's a different job, with different leverage, and hiring three more junior engineers produces none of it.

The Reframe

You don't have a headcount problem. You have a leverage problem dressed up as a headcount problem.

This is what the spreadsheet refuses to show you. Three engineers at $120K produce a specific kind of output: volume on well-scoped tickets, in a codebase someone else designed, with architectural decisions someone else made. One staff engineer at $220K produces a different kind of output: the scoping, the codebase design, and the decisions that let any number of other engineers ship without tripping over each other. The first cost buys you labor. The second buys you leverage. They look similar on the payroll. They don't compound the same way.

Gergely Orosz at The Pragmatic Engineer has documented this pattern across dozens of engineering orgs: the companies that ship durably tend to have a denser concentration of senior judgment, not a larger total headcount. The ones that struggle have often solved the wrong problem by adding bodies to a team whose real bottleneck was a few missing architectural calls that nobody on staff had the seniority to make.

So when the board meeting comes around and someone reaches for the headcount lever, the question worth asking out loud is: what specifically are we expecting three more engineers to do that one more staff engineer couldn't do better? If you can answer that, hire the three. If you can't, the recruiting budget is paying for the comfort of motion, not the outcome you actually need.

The slide deck version of your roadmap is probably accurate about what needs to ship. It's almost certainly wrong about who needs to ship it. That's the conversation worth having before the next board meeting — and it's the one we tend to step into.