The hidden cost of developer friction nobody puts on a P&L
Slow builds, unclear ownership, and manual approvals don't show up as a line item — they show up as everything else being late. Here's how to make the cost visible.
Ask a CFO what the platform costs and they can answer in one number: headcount, cloud spend, tooling licenses. Ask what it costs not to have a good one, and the answer is usually a shrug. That asymmetry is the whole problem — the cost of friction is real, it's often larger than the cost of the team that would fix it, and it's invisible on every report finance actually reads.
Three kinds of cost, only one of which gets tracked
- Engineering cost — the fully-loaded cost of the team. Salary, benefits, tooling, overhead. Executives already track this; it's the number in the budget.
- Opportunity cost — what didn't get built because engineers were fighting the platform instead of shipping features. Invisible on a P&L, and in practice the larger number of the two.
- Developer friction — the accumulation of small frictions: a slow build, an unclear owner for a shared service, a manual approval that sits in someone's queue for two days. Individually each one looks trivial. Collectively they account for most of the lost cycle time in a mid-size engineering org.
The mistake is treating only the first bucket as real because it's the only one with a number attached. Friction and opportunity cost are just as real — they're paid in calendar time and morale instead of invoices, which makes them easy to defer and easy to underestimate.
Visualizing the friction
You don't need a research team to quantify this. You need three inputs:
hours lost to friction = developers × toil hours/week × working weeks
cost of friction = hours lost × fully-loaded hourly cost
"Toil hours per week" comes from asking engineers directly — provisioning waits, CI flakiness, environment setup, chasing approvals. It's a soft, subjective number and should therefore be conservatively adjusted. This is the same model that backs the platform ROI calculator: this calculator doesn't try to be precise, it tries to be defensible with a proper range, because every input traces back to a fully-loaded cost or a measured friction rather than an aspiration.
Why this compounds
Friction doesn't stay flat — it's a multiplier on everything downstream. A slow, manual path to production doesn't just cost the hours spent waiting; it discourages small, frequent changes, which pushes teams back toward large, risky batches. That's the same mechanism DORA's research names directly: throughput and stability aren't a trade-off, they move together, and an org stuck in slow-and-manual is usually losing on both fronts at once, not trading one for the other.
The real pitch
The pitch for a platform team should rarely be "we need new tools or more engineers". It's "here is what the org is already paying for the opportunity cost of not having a solid platform with golden paths" - itemized in hours and dollars lost - and here is projected increase in productivity (and therefore revenue) with said platform". That framing turns the platform from a cost center asking for budget into a debt-reduction plan with a payback period — which is a conversation finance already knows how to have.