Engineering Economics: Why Every Technical Decision Is a Financial Decision

A VP of Engineering presents a proposal to the board. Replace the company's batch processing infrastructure — nightly jobs that take six hours — with streaming jobs that produce near-real-time output. The cost: fourteen engineer-weeks. The benefit: customers see fresher data.

The board asks the obvious question: is fourteen engineer-weeks worth fresher data? The VP cannot answer. Not because the engineering is unclear, but because the proposal was framed as an engineering improvement — and nobody had asked what fresher data is worth to a customer, what fourteen engineer-weeks would cost in opportunity, or what the new infrastructure costs to run per month at 2× volume.

The proposal was an economic decision wearing engineering clothes. Every significant engineering decision is.

Three Numbers, Always

Any significant engineering investment must be evaluated on three economic dimensions: what it costs to build and operate, what not building it costs, and what it costs as the system scales. Without all three, the investment cannot be compared to the organisation's other uses of capital.

The board presentation has a fixed three-number structure: current cost, projected cost at 2× scale, cost of the investment required to change the cost curve. A streaming investment of fourteen engineer-weeks that cuts batch infrastructure cost by 40% per month at 2× 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 it pay off, and do we believe we'll reach 2× scale within that horizon?" — a question the board can actually answer.

Cost of Delay: The Concept Most Orgs Don't Use

Cost of delay is the value lost per unit of time by not shipping something. A feature that would generate €10,000 of monthly recurring revenue has a cost of delay of €10,000/month. A three-month delay costs €30,000. An investment that shortens that delay from three months to one is worth €20,000.

Without cost of delay, every engineering decision is evaluated against the cost to build — never against the value of building. And the shape of the cost-of-delay curve varies by project type, which is why treating everything as linear produces systematically wrong prioritisation:

• Feature delay is linear — roughly €10K/week, steady and predictable.
• Security delay is exponential — near-zero cost per week until the vulnerability is exploited, then catastrophic.
• Compliance delay is a cliff — €0/week until the deadline, then the full fine arrives regardless of how close you came.

A leader who prioritises by backlog age or engineering preference is optimising against the wrong curve entirely.

Cost of delay — three curves, three priorities

  cost
    │                            ╱  security (exponential)
    │                          ╱
    │                    ___╱──────────  compliance (cliff)
    │              ___╱──      │
    │        ___╱──      ______│  feature (linear)
    │  ___╱──     ______│
    └──────────────────────────────────▶ time delayed
   prioritising by backlog age optimises the wrong curve

The Tradeoff: Latency vs Throughput Is an Economic Curve

AT2 (Latency vs Throughput) is not only a systems tradeoff — it is an economic one. Lower latency typically requires more infrastructure: more replicas, more cache, more compute. Higher throughput without a latency constraint is cheaper per unit at scale. The economic consequence of AT2 is a cost curve, and the cost curve is the thing a board can evaluate.

When the business model genuinely requires low latency — a trading system, a real-time recommendation engine — the cost of that latency is a product requirement, not an engineering preference, and it should be presented as such. The board cannot evaluate "a 40ms latency improvement." It can evaluate "cost per transaction at 2× volume."

Where It Fails: The Invisible Maintenance Bill

The most common engineering-economics failure is FM3 (Unbounded Resource Consumption) in the maintenance dimension. Teams account for build cost and infrastructure cost, then ignore the ongoing engineering overhead — incident time, updates, the cognitive load of understanding a complex system in a high-turnover org. Every capability added is a permanent maintenance obligation, and it never appears in the investment proposal. The operating cost of systems is systematically underestimated because it is spread across cost centres that are rarely aggregated: compute is on the cloud bill, but on-call load and incident response are not — and they are often larger.

A second failure: FM6 (Hotspotting) at the economic level. Infrastructure cost concentrated in one component — a single database, a single data-transfer path — makes the cost curve non-linear. When that hot component hits its capacity ceiling, the cost to keep scaling jumps discontinuously. Organisations that do not model their cost hot spots are ambushed by cliff-edge cost events that the cost model would have predicted.

What Great Technical Leaders Do

They translate technical decisions into cost curves before presenting them. They do not pitch streaming as "better architecture" — they pitch "current cost at 1× volume, projected cost at 2×, projected cost with streaming at 2×, breakeven at month nine given projected growth." They maintain a cost model for the organisation's most significant infrastructure — not a spreadsheet of every cloud resource, but a model that shows how cost scales with product growth. A cost model that cannot explain a 3× cost increase when data volume merely doubled has missed a scaling assumption. And they prioritise by cost of delay, not by which project is most technically interesting or has been in the backlog longest.

The One Sentence

Every technical decision is a financial decision, and the job of engineering leadership is to make it legible as one — current cost, cost at 2× scale, cost of the investment, and cost of delay if deferred — because a board cannot evaluate a latency number, but it can evaluate a breakeven date.