38 posts tagged with "leadership"

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 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.

You open the Q3 Plan-vs-Actual report. Planned engineering spend: $1.8M. Actual: $2.34M. Variance: +30%. The CFO wants to know why by Friday.

The textbook answer says "investigate any line where |actual − plan| > 10%". That's where most engineering variance reviews stop, and where they go wrong. A 30% gap on engineering cost has at least 5 distinct causes. Each one leaves a different signature in the data. If you don't decompose the variance, you end up firing the project manager when the real culprit was a retroactive raise round in August.

CIMA's variance analysis framework treats variance as a tree: rate variance × volume variance × mix variance. Engineering cost is messier, because labor isn't a uniform commodity. Below is the version that actually fits how dev teams burn money.

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.

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.

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.

The most common myth in our industry: an Engineering Manager is a senior developer who got admin rights in GitHub and the authority to approve pull requests on Fridays. Two reasons that's wrong. First, the median EM on the 100+ B2B teams we measure writes code for roughly 18 minutes per day, and that's the healthy number. Second, the highest-leverage thing an EM does has nothing to do with the IDE. It's the conversation that prevents a senior from quitting. The spec rewrite that saves a quarter. The hiring loop that finds an engineer one level above what the team thought it could afford. Will Larson, who built engineering at Stripe, Calm, and Carta, puts it bluntly in An Elegant Puzzle: an EM's job is to make the team output more than the sum of its parts. You cannot do that with your hands on a keyboard.

This is a plain-language definition. Who an EM is, what they do during a week, how the role differs from Tech Lead, the path from senior engineer, and how to measure whether one is doing the job well.

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.