Engineering Economics

Introduction

A VP of Engineering presents a proposal to replace the company’s batch processing infrastructure. Current infrastructure runs nightly jobs that take six hours. The replacement would run streaming jobs with near-real-time output. The cost: fourteen engineer-weeks to build. The benefit: customers see fresher data.

The board asks the natural question: is fourteen engineer-weeks worth fresher data? The VP cannot answer, because the proposal was framed as an engineering improvement, not an economic decision. Nobody had asked what fresher data is worth to a customer. Nobody had asked what fourteen engineer-weeks would cost in opportunity — what else could be built with that capacity. Nobody had asked what the streaming infrastructure would cost to operate per month at 2x current data volume.

Engineering decisions are economic decisions. The vocabulary of engineering economics — cost of delay, total cost of ownership, investment return — converts engineering proposals from capability arguments into decision inputs that non-technical stakeholders can evaluate alongside the organisation’s other investments.

The Decision

Any significant engineering investment should be evaluated on three economic dimensions: what it costs to build and operate, what the cost of not building it is, and what it costs as the system scales. These three dimensions define the economic case. Without all three, the investment cannot be compared to alternatives.

What the Frameworks Say

F4 (Tradeoffs) provides the frame for investment decisions: every engineering investment is a choice between two or more uses of engineering capacity, each with different costs, different returns, and different timelines. Naming the tradeoff — we are investing in streaming infrastructure instead of customer-facing feature X — makes the economic comparison possible.

F9 (Empirical Grounding) provides Little’s Law: throughput equals arrival rate times residence time (L = λW). In capacity planning, this law constrains the economics: if residence time (latency) increases, throughput decreases without adding capacity. Capacity planning that does not model latency growth will underestimate the infrastructure cost at scale.

T12 (Tradeoffs) frames the meta-decision: engineering economics is the vocabulary that makes technical tradeoffs legible to non-technical decision-makers. AT2 (Latency vs Throughput) is not just a systems tradeoff — it is an economic tradeoff. Higher throughput means lower cost per unit at scale. Lower latency means higher infrastructure cost for the same throughput. The economic consequence of AT2 is a cost curve, and the cost curve is what the board can evaluate.

The Forces at Play

The cost-of-delay curve varies by project type, and treating all three as linear produces systematically wrong prioritisation decisions. Feature delay is linear and predictable. Security delay is exponential because the cost is near-zero until the vulnerability is exploited, then catastrophic. Compliance delay is flat until the deadline, then a cliff — the fine or penalty arrives in full regardless of how close to the deadline the work was completed. Engineering leaders who prioritise by backlog age or engineering preference instead of cost-of-delay shape are optimising against the wrong curve.

The force working against engineering economics is the technical framing of engineering decisions. Engineers are trained to reason about technical properties — latency, throughput, consistency, availability — not economic ones. The translation to economic language feels like simplification, which engineers often resist. But the board cannot evaluate a latency improvement; they can evaluate a cost reduction per transaction at 2x volume.

Cost of delay is the most important concept in engineering economics that most engineering organisations do not use. Cost of delay is the value lost by not shipping something per unit of time. A feature that would generate ten thousand euros of monthly recurring revenue has a cost of delay of ten thousand euros per month. A three-month delay costs thirty thousand euros. An engineering investment that reduces the delay from three months to one month is worth twenty thousand euros. Without cost of delay, every engineering decision is evaluated against the cost to build, not against the value of building.

The Options and Tradeoffs

Engineering investment decisions have a standard economic structure. The investment cost is the engineering weeks to build, plus the infrastructure cost to operate, plus the maintenance overhead over the system’s lifecycle. The return is the value generated — either directly (revenue, cost reduction) or indirectly (velocity improvement, risk reduction). The time to return is the lag between investment and value.

The cost of operating systems is systematically underestimated because it is distributed across multiple cost centres that are rarely aggregated. Compute and network costs are visible in the cloud bill. People costs — on-call load, incident response, maintenance time, the cognitive overhead of understanding a complex system — are not on the cloud bill but are often larger than the infrastructure costs.

The board presentation has a three-number structure: current cost, projected cost at 2x scale, cost of investment required to change the cost curve. A streaming infrastructure investment that costs fourteen engineer-weeks and reduces batch processing infrastructure cost by forty percent per month at 2x data volume has a breakeven point, and that breakeven point is calculable. The calculation is not complex. Presenting it changes the conversation from “should we invest in streaming?” to “when does the streaming investment pay off, and do we believe we will reach 2x scale within that horizon?”

AT2 (Latency vs Throughput) is an economic decision at scale. Lower latency typically requires more infrastructure — more replicas, more cache capacity, more compute. Higher throughput without latency constraints is cheaper per unit. When the business model requires low latency — a trading system, a real-time recommendation engine — the economic cost of latency is a product requirement, not an engineering preference.

What Great CTOs Do

Technical leaders who communicate engineering economics well translate technical decisions into cost curves before presenting them. They do not present the streaming infrastructure investment as “better architecture” — they present it as “current cost at 1x data volume, projected cost at 2x, projected cost with streaming at 2x, breakeven at month nine given projected growth.”

They maintain a cost model for the engineering organisation’s most significant infrastructure investments — not a spreadsheet of every cloud resource, but a model that makes visible how costs scale with product growth. A cost model that cannot explain a 3x cost increase when data volume doubled is a model that has missed a scaling assumption.

The best technical leaders use cost of delay explicitly when prioritising engineering investments. The question is not “which of these projects is most technically interesting?” or “which has been on the backlog longest?” — it is “which of these has the highest cost of delay?” The cost of delay calculation is imperfect but directional: it consistently surfaces the investments that are costing the business most per week by not being done.

What Goes Wrong

The most common engineering economics failure is the invisible cost of maintenance. Teams invest in building capabilities, account for the infrastructure cost, and do not model the ongoing engineering overhead — the time spent on incidents, the time spent on updates, the cognitive load of understanding the system in a high-turnover environment. FM3 (Unbounded Resource Growth) in the maintenance dimension: every capability added is a permanent maintenance obligation that does not appear in the investment proposal.

The second failure is cost of delay in reverse: prioritising work by engineering preference or backlog age rather than economic urgency. A feature with a ten-thousand-euro monthly cost of delay that has been in the backlog for six months has cost sixty thousand euros of delay. A feature with a one-thousand-euro monthly cost of delay that ships this sprint costs one thousand euros of delay. The backlog ordering by engineering preference has cost the organisation fifty-nine thousand euros.

FM6 (Hotspotting) at the economic level: infrastructure costs that are concentrated in a small component — a single database, a single service, a single data transfer path — make the cost curve non-linear. When the hot component reaches its capacity ceiling, the cost to continue scaling jumps discontinuously. Engineering organisations that do not model their cost hot spots are surprised by cliff-edge cost events that could have been predicted from the cost model.

Reflection Questions

These questions are most useful when answered in writing before a team discussion, or when used as a retrospective prompt after a decision has been made.

1. What is the cost of delay of the most important item currently in your engineering backlog? Can you calculate it in currency per month?
2. Pick the three most expensive systems your team operates. For each: what is the current monthly cost, and what is the projected cost at 2x current load? Has the scaling curve been modelled?
3. What engineering investment has your team made in the last twelve months where you could now calculate the actual return? Does the return match the investment case?
4. Where in your architecture is there a cost hot spot — a component whose cost will grow discontinuously as volume increases? Has that non-linearity been communicated to financial planning?

Design: Take the most significant engineering investment currently under consideration in your organisation. Build the economic case using the three-number structure: current cost, projected cost at 2x scale, and cost of the proposed investment. Calculate the breakeven point and the cost of delay per month if the investment is deferred. Present it in a format that allows a non-technical board member to evaluate the investment against other business priorities.