73 posts tagged with "engineering-metrics"

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.

In Q1 2026 we instrumented an engineering organization that reported a healthy "$340K spent on Project X this quarter." Drilling down, the top five tickets told a different story. PROJ-1245 refactor auth: $4,820. PROJ-1281 date-format bug: $3,140. A two-hour bug fix that cost more than half of an architectural refactor. Six engineers had touched it across three weeks because nobody owned it.

You cannot have that conversation with a project-level number. You can have it with a ticket-level number. That is the entire argument of this post, and the reason most engineering finance tools are debating the wrong layer.

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.

Your 40-engineer team maintains 34 repositories. Sound reasonable? We see this shape often. A typical developer in that configuration triggers 11.4 context switches per day between repositories — almost all invisible to the EM, each costing roughly 23 minutes of refocus time, per UC Irvine's Gloria Mark (The Cost of Interrupted Work, 2008) and subsequent replications. The same team post-monorepo migration: 3.2 switches per day. The productivity math is obvious; the cost math is where it gets interesting.

Both architectures work. Google runs the largest known monorepo (2 billion+ lines of code, ~85,000 engineers). Netflix runs thousands of polyrepos. The question isn't which is better in the abstract — it's which fits your team size, your CI budget, and your tolerance for coordination overhead.

A team of 8 engineers logged 1,280 hours in March 2026. That is exactly what a 160-hour-per-FTE month should produce. The spreadsheet looked clean. Two engineers were three weeks from quitting. The hours number hid that completely; FTE utilization showed it on day five.

This is the gap between an attendance metric and an engagement-against-baseline metric. Microsoft Research's 2022 WorkLab study on the "triple peak workday" documented a third evening productivity spike pushing knowledge workers past sustainable hours, and that signal stays invisible if you only count totals. Hours don't tell you who is sprinting and who is coasting. FTE utilization does.

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.

AI code review sits at the crest of the hype cycle. GitHub Copilot, CodeRabbit, Qodo, Graphite, and half a dozen startups are pitching a future where LLMs catch bugs faster than humans. Microsoft Research and Bacchelli's seminal 2013 study on code review established the baseline we've been measuring against for a decade: human review catches ~14% of functional defects but 68% of maintainability issues. The question now is: does layering an LLM on top actually move either number?

We pulled review data from 100 B2B teams between Q1 2025 and Q1 2026: a mix of teams using AI review, teams not, and teams running hybrid. The pattern isn't what the vendors claim.

Most non-technical CEOs I've met treat engineering as either a black box or a theater. Black-box CEOs ask "how's engineering?" at the executive meeting, accept "we're on track" as an answer, and act surprised four quarters later when the senior architect resigns and the product roadmap stalls. Theater CEOs become amateur engineering managers — they learn to recite DORA metrics, mispronounce "Kubernetes," and inadvertently turn every roadmap discussion into a technical argument they can't follow.

Neither failure mode is about intelligence. It's about the absence of a short, non-technical vocabulary for engineering health. First Round's 2023 State of Startups survey found 68% of first-time CEOs rate themselves "somewhat" or "very" dependent on their CTO for all engineering judgment calls — which is fine until the CTO leaves or disagrees with the board on direction.

This guide is the minimum CEO vocabulary: 6 questions that let you test whether engineering is healthy without pretending to be technical.