You’ve probably sat in one of those meetings. The CFO looks at the engineering budget, then looks at you, and asks the question that makes your stomach drop: “What are we actually getting for all this money?”
And you fumble. You talk about velocity. You pull up a Jira dashboard. You mention sprint completion rates. You show a burn-down chart that looks vaguely encouraging. Everyone nods politely, and nobody — including you — believes a word of it.
Here’s the dirty secret nobody in engineering leadership wants to admit: we’ve been measuring the wrong thing for two decades, and we know it.
The metrics we use to justify engineering teams don’t measure engineering. They measure motion. And motion is not the same as progress.
Think about what happens when you track velocity. Developers learn to inflate story points. When you track lines of code, you get bloated PRs. When you track commit frequency, you get meaningless commits. Every activity metric becomes a target, and every target becomes a game. Goodhart’s Law doesn’t just apply to economics — it’s the invisible tax on every engineering dashboard ever built.
But here’s where most conversations go off the rails. Someone says “you can’t measure engineering” and the room shrugs and moves on. That’s a cop-out. The problem isn’t measurement itself. The problem is that we’ve been measuring inputs when we should be measuring outcomes.
The shift is simple to describe and brutal to execute: weight completed work items by their estimated business value. Not by effort. Not by time. Not by story points. By the actual value the work delivers to the business.
That feature that saves the support team 20 hours a week? High value. That refactor that makes the codebase 3% cleaner but nobody outside engineering will ever notice? Lower value. That’s not a judgment on the refactor — it’s an honest accounting of impact.
If your engineering metrics make the CFO’s eyes light up instead of glaze over, you’re finally speaking the right language.
Now, the obvious objection: value estimation is subjective. Business leaders can’t always predict what a feature will be worth. Engineers can’t always predict what a refactor will unlock. Fair. But here’s the thing — effort estimation is also subjective, and we’ve been doing that for years without anyone threatening to shut down the planning poker sessions.
The point isn’t perfection. The point is direction. A value-weighted metric says to your team: “We care about what moves the business forward, not how busy you looked doing it.” That signal alone changes behavior more than any dashboard ever will.
I’ve seen what happens when teams switch. The developer who used to game story points starts asking product managers why a feature matters. The tech lead who used to over-engineer everything starts asking whether the complexity is justified by the outcome. Conversations shift from “how many tickets did you close?” to “did the work you did this quarter actually matter?”
When you measure value, you don’t just change the metric. You change the question. And the question is always more powerful than the answer.
Yes, someone will try to game the value metric too. Someone always does. But gaming a value metric requires arguing that low-impact work is high-impact — which means having that conversation in the open, with stakeholders present, where bad arguments die quickly. Compare that to gaming velocity, which happens silently in a story-point estimation meeting where nobody outside engineering is watching.
The real reason most companies don’t measure engineering by value isn’t that it’s hard. It’s that it forces an uncomfortable conversation: not everything your engineering team does is equally valuable, and some of it might not be valuable at all. That’s a hard pill. But it’s the pill that separates teams that build things people want from teams that build things that ship.
So the next time the CFO asks what you’re getting for the engineering budget, don’t show them a burn-down chart. Show them the value. And if you can’t show them the value, that’s not a measurement problem. That’s a strategy problem.
FAQ
Q: Isn't value estimation too subjective to be useful?
A: Effort estimation is equally subjective and you've been doing it for years. The goal isn't a perfect number — it's a directional signal that aligns engineering conversations with business outcomes. Imperfect honesty beats perfect irrelevance.
Q: How do we actually implement value-weighted metrics?
A: Start simple: assign a rough value weight (low/medium/high) to each work item during planning, then aggregate completed items by value at the end of each quarter. The number matters less than the conversation it forces between engineering and product.
Q: Won't developers just game the value metric the way they game velocity?
A: They'll try. But gaming value requires arguing that low-impact work is high-impact in front of stakeholders — which is a much harder con to run than inflating story points in a closed engineering meeting. Sunlight is the disinfectant.