Engineering Economics: Putting a Number on Your Team

TL;DR: In most software companies, engineering payroll is the single largest budget nobody can see inside. Finance sees one opaque block of salaries; engineering sees standups and pull requests; nobody sees what the money actually buys. Engineering economics is the discipline of connecting the two: a loaded cost per hour, a price on waiting, a price on rework, and an honest split between investment and upkeep. None of it requires new tooling to start. It requires four numbers and the nerve to write them down.

What is engineering economics?

Engineering economics is the practice of expressing what your engineering organization does in the one language every leadership table shares: money. Not to bill anyone. Not to rank anyone. To make trade-offs comparable, because "our reviews are slow," "our debt is heavy," and "we should hire two more" are three claims in three different units, and nothing in three different units can be prioritized.

The discipline rests on four numbers, and each one has its own deep-dive on this blog:

1. The exchange rate: what an engineer-hour actually costs, fully loaded.
2. The price of waiting: what queues and delay consume in payroll.
3. The recurring charges: what rework and technical debt quietly bill you every sprint.
4. The investment split: which share of the work is building an asset versus keeping the lights on.

A CTO who can produce those four numbers, with methods disclosed, walks into budget season with receipts. One who cannot walks in with adjectives.

One framing before the numbers: nobody here is trying to squeeze more output per person. The point is seeing where a fixed, expensive capacity actually goes.

In every organization we have looked at, the surprising line item is never the salaries. It is how much of them goes to waiting, redoing, and maintaining.

The exchange rate: fully loaded cost

Everything starts here, because every other number is a multiplication against this one. An engineer's cost is not their salary: MIT's Joe Hadzima puts the real figure at 1.25 to 1.4 times base salary once payroll taxes and benefits are counted (How Much Does an Employee Cost?), and the U.S. Bureau of Labor Statistics measured benefits at 29.7% of total employer compensation costs for private-industry workers in March 2025 (BLS ECEC). That is before equipment, seats, or recruiting.

The full walkthrough - components, the 2,080-hour denominator question, and the honesty rules - is in Fully Loaded Cost of an Engineer. Compute it once, disclose your method, and reuse the same figure everywhere. A team that quietly switches between salary and loaded cost depending on which is more dramatic has already lost the CFO's trust.

The price of waiting: queues and cost of delay

The least visible drain in engineering is time when nobody is working: a pull request sitting unreviewed, a deploy waiting for a window, a decision waiting for a meeting. Payroll runs at full rate through all of it. Queue time is pure operating expense with zero output, which makes it the cheapest waste to attack. No rewrite required, just process.

Reviews are usually the biggest and most measurable queue, and pricing one is the fastest way to demonstrate the whole discipline. The arithmetic and the evidence standard are in What Slow Code Review Costs You in Payroll. The same logic extends to every handoff in your delivery pipeline: wherever work waits, money burns.

The recurring charges: rework and technical debt

The second leak is work you pay for twice. Stripe's Developer Coefficient study (more than 1,000 developers and 1,000 C-level executives surveyed with Harris Poll) found the average developer reporting a 41.1-hour week of which 17.3 hours go to maintenance work like debugging and refactoring, including 13.5 hours a week on technical debt (Stripe, 2018). Self-reported, but directionally brutal: roughly a third of the payroll buying upkeep instead of progress.

The balance-sheet view agrees. In McKinsey's survey of CIOs, respondents reported 10 to 20 percent of the technology budget meant for new products is diverted to resolving tech-debt issues, and estimated accumulated debt at 20 to 40 percent of the value of their entire technology estate (McKinsey, Tech debt: Reclaiming tech equity).

Two companion pieces break this down into measurable practice: The Real Cost of Technical Debt covers how to price the interest honestly (and what a CFO will call overclaiming), and Rework Rate covers the delivery-data metric that catches paying-twice as it happens, before it hardens into debt. If your team has adopted AI assistants, read them alongside the technical debt AI generates, because generated code is changing how fast the meter runs.

The investment split: CapEx, OpEx, and what the work builds

The fourth number reframes the whole conversation: how much of your engineering spend is building an asset versus operating the shop? Finance genuinely needs the split. Capitalizable development lands differently on the P&L than expense, and the accounting rules recently modernized on both sides of the Atlantic. The primer on what qualifies is CapEx vs OpEx for Software; the practical guide to keeping the evidence audit-ready in a continuous-delivery world is Capitalizing Software Development Costs in Agile.

But the split is a management signal as much as a compliance artifact. If the investment share of your engineering time shrinks quarter over quarter, your roadmap is quietly becoming upkeep, and no headcount request fixes that, because new hires inherit the same ratio.

The honesty rules

Engineering economics earns respect exactly as fast as it stays honest, and loses it faster. Four rules:

• Disclose every input. Loaded-cost multiplier, hours denominator, time windows - all choices, all stated. A number with a hidden method is an opinion in a costume.
• Quote, never invent. Industry figures are context. Stripe's 17.3 hours is what surveyed developers reported, not what your team does. Measure your own before you claim it.
• Never double-count. A slow review that causes rework that becomes debt is one hour of waste, not three. Pick the primary bucket per receipt.
• Price systems, not people. The moment cost-per-hour becomes a ranking of humans, you have left economics and entered a different, uglier business. The waste lives in queues, debt, and process - price those.

The door

Block one afternoon with your finance lead. Produce four numbers: loaded cost per engineer-hour, the payroll price of your worst queue, your rework share, and your investment-versus-upkeep split. Write the methods next to them. That single page will do more for your next planning cycle than any framework deck, because for the first time everything on the table will be in the same units.