Engineering metrics that matter — without surveilling your developers

There is a fork in the road every engineering leader eventually reaches. You want to know whether delivery is healthy, so you go looking for numbers. One path leads to metrics that measure the system — how fast work flows, where it gets stuck, whether quality is holding. The other leads to metrics that measure the people — lines of code, commit counts, individual velocity rankings. The two paths look similar at the trailhead. They end in completely different places: one builds a team that partners with you to improve, the other builds a team that games you and quietly updates its résumé.

The metrics that reward the wrong thing

Start with what to never track. Lines of code has been debunked by every credible research group, including Google’s own DORA team — it rewards verbosity and punishes the senior engineer who deletes 400 lines to fix a bug. Commit counts reward noise. Individual velocity rankings are the fastest way to turn story points from a planning tool into a currency, and currencies get inflated: within two quarters of measuring individual velocity, you are no longer measuring anything except who is best at making the number go up. This is Goodhart’s law in its purest form — the moment a measure becomes a target, it stops being a good measure.

Metrics used as a coaching tool build trust. The exact same metrics used for surveillance destroy it. The number is never the problem — the altitude you view it from is.

Measure the system, not the individual

The metrics that actually predict performance all share one property: they describe flow, not people. The DORA set — deployment frequency, lead time for changes, change-failure rate, and time to restore — is the closest thing the industry has to proven ground, backed by a decade of research across tens of thousands of professionals, and every one of them is a property of the system. Cycle time tells you how long work waits versus how long it is worked. Change-failure rate tells you whether speed is costing you stability. None of them names a person, and that is not a limitation — it is the source of their power. A bottleneck is a property of a process. Fix the process and everyone gets faster.

• Flow, in business days — cycle time and aging work-in-progress, so a weekend never makes work look "stale."
• Quality under pressure — change-failure rate and rework, so you can see when speed is quietly buying future incidents.
• Bottlenecks by role, not by name — "reviews are serialized through one person" is a routing problem to fix, not a person to blame.
• Delivery risk, per sprint — a calibrated chance of missing the commitment, so the team can act before the deadline decides for them.

The people-risk you can measure safely

There is real organizational risk that looks like a people metric but is not: the bus factor. When 70% of the reviews on a critical service route through one engineer, or every 11pm rollback is authored by the same person, you have a single point of failure — and you find out the hard way the week they are on PTO during an incident. You can and should measure this. The trick is to measure it as team-level fragility, aggregated, with a floor of several people, never as an individual productivity score. "Bus factor one on payments-core" is an org-design fact you can fund a fix for. "Here is a ranked list of who reviews the most" is a leaderboard that will be gamed by Friday.

Why the surveillance-free version is also the more useful one

The happy accident is that the privacy-preserving choice is also the higher-signal one. Per-person metrics are noisy, easily gamed, and legally radioactive in much of the world — European works councils will switch the whole tool off the moment it exposes individual analytics. System metrics are harder to game because they cross-examine two systems at once, and they point at the thing you can actually change: the process. You do not fix delivery by ranking developers. You fix it by finding the blocked dependency, the review queue, the scope that snuck in — none of which has a name attached.

This is a first-class design promise in KalMatrix, not an afterthought: no individual velocity leaderboards, ever; every comparison denominated against a team’s own history; and the trust-sensitive signals reserved for team-level aggregates with a hard floor. The result is a tool the engineering org treats as a bystander during a purchase instead of an adversary — and one that still tells a CTO, every morning, whether the deadline is real. Measure the system, protect the people, and you get both the trust and the truth. Measure the people, and you will eventually have neither.