Measuring Engineering Productivity Without Vanity Metrics
How do you measure engineering productivity correctly?
Not with a single number. Measuring engineering productivity honestly means combining three layers: Flow (how fast and stable the system ships — DORA), Outcome (is business value created, or just busywork) and Experience (can developers actually be productive — SPACE). Single metrics like lines of code, commit counts or story points are vanity metrics: easy to collect, easy to game, and almost always misleading.
The vanity-metrics trap
Almost every engineering organization measures something. The problem is rarely “too little data” — it is that the wrong things get measured because they are easy to count. Lines of code, number of commits, closed tickets, story-point velocity, hours logged: they all share one pattern. They measure activity, not impact.
The moment one of these numbers becomes a target, it stops being a good measure — that is Goodhart's law, and in engineering teams it bites faster than almost anywhere else. Reward commits and you get many tiny commits. Reward velocity and estimates inflate. Reward closed tickets and the hard, valuable bug gets left behind.
| Vanity metric | What it claims to measure | What actually happens |
|---|---|---|
| Lines of code | Productivity | Rewards bloated code; the best fix often deletes lines |
| Commit count | Engagement | Trivially gamed; says nothing about value |
| Story-point velocity | Output speed | A relative estimate, not a measure — as a KPI it inflates |
| Closed tickets | Throughput | Favors many small tasks over a few important ones |
| Hours logged | Effort | Measures presence; does not correlate with results |
Layer 1 — Flow: what DORA gets right
The four DORA metrics (from the DevOps Research and Assessment program) are the best available measure of a system's delivery capability — and crucially, they are team metrics, not individual rankings. They measure the system, not the person.
Deployment frequency
How often do you ship changes to production? Frequent, small deployments are a sign of healthy automation and low risk per release.
Lead time for changes
How long from commit to production? Short lead times mean short feedback loops — the real source of speed.
Change-failure rate
What share of deployments causes a failure? Keeps the truth in view: speed without stability is just deferred work.
Time to restore (MTTR)
How quickly do you recover from an outage? Resilience is a capability — and it is measurable.
Why does this work where LoC fails? Because the four metrics sit in tension with one another. You cannot simply deploy faster without the failure rate sending the bill. That built-in balance is exactly what makes DORA hard to game.
Why DORA metrics alone are not enough
DORA measures how well you deliver — but not whether you deliver the right thing, and not what it feels like to work in this team. A team can have excellent DORA scores and still build past the market or quietly burn out. That is why you need two more layers.
Outcome over output
The question is not “how much was built?” but “where did the energy go?” An honest investment mix — features vs. bugs vs. maintenance vs. ops, rolled up by product area — is often the most revealing number in the whole company.
It answers the CFO question “where did the engineering budget go?” with defensible data instead of a shrug.
Experience: the SPACE framework
SPACE (from the same researchers behind DORA) is a reminder that productivity is multi-dimensional: Satisfaction, Performance, Activity, Communication, Efficiency & flow.
The core idea: always combine at least two dimensions — and mix objective signals (system data) with subjective ones (developer sentiment). A single dimension lies.
The 2026 twist: AI breaks the old velocity numbers
With Claude Code, Cursor and internal copilots, the old assumptions have dissolved. When a developer produces in an hour what used to take a day, commit counts and LoC are finally worthless — they go up while their signal drops to zero.
AI shifts the bottleneck from writing code to reviewing, integrating and owning it. To measure honestly in 2026 you need to see two extra things: where AI is actually used (and at what cost) and whether quality keeps up — otherwise you optimize speed at the expense of the change-failure rate without noticing.
Velocity metrics that ignore AI are simply wrong in 2026. The right measures stay the same — flow, outcome, experience — but the signal sources have to include the AI-augmented reality.
The most important rule: do not weaponize metrics
Even the best metrics do damage when pulled to the wrong level. Three guardrails we enforce in every team:
Do not apply system metrics to individuals. DORA evaluates the delivery pipeline, not “developer X”. Individual rankings built from activity data create fear and the wrong behavior — not better engineering.
Metrics are conversation starters, not verdicts. An unusual number is a question (“what is blocking here?”), not an answer. The value is created in the 1:1, not in the dashboard.
Fair reviews need multiple sources. Code, reviews, collaboration and growth belong together — with bias checks. A single number as the basis for a promotion is never fair.
From concept to practice
All of this can be built by hand — many teams pull DORA numbers from GitHub exports, track sentiment in a spreadsheet, and fold in 1:1 notes from a private notebook. It works, but it costs time every week that should go into coaching. That is exactly why we built DevInsight — the visibility module of our Engineering Intelligence Platform.
DevInsight pulls DORA from real repository data, connects Git, Jira, Claude Code, Cursor, 1:1 notes and peer feedback into four lenses (Individual, Team, Department, Business Value), and suggests concrete 1:1 topics via the Manager Copilot — grounded in actual work patterns. Hosted as SaaS in Frankfurt, EU data residency, GDPR by design. So you do not have to wire up the frameworks above yourself — or you do, and use this article as the blueprint.
The short version for your next review
- ✓ Never make a single metric the target — Goodhart's law strikes reliably.
- ✓ Combine three layers: flow (DORA), outcome (investment mix), experience (SPACE).
- ✓ Apply system metrics to teams, never as an individual ranking.
- ✓ Mix objective and subjective signals — one dimension lies.
- ✓ Measure AI usage and quality explicitly — old velocity numbers are worthless in 2026.
- ✓ Treat metrics as a conversation starter, not a verdict.
Want to see these layers without spreadsheet chaos?
DevInsight is in closed alpha — first month free, guided onboarding, SaaS in Frankfurt. Or book a demo and we will walk through your concrete signals together.
