17 posts tagged with "finance"

The standing monthly engineering cost review at the 80-person org we worked with in March 2026 ran 90 minutes. Six dashboards. Four department leads each defending their numbers. The output: a Slack message saying "let's dig in next month." Same message in February. Same in January. The dashboards were excellent. The decisions were zero.

The problem is not data scarcity. Asana's 2024 Anatomy of Work report found knowledge workers spend 58% of the day on "work about work," meetings, status updates, and dashboard reviews, and that the modal review meeting produces no concrete next action. Engineering cost reviews are a textbook case. Too many numbers, no forcing function for a decision.

Open the Finances page for an organization with 38 active projects. The default view is a sortable table: project name, cost last 30 days, cost all-time, owner, status. The CFO's monthly cost review starts here. 38 rows, 8 minutes of scrolling, and a 60% chance the most-expensive project is on row 17 where nobody actually looks. Edward Tufte made the case in The Visual Display of Quantitative Information (1983, 2nd ed. 2001) that humans process color and size before they process numbers. A heatmap of the same 38 projects surfaces the dark-red square in under a second. Stephen Few's Information Dashboard Design (2006, 2nd ed. 2013) reaches the same conclusion in industry research: when monitoring requires "find the outlier," tabular data is the wrong primary view. PanDev Metrics' Projects Heatmap widget runs both modes side by side. This post is about why the mosaic should be the default and the list the cross-check.

A VP of Engineering walks into the quarterly review with a clean DORA dashboard: lead time down from 9 days to 4, deployment frequency up from 1.2 per week to 2.8, change failure rate trimmed from 18% to 11%. The CFO listens patiently, then asks the only question that matters: "What did that save us in dollars?" The room goes quiet. The DORA tool does not know. The finance tool does not know either, because it does not see deployment data. The CTO ends up arguing on principle. Two quarters later, the platform team's budget is cut to fund a sales hire.

Most engineering organizations track DORA and cost in two separate systems. Sleuth, Swarmia, LinearB show you DORA. Jellyfish (its standalone finance module) and Faros show you cost. The DORA State of DevOps reports explicitly link the four DORA metrics to organizational performance, but only at the outcomes layer, not the dollar layer. To translate "we cut lead time from 9d to 4d" into a real number the CFO defends, you need both data sources in the same query. This article walks through the four integration points, then a worked Q1 → Q2 example with a 2.73x quarterly ROI.

A VP of Engineering walks out of a Q1 review and announces an 8% raise for 12 backend engineers, effective March 1. It's now May 18. Three months of finance reports already shipped to the board with the old rates baked in. HR has two options: pretend the raise started today, or retroactively update March, April, and May. Most engineering finance tools force option one. PanDev Metrics supports option two, and the Sarbanes-Oxley Act of 2002 is the reason it has to be done carefully.

This is one of the few areas where our product genuinely diverges from LinearB, Jellyfish, and Code Climate Velocity. Those tools were built around forward-only rate models. PanDev's UserRate table is bitemporal: every rate has a startPeriod and endPeriod, and the OverheadCoefficientFullRecalcCronJob will replay activity events through new rate × overhead K when historical rows change. That's powerful. It's also exactly the kind of capability that auditors look at twice.

A platform team of 6 engineers costs $156K per quarter. They run auth, observability, the internal API gateway, the shared cache, and the deploy pipeline. Eight product teams use those services every day. Ask the CFO who pays for it and the answer is "central R&D." Ask the platform lead who consumes it and the answer is "everyone equally." Both are wrong, and the gap between them is where engineering finance loses six figures a year in distorted decisions.

Adrian Cockcroft made the original argument when Netflix decoupled into microservices: shared infrastructure has a unit cost, and unit cost should follow the request. The CNCF FinOps Working Group in their 2024 State of FinOps for Engineering report found fewer than 24% of microservices organizations allocate platform-team time back to consumer teams. The other 76% treat platform engineering as overhead, which means the team consuming 41% of platform requests is invoiced the same as the team consuming 1%.

A CTO sees a $52K/year SaaS quote for a billing tool. Four engineers in the room, paid roughly $7K/month each loaded. The math is fast: "4 engineers × 4 months = 16 person-months. We can build this for $112K. Then it's free forever." The board nods. Procurement is told to cancel the SaaS evaluation. Eighteen months later, the team still owns the billing service, two engineers maintain it part-time, and the original four have shipped zero revenue features the quarter they were inside it. The real 5-year cost of "build" lands at $546K, almost double the SaaS path. Forrester's 2023 Total Economic Impact of Buy-vs-Build analysis put the median underestimate of in-house cost at 2.3×. Gartner's TCO frameworks have said the same thing for fifteen years. Most teams still don't multiply through.

A VP of Engineering presents a $1.2M microservices migration to the board. ROI projection: "we save 30% on infra and ship 2x faster." The CFO asks: "Show me the math." The answer is a single number, 240%, with no method behind it. The board says no. Two quarters later, a competitor closes the same migration in eight months and starts winning enterprise deals on latency. The project was good. The math was the problem.

There is no single "engineering ROI formula." There are five distinct calculation methods, each built for a different question. McKinsey's Developer Velocity Index research found top-quartile teams generate 4–5x the revenue per developer of bottom-quartile teams. That ratio means nothing without specifying how you measured it. Pick the wrong method for the question being asked and you will lose a defensible project. This article walks through all five with worked numbers.

A team of 6 engineers, 60 working days, 8 hours each. The PM walks into the planning room with 2,880 dev-hours of capacity on the slide. Q3 roadmap fits in 2,400. Comfortable buffer. Three months later 40% of the roadmap is late and the postmortem blames "scope creep."

There was no scope creep. The capacity number was wrong on day one. Stanford economist John Pencavel's hours-and-productivity study shows output per hour starts collapsing past 49 hours per week, long before you hit 60. Microsoft Research and UC Irvine's Gloria Mark added the second blade: every interruption costs an average 23 minutes 15 seconds to fully recover focus. Stack those two findings on top of any 8-hour calendar and you get something far less than 8 productive hours of real output.

A 60-person engineering org we instrumented through 14 months of finance data ran an average overhead coefficient of K = 0.41. That number is useless. The actual monthly series is Jan 0.46, Feb 0.40, Mar 0.39, Apr 0.40, May 0.41, Jun 0.43, Jul 0.48, Aug 0.49, Sep 0.42, Oct 0.40, Nov 0.43, Dec 0.52. The flat-K finance model predicted December overhead of $185K. Reality came in at $235K. The 27% miss is not a forecasting bug. It is the entire story of every Q4 budget surprise the CFO has ever asked engineering to explain.

DORA's 2024 State of DevOps report flagged the same shape from a different angle: deployment frequency in Q4 drops 12–18% across the surveyed cohort, while incident volume rises. Stack Overflow's 2024 Developer Survey reports developers take an average of 17 vacation days per year, with concentration in late December and August. Harvard Business Review's Why Most Product Launches Fail notes Q4 launch density runs 30–40% above other quarters. Three different datasets, one consequence: engineering capacity in December is structurally different from June. Treating it as the same in your finance model is the mistake.

A 50-engineer R&D org we worked with last fiscal year set its annual budget the way most do: take last year's spend ($5.4M), add 10%, call it $5.94M. By Q3, finance was negotiating a $700K supplemental from the board. The shortfall was almost exactly $710K, 12% above the top-down number, and the postmortem traced every dollar to assumptions nobody had written down. Holiday months ran hotter on overhead. Two contractors were on-paper part-time but billed 0.9 FTE. One team grew by three heads in March, and the cost compounded for nine months instead of the four the planner had pencilled.

Gartner's 2025 IT Spending Forecast puts software R&D growth at 9-11% YoY, but the variance band on individual company budgets is much wider. Deloitte's CFO Insights: Budgeting in Volatile Times (2024) found median forecast error of 18% in software-heavy organizations using top-down methods, and the worst quartile missed by more than 30%. McKinsey's 2023 Tech Talent Tectonics report sharpens the case: top-quartile engineering organizations don't just spend less per output. They forecast more accurately, which lets them allocate aggressively where bottom-quartile organizations have to keep cash slack as a hedge against their own bad math.