How to Measure Engineering Productivity Without Breaking Trust

Every few quarters a well-meaning executive asks me to rank engineers by output. Lines of code, story points, commits, pick your poison. I always say no, and then I explain why the question itself is the problem. The way to measure engineering productivity is to measure the delivery system, not the individual: DORA metrics for team-level speed and stability, paired with the business outcomes the work was supposed to move.

The moment a metric is used to evaluate a person, that person optimizes the metric instead of the outcome. Goodhart's law isn't a theory in software; it's a Tuesday. Measure commits and you get more commits. Measure points and the estimates inflate. None of that is productivity; it just teaches people to game you.

Why ranking individuals always backfires

It's worth being precise about why, because the instinct behind the request is reasonable. Engineering is expensive and leadership deserves to know whether the money is working. The problem is that individual output in software has no honest unit. The best week of a senior engineer's year might produce negative lines of code: a deletion that removes an entire class of bugs, a design conversation that kills a doomed project before it burns a quarter, an hour of unblocking that saves three other people a day each. Every counting scheme ever proposed misses that work completely. Worse, it punishes it.

Then there's what measurement does to behavior. Rank people on commits and your best reviewer stops reviewing, because review doesn't show up in their number. Rank on story points and the estimates inflate within two sprints. Rank on tickets closed and the tickets get smaller. Nobody is being dishonest, exactly. They're responding rationally to what you told them matters. You wanted a measure and you built an incentive system, and now the incentive system is optimizing against you.

And even a hypothetically ungameable individual metric would point at the wrong thing. Take your strongest engineer and drop them into a codebase with a forty-minute build, a flaky test suite, and a two-day review queue. Their output craters. The engineer didn't change; the system did. Most of the variance leaders attribute to individuals actually lives in the system around them. That's good news, because the system is the thing you can fix without anyone feeling hunted.

Measure the system, not the person

The useful signals are nearly all system-level. How long does a change take to reach production? How often does delivery fail? How quickly do we recover? These describe the machine the team works inside, and improving the machine helps everyone at once.

• Flow, lead time and deployment frequency tell you whether work moves.
• Stability, change-failure rate and restore time tell you whether it's safe.
• Friction, where do engineers wait? Review queues, flaky tests, slow environments.
• Focus, how much of the week is uninterrupted deep work versus context-switching?

Start with DORA

When a company asks me where to begin, my answer is boring and consistent: the four metrics from the DORA research program. Lead time for changes, deployment frequency, change-failure rate, and time to restore service. More than a decade of research across tens of thousands of teams sits behind them, and they have the one property that matters most here: they describe a team's delivery system and never a person.

The four work as two pairs held in tension. Lead time and deployment frequency measure speed. Change-failure rate and restore time measure stability. Game one pair and the other exposes you immediately: ship recklessly fast and your failure rate gives you away, play it so safe nothing ever breaks and your lead time does. That tension is what makes DORA hard to fake and safe to put on a wall where the whole team can see it.

It's also achievable fast. Most of the raw data already lives in your Git history, your CI system, and your incident tracker, so a first honest dashboard is weeks of work rather than quarters. I've written up how one engineering organization went from fearful, manual releases to elite DORA performance in ninety days. Process did the work. Nobody got ranked, and nobody quit.

DORA proves the machine works, not that it matters

Here's the trap on the other side. A team can post elite DORA numbers while shipping things no customer wants. The metrics grade the delivery machine, and a flawless machine pointed at the wrong target is just faster waste. So pair the system metrics with business outcomes: the revenue, retention, cost, or risk number each initiative was supposed to move. Every meaningful piece of work should have that number attached before it starts. If nobody in the room can name it, you don't have a measurement gap. You have a prioritization problem wearing a measurement costume.

That pairing is the whole method. DORA answers "is the engine healthy." Business outcomes answer "is it pointed somewhere worth going." Either one alone will mislead you. Together they give a board an honest picture in two slides.

The AI wrinkle: new dashboards, same trap

AI tooling has handed the rank-people instinct a shiny new number to abuse: token consumption. I've watched executives pull up usage dashboards and ask which engineers are "really using the AI," as if tokens burned were work done. They aren't. Tokenmaxxing is the lines-of-code fallacy with a fresh coat of paint, and it misleads in both directions, flattering the engineer who flails through forty re-prompts and punishing the one who solved the same problem in three.

AI also raises the stakes for measuring the right thing. When generating code is cheap, raw output inflates across the board and output-shaped metrics get even less meaningful than they already were. The signal moves downstream: did the change survive review, did it ship, did it stay shipped, did the outcome move. The system-level view was always the right one. AI just made the individual-output view actively hallucinatory.

What leadership actually wants

When a board asks about productivity, they're rarely asking who to fire. They're asking whether the investment in engineering is paying off and whether the next commitment is safe to make. System metrics answer that honestly, and they do it without turning your best people into adversaries.

Point the measurement at the system and fix the friction. The individuals were never the bottleneck.

If your metrics have already turned toxic, this is fixable, and it's usually the first thing I repair in a turnaround engagement, because nothing else improves while people are afraid of the numbers. If your dashboard has quietly become a weapon, let's talk →