Engineering performance metrics that aren't lines-of-code

Engineering performance measurement is where 90% of HR functions lose engineering's trust. The pattern: an exec asks 'how do we know who's productive?' HR (or a Jira admin) proposes a dashboard with commit counts and story points. Within a quarter, engineers are gaming the metrics — small commits, inflated estimates, padded PRs. Velocity 'increases' while actual output drops. The eng leader stops trusting HR with performance work. This article is how to avoid that pattern.

The anti-metrics (and why they fail)

The DORA four (team-level delivery)

The DORA (DevOps Research and Assessment, now part of Google Cloud) metrics are the industry standard for measuring software delivery performance at the team level. They've been validated across thousands of organizations in the State of DevOps reports since 2014.

These metrics are correlated with both delivery speed and stability — the highest-performing teams excel at both, dispelling the myth that you trade off. They're team-level metrics. Never individual. Comparing engineers on 'my deploy frequency' is the kind of category error that sends engineers updating their LinkedIn.

The SPACE framework

SPACE was developed by GitHub, Microsoft Research, and the University of Victoria as a multidimensional alternative to single-metric productivity (Forsgren et al., 2021). The five dimensions:

SPACE's central insight: any single metric is misleading. Always use at least 3 of the 5 dimensions to assess a team. Always combine quantitative with qualitative (developer survey data).

DX Index (developer experience)

Developer experience (DX) metrics — popularized by DX.com and adopted by Spotify, Block, Pfizer engineering — measure the friction engineers face. The DX Core 4 is a 4-question survey administered quarterly: how often do you experience friction? how often does friction block your work? how confident are you in the team's tools? how would you rate your overall developer experience? Combined with one outcome metric (typically deployment frequency or lead time), this gives a leading indicator of engineering productivity.

DX surveys are particularly useful because they surface invisible drags: slow CI, flaky tests, unreliable staging environments, painful local dev setup. These costs are real and rarely show up in feature-completion metrics — but they're the difference between an engineering org operating at 60% capacity and one at 95%.

Individual vs team metrics

How to evaluate IC performance

Metrics misuse — what to prevent

• Never rank engineers on individual quantitative metrics (PRs, commits, story points). Push back hard if asked.
• Never tie DORA metrics to individual performance reviews. They're team-system metrics.
• Never use Jira velocity to compare teams. Estimation isn't calibrated across teams.
• Never publish individual-level engineering dashboards visible to peers. Social comparison gamifies the wrong thing.
• Never let an exec demand 'top 10 / bottom 10' lists from quantitative engineering metrics. The answer is 'we don't measure individuals that way and here's why.'
• Never let layoff selection use commit/PR counts as input. Multiple companies have been sued over this (Twitter post-acquisition lawsuits, 2023; one settled).

The HRBP's role

• Own the engineering performance philosophy doc. 1–2 pages: what we measure at team level, what we measure at individual level, what we don't measure and why.
• Train managers on qualitative IC evaluation. The skill is rare; most managers default to 'shipped a lot' as a proxy.
• Push back when execs ask for individual-level quantitative dashboards. Document the rationale in writing.
• Run the team-level metrics review quarterly. Surface DORA + DX trends to eng leadership.
• Be the metrics misuse guardrail in RIF planning. When layoff input lists include commit counts, intervene — the legal exposure is real.

FAQ