"Engineering Efficiency" Is the Wrong Frame

Efficiency is a ratio: output over input. It's a genuinely useful concept in settings where both terms are stable and comparable.

Software development has neither. That isn't a complaint about measurement being hard — it's a statement about what the ratio would have to mean, and it explains why programmes framed as efficiency drives keep producing decisions their sponsors regret.

Where the analogy comes from and why it breaks

The frame is borrowed from manufacturing, and the borrowing is usually unexamined.

Steel production is a well-defined, largely deterministic process. You can price inputs — tools, plant, raw materials, labour — measure finished goods, and compare productivity across plants and countries. The comparison is meaningful because the output is identical wherever it's made.

Software output isn't identical. A thousand lines that eliminate a subsystem and a thousand lines that add one are opposite in value and identical in the count. The single most valuable change an engineer makes in a quarter might be a two-line fix, a deletion, or a design conversation that stopped a project.

The input side fails too. Two engineers on the same team are not interchangeable units of the same resource, and neither are two hours from the same engineer — an hour of uninterrupted work and an hour fragmented across four meetings produce different amounts of anything.

Neither term of the ratio holds. What you get from computing it anyway is a number that moves, which is worse than no number, because it looks like information.

Why the frame keeps returning

Not because executives are naive. Because engineering has failed to offer an alternative.

Kent Beck and Gergely Orosz put this plainly in 2023: CEOs and CFOs are frustrated by engineering leaders who answer measurement questions by saying software is too nuanced to measure. Sales reports on pipeline and conversion. Recruiting reports on time to hire and offer acceptance. Engineering, often the largest cost centre in the building, says the question is malformed and offers nothing in its place.

That vacuum is what gets filled, and it's why a consultancy framework promising measurable developer productivity found buyers at nearly twenty companies before the field pushed back.

Any argument against the efficiency frame that stops at "you can't measure this" deserves to lose, and does.

What the frame does in practice

It makes deletion look like negative work. Removing a service three teams were separately maintaining is one of the highest-return actions available in most organisations, and every efficiency ratio records it as reduced output.

It taxes collaboration. If your ratio depends on your output, helping a colleague costs you. The behaviour that most improves team performance becomes individually irrational.

It rewards volume at exactly the wrong moment. AI assistants made producing code substantially cheaper without making producing the right code cheaper. Any frame anchored on output responds to that by reporting improvement while maintenance burden rises — which is what the evidence shows happening.

It relocates rather than removes work. Efficiency drives typically compress one stage of the process. Time saved writing code reappears in review. The ratio improves, the system doesn't.

The frame that works

Not "how much do we produce per unit of input" but "where does work get stuck, and is what we ship worth having."

Two questions, both answerable, both actionable.

The first is a flow question. Where does work queue, wait, or get redone. DORA answers this at the delivery layer, DevEx at the friction layer. Both are diagnostics rather than scores, and both point at something a team can change.

The second is an outcome question. What shipped, what changed for users, what the business got. This is the half that effort-and-output frameworks skip, and it's the half executives actually care about once you offer it.

Together they give a CFO a better answer than an efficiency ratio would. Not a single number — but a defensible account of where the money went and what it bought, which is what the question was really asking.

What to say when asked for the ratio

Don't refuse. Reframe, then deliver.

We can't produce a meaningful output-per-input figure, because the output isn't uniform — deleting a service and adding one are opposite in value and identical in any count. What we can give you is where delivery is constrained, what we shipped this quarter, what it changed, and what it cost. Here it is.

Then have it ready. The reframing only works if the alternative is on the table, and the most common failure in this conversation is engineering leaders who make the argument and stop.

Frequently asked

Isn't this just resisting accountability? The opposite, if done properly. It replaces an unanswerable question with two answerable ones and commits to reporting on both. Refusing without the alternative is the version that deserves the accusation.

What about efficiency in a narrow sense — build times, CI cost? Entirely legitimate. Those are well-defined processes with stable inputs and outputs, which is precisely why the ratio works there. The frame fails when applied to development as a whole.

Doesn't DORA measure efficiency? No. DORA measures flow and stability in a delivery system. It has no input term, which is what stops it from being an efficiency ratio, and its authors have been clear it was never a productivity measure.

How do we handle a mandate that uses the word? Adopt the goal, replace the instrument. Nobody asking for engineering efficiency wants a ratio; they want to know the money is well spent. Answer that question and the terminology stops mattering.