You Pay a Fortune for Engineering. Where Does It Go?

TL;DR: The scary version of the board question - what do all these engineers do? - assumes the money is vanishing. It isn't. It's buying maintenance, debt interest, keeping-the-lights-on work, and queue time: real work that never appears on a roadmap, so it reads as nothing. The free fix is an afternoon of accounting: compute your true loaded cost, bucket one sprint's merged PRs into new-value vs. everything else, and you'll have an answer you can defend, and a share you can start deliberately shrinking.

Engineering is your biggest line item. You know the number: you sign off on it every month. And when you put it next to the quarter's shipped features, the ratio makes your stomach drop a little, because you know exactly the question it invites: what do they all do all day?

Worse than the question is your honest answer: "trust me, they're working." You can feel how thin that sounds, even though you know it's true. You've seen this team pull off hard things. The money is going somewhere real. You just can't point at it.

The money isn't vanishing. It's buying invisible work.

Start with the line item itself, because it's bigger than the salaries. U.S. BLS data puts benefits at 29.7% of private-industry employer compensation costs, and the standard estimate for a fully-loaded employee runs 1.25 to 1.4 times base salary once you add employment costs, equipment, and space. If you're mentally dividing "salaries" by "features," your denominator is already wrong. The honest loaded-cost math is step zero.

Now the numerator - where the hours go. In Stripe's Developer Coefficient survey of over a thousand developers (self-reported, and worth reading with that caveat), respondents averaged a 41.1-hour week, of which 17.3 hours went to maintenance - debugging, refactoring, fixing bad code - including 13.5 hours attributed to technical debt. And 59% of them called the time spent on bad code excessive. Whatever the precise figure in your org, the shape is the point: a large fraction of every engineering week is spent keeping yesterday's decisions alive, on debt interest and keeping-the-lights-on work. None of it ever appears on a roadmap slide. It's real, necessary, and completely invisible in the artifact you're being judged on.

Two more sinks and the picture is complete. First, queues: work that's finished but waiting (for review, for QA, for a deploy window) burns payroll while producing nothing, and it's usually the biggest hidden sink of all. Second, the subtler one: shipping things that don't matter. John Cutler's feature factory essay calls it success theater: celebrating "shipped" with little discussion of impact. If that one stings, read the full list of signs; output and outcome diverge quietly.

Notice what's not on the list: lazy engineers. If the budget question gets answered by pulling per-person output stats, you'll find someone to blame and miss every actual sink. That's the stack-ranking trap, and it burns trust you'll want later.

Do this first - free, this afternoon

1. Compute your real loaded cost per engineer. Salary × the Hadzima multiplier, or your finance team's actual number. Every later claim is honest only if this input is.
2. Bucket one sprint. Go through the merged PRs and closed tickets of your last sprint and tag each: new value, maintenance/debt, KTLO/ops, or rework. Two hours, after the fact, no timesheets. The output is one sentence you've never been able to say before: "roughly this share of our engineering week buys new product, and this share keeps the existing product alive."
3. Decide the split on purpose. There is no universally correct ratio: a mature platform legitimately spends more on KTLO than a greenfield startup. The failure mode isn't a high maintenance share; it's a share nobody chose. If debt work is eating the roadmap, that's a case to make explicitly. Here's how to make it.
4. Ask the impact question. Of the last five things shipped, which moved a metric anyone cares about? If the answer is silence, your problem isn't velocity at all, and more engineering spend will just produce faster silence.

What "good" looks like: you walk into the next board meeting able to decompose the line item - this much new value, this much maintenance we've chosen, this much queue waste we're fixing - instead of defending a blob.

How you'd actually see it

The afternoon audit answers the question once. The spend drifts continuously: debt accrues, queues regrow, KTLO creeps. So the durable version is a money view computed from your actual engineering activity: your loaded-cost model applied to measured drains like review-queue time, rework, and maintenance share, in your currency, with every figure traceable to the formula and inputs that produced it.

That's what Busfactor's money view does, and one design choice matters more than the feature list: every number must be reconstructable. A serious tool shows its math (inputs you set, formulas you can check), because the alternative is the dashboard that prints a giant scary "opportunity cost" total your CFO will demolish in one question. We refuse to print numbers like that; engineering economics done honestly is more persuasive precisely because it claims less.

The door

The uncomfortable board question has a genuinely good answer - you've just never had the accounting to give it. Run the afternoon audit; you'll walk out with a defensible split and probably one obvious fix. If the split shows the money leaking into queues, start here. If you were hoping AI tooling would fix the ratio by itself, read this first. And if you want the decomposition maintained weekly instead of rebuilt every board cycle, priced in your currency with receipts attached, that's exactly the product. The question isn't going away. The blob answer should.