Scale ScoreEngineering KPIs
Most engineering metrics measure activity. Activity is easy to count and easy to inflate, which is why dashboards full of it tend to look healthy right up until something goes wrong. The metrics worth tracking measure outcomes: how quickly work reaches customers, and how often it breaks when it gets there.
The four that hold up
These come from the DORA research programme and have survived more scrutiny than anything else in this space. They are also readable without an engineering background, because all four are expressed in time or frequency.
| Metric | What it tells you | Healthy direction |
|---|---|---|
| Deployment frequency | How often finished work actually reaches customers. A proxy for batch size and confidence in the release process. | Higher |
| Lead time for changes | How long from a change being written to it being live. Exposes queueing and manual steps that status meetings hide. | Lower |
| Change failure rate | What proportion of releases cause a problem needing a fix or rollback. The counterweight that stops the first two being gamed. | Lower |
| Time to restore service | How long recovery takes when something breaks. Often more commercially important than preventing the breakage. | Lower |
The four work as a set. Deployment frequency alone rewards shipping recklessly; change failure rate alone rewards shipping nothing. Together they are hard to move without genuinely improving.
Metrics that get gamed
These appear on a lot of dashboards and are worth treating with suspicion:
- Lines of code. Measures typing. Rewards verbosity and punishes the deletion that usually improves a codebase.
- Story points completed. Relative to one team's own baseline, so cross-team comparison is meaningless, and the units drift upward the moment anyone is measured on them.
- Commit or pull request count. Trivially inflated by splitting work into smaller pieces, which is not the same as delivering more.
- Ticket closure rate. Rewards closing easy tickets and leaves hard ones to rot.
- Individual velocity. Beyond being noisy, it discourages the reviewing, mentoring and debugging that make everyone else faster.
The pattern: anything an individual can move on their own, without the product improving, will eventually be moved that way. Not through bad faith, just through ordinary response to measurement.
Reading them without being misled
A number on its own is rarely the story. Three habits help:
- Watch the trend, not the value. There is no universal good deployment frequency. There is a clear difference between one that is climbing and one that is falling.
- Always pair a speed metric with a quality one. Lead time falling while change failure rate climbs is not an improvement, it is a warning.
- Ask what changed, not who. The useful conversation after a metric moves is about the process. The moment it becomes about individuals, the numbers stop being trustworthy, permanently.
What these do not tell you
Delivery metrics say nothing about whether the right thing is being built. A team can score excellently on all four while shipping features nobody uses. They also say little about maintainability, security posture or key-person risk, which is why technical due diligence looks well beyond them.
For the practices that produce these outcomes rather than the outcomes themselves, see the DevOps maturity model. Levels 2 and 3 are what move all four of these numbers.