Measuring Engineer Productivity Without Breaking Trust
Productivity metrics turn toxic the moment they're used to rank people. Here's how to measure the system instead of the individual, and still get the leverage leadership wants.
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 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 estimates inflate. You haven't measured productivity, you've taught people to game you.
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?
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. Fix the friction. The individuals were never the bottleneck.