Why Unit Economics Matter for Engineering Leaders

Engineering is expensive. In most technology companies, engineering is the largest operating expense - often consuming 30-50% of total headcount cost. Despite this, most engineering organisations cannot answer a basic question: what are we getting for that money?

This is not a question about individual engineer productivity. That is a separate and largely misguided conversation. This is a question about whether the engineering system - the whole organisation, with its infrastructure, tooling, processes, and people - is becoming more efficient over time, and whether the investment is tracking to the value it creates.

Unit economics is the practice of expressing cost relative to a unit of output or outcome. It forces precision. It creates comparability across time. And it gives engineering leaders a way to have investment conversations with finance and leadership that go beyond total spend figures.

The uncomfortable truth is that most engineering organisations do not track unit economics because the calculation requires assumptions, the numbers are imprecise, and the results can be awkward. These are exactly the reasons you should track them.

The Key Ratios

Cost Per Active User

Total engineering cost (or total infrastructure cost, depending on what you are measuring) divided by monthly active users.

This is one of the most useful signals of engineering efficiency at scale. If you are spending the same to serve twice as many users, your cost per user has halved - that is a real efficiency gain. If your user base is flat and your engineering cost is growing, your cost per user is rising - that demands explanation.

The calculation: total loaded engineering cost for the period, divided by monthly active users for the same period. "Loaded cost" means salary plus benefits plus contractor spend plus tooling plus infrastructure - everything it costs to run the engineering function.

The limitation: this ratio does not distinguish between growth and inflation. If your user base grows because you acquired a company that brought users, not because your product is working, the ratio flatters you. Context always matters.

Cost Per Deployment

Total engineering cost divided by number of deployments in a period.

This ratio is controversial and should be used carefully. Its value is as a directional signal: are we getting more deployments per pound of engineering investment over time? Organisations that invest in deployment automation, CI/CD pipelines, and developer experience typically see their cost per deployment fall as the investment matures.

The risk is perverse incentives. If teams believe they are being measured on cost per deployment, they will either deploy more trivial changes to drive the denominator up, or resist the measurement entirely. Use it as a leadership-level trend metric, not as a team-level performance metric.

Cost Per Feature

The most contested and least precise of the unit economics metrics. The calculation is: total engineering cost divided by number of significant features delivered.

The problem is defining "significant feature." A feature in one organisation is a bug fix in another. Teams will game any definition you create. The metric is subject to enormous judgement calls.

Despite this, there is value in the exercise of trying to calculate it - not because the number will be precise, but because the conversation forces clarity about what counts as output and whether that output is growing proportionally to investment.

A more defensible version: track the cost of delivering a defined unit of work (a story point, a completed initiative, a deployed capability) over time within a single team, using a consistent definition. This gives you a trend for that team rather than a cross-organisation comparison.

Engineering Efficiency Ratios

Beyond cost-based ratios, there are efficiency ratios that give a picture of how well the engineering system is functioning.

Ratio of feature work to maintenance work: what percentage of engineering capacity goes to new capability versus maintaining existing capability? If this ratio is deteriorating - more maintenance, less feature work over time - it is a signal that technical debt is accumulating and consuming capacity.

Developer time on high-value work: a cruder version of the above. What proportion of developer time goes to work that directly delivers business value versus tooling, meetings, toil, and overhead? Studies consistently find this number is lower than engineering leaders expect. Measuring it creates pressure to improve it.

Deployment frequency and lead time: these are DORA metrics, covered separately, but they are also unit economics in a sense - they measure the throughput of the engineering system relative to its inputs.

Using Unit Economics to Justify Platform Investment

One of the most valuable applications of unit economics is making the investment case for platform work. Platform investment is notoriously hard to justify because the benefits are diffuse and delayed - faster builds, easier deployments, better observability do not translate directly into a revenue number.

Unit economics gives you a bridge. If your deployment lead time is 48 hours and you can demonstrate that bringing it to 4 hours would save X engineer-days per quarter, you can translate that into a cost saving. If your infrastructure cost per user is rising quarter-on-quarter and platform investment would arrest that trend, you can model the cost avoided.

Building the Case

Step one: establish the baseline. What is the current cost per unit (per user, per deployment, per whatever metric you choose)? What is the trend over the last four to eight quarters?

Step two: model the improvement. If you invest in the platform capability, what does the unit economics metric do? Be conservative. Show the expected improvement, the assumptions behind it, and the timeline to realise it.

Step three: quantify the alternative. What happens if you do not invest? Does the metric continue to deteriorate? What does that cost over the same timeline?

This framing - investment versus no-investment comparison over time - is more compelling to finance teams than a feature comparison, because it speaks to cost efficiency rather than capability.

The Limits of Unit Economics

Unit economics tells you about efficiency. It does not tell you about effectiveness.

A team can become more efficient at delivering the wrong things. Cost per deployment can fall while none of the deployments produce business value. Cost per user can fall while user satisfaction deteriorates. Efficiency is not the same as impact.

Unit economics should sit alongside, not replace, outcome measures. You want to know whether the cost per user is falling (efficiency) and whether users are retained, satisfied, and generating revenue (effectiveness). The two together give you a meaningful picture.

Unit economics also cannot capture everything that engineering does. Security investment, compliance work, reliability investment - these do not show up as features or users, but they matter. Be careful not to create incentives that deprioritise this work because it does not improve the visible ratios.

The precision problem is real: most unit economics calculations in engineering are estimates built on assumptions. The value is in the trend and the direction, not the absolute number. If your cost per user has fallen 15% over two years, that is meaningful even if the exact figure is imprecise. If it has risen 30%, that is a signal even if the methodology is imperfect.

Introducing Unit Economic Thinking

The way to introduce unit economics to an engineering organisation is gradually and conversationally, not as a new measurement regime imposed from above.

Start with one ratio. Cost per active user, or infrastructure cost per deployment - something specific and calculable. Calculate it for the last eight quarters. Present the trend at an engineering leadership meeting. Discuss what it means and what might explain it.

Do this for two or three cycles before widening the scope. Build familiarity with the concept before building a full measurement framework. If engineers experience unit economics as a tool that creates insight and drives good conversations, they will engage with it. If they experience it as a management control mechanism, they will resist it.

The goal is to develop an engineering organisation that thinks about financial efficiency as naturally as it thinks about technical quality. These are not in tension - efficient engineering is usually also good engineering, and vice versa.