17 posts tagged with "finance"

A feature is two weeks late. The product manager shrugs: "It's still in the same quarter." The engineering lead nods. The CFO never hears about it. Two weeks turn into six. By then, the enterprise customer who needed it for their procurement cycle has signed with a competitor. The total business cost of that slip was roughly $192,000. None of it appears on any engineering report.

Cost of Delay (CoD) is the most-talked-about, least-quantified concept in modern product development. Don Reinertsen built the math in The Principles of Product Development Flow (2009, chapter 2), and SAFe formalized it into WSJF (Weighted Shortest Job First). McKinsey's 2023 Developer Velocity research found that B2B SaaS leaders ship features 4–5x faster than laggards and capture disproportionately more pipeline ARR per engineer. Yet ask 10 product managers what their last delayed feature actually cost the business and 9 will say "I don't know." The math is reachable. Most teams just never reach for it.

Sprint 47, 8-person team. The standard retro narrative would be: "Velocity dropped 20%, lots of bug fires, we'll prioritize better next sprint." Same vibe as Sprint 46. Same vibe as Sprint 45. Now add one number to the same retro: total sprint cost was $32,800, of which $11,600 (35%) went to bug-fix tickets versus $14,200 (43%) to features. The team's rolling-average bug share is 18%. That single line, "we doubled our usual bug spend this sprint," moved the team from "we'll do better" to "Sprint 48's first three days are bug-prevention only, full stop."

This article shows how to wire one financial number into a 30-minute retro so it produces decisions, not vibes.

A staff engineer asks the analytics lead a simple question: "How much did the SSO feature actually cost?" Forty minutes later, the analyst comes back with a number. It's wrong by 35%. Not because the analyst is bad, but because the SQL SUM(hours) × $50 lost the rate-type branching, missed the per-month overhead K, and treated a contractor on monthly invoice the same as a salaried engineer. McKinsey's 2023 Developer Velocity Index lands the typical engineering overhead at 30–55% of payroll; if your cost-per-feature query doesn't multiply through, you're running on the wrong half of those numbers. The fix is a real PostgreSQL query, with all three layers in it. This post is that query.

A 50-person engineering org we instrumented in February 2026 had a monthly overhead coefficient of K = 0.37. That means every $1 of direct development work was shadowed by 37 cents of indirect cost: meetings, code review, ramp-up, and a slice of CTO/EM/DevOps salary spread across the team. The CFO had been modelling overhead at a flat 30% loaded multiplier for three years. The actual number was 23% higher, and almost nobody in the company knew.

The bigger problem was not the gap. The bigger problem was that the 30% number was a single bucket, so even after you discovered the gap, there was nothing actionable inside it. Boston Consulting Group's 2024 report on G&A allocation in software firms made the same observation at industry scale: companies that report overhead as one line item find it nearly impossible to trim, while companies that decompose it into three components reduce it by 8–15% within two quarters.

A finance lead at a 12-person engineering team opens the cost dashboard. Total monthly burn: $58,000. Four full-time engineers on monthly salary, five contractors on hourly rates, three more outsourced through a vendor invoiced monthly. The dashboard shows a single average cost per developer. It is the wrong number, and every per-feature decision built on top of it is also wrong.

The conventional fix is the 160-hour conversion: divide a monthly rate by 160 to get an hourly equivalent, then compare. The US Bureau of Labor Statistics tracks average annual hours actually worked per employee at 1,791 hours. That is 149 hours per month, not 160. In Kazakhstan, a statutory 24-day vacation entitlement plus 13 paid holidays brings the effective figure closer to 144 hours. The 160 number is a hand-me-down from a country that no longer matches its own data.

A senior backend engineer in Almaty earns $5,000/month gross. A CFO scoping a new project does the obvious math: $5,000 ÷ 160 = $31.25/hour. That number lands in a spreadsheet, then in a board deck, then in a quote sent to a customer.

The real cost of that engineer's hour, after overhead, is closer to $46/hour. That's a 48% gap. The 2024 DORA State of DevOps Report puts non-coding overhead at 35–55% of engineering payroll across high-performing organizations. McKinsey's Developer Velocity Index (2023) lands in the same range. Most companies never multiply through. They quote, scope, and forecast on the naive number, then wonder why the books don't close.

A CFO usually sees engineering on one line of the P&L: salaries. A headcount column, a loaded-cost multiplier, a big number growing faster than revenue. That's it. Deloitte's 2024 Global Technology Leadership Study put the gap at its starkest: only 31% of CFOs said they could tell whether their engineering investment was producing returns proportionate to cost. The other 69% were flying blind on roughly the largest discretionary spend in the company.

This is not a tooling problem. It's a question problem. The numbers exist. Your CFO peers just haven't learned which five questions extract them.