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. 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 to go without a good one, and the answer is usually a shrug. That asymmetry is the whole problem. The cost of friction is often larger than the cost of the team that would fix it, and it doesn't appear on any report finance 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 annoyances. A slow build, an unclear owner for a shared service, a manual approval that sits in someone's queue for two days. Each one looks trivial. Together they account for most of the lost cycle time in a mid-size engineering org.
The mistake is counting only the first bucket because it's the only one with a number attached. Friction and opportunity cost get paid too, 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. Three inputs are enough:
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, so adjust it conservatively. This is the same model that backs the platform ROI calculator. The calculator doesn't try to be precise. It gives a defensible range, because every input traces back to a fully-loaded cost or a measured friction rather than an aspiration.
Why this compounds
Friction multiplies everything downstream. A slow, manual path to production costs the hours spent waiting, and it also discourages small, frequent changes, which pushes teams back toward large, risky batches. DORA's research describes the same mechanism: throughput and stability move together instead of trading off, and an org stuck in slow-and-manual is usually losing on both at once.
The pitch
The pitch for a platform team should rarely be "we need new tools or more engineers". It should be "here is what the org already pays in opportunity cost for not having a solid platform with golden paths, itemized in hours and dollars lost, and here is the projected increase in productivity (and therefore revenue) with that 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.