Every engineering organisation past a certain size is asked to demonstrate that it is improving, and most answer with velocity — a count of story points completed per sprint. It is the wrong number for a simple reason: it measures how the team estimates, not what it delivers, and it can be improved by estimating more generously. Any metric a team can move without changing the outcome will be moved.
Four measures describe delivery capability better and are hard to game. Deployment frequency: how often you ship to production. Lead time for change: how long from a commit to that commit running in production. Change failure rate: what proportion of deployments cause a problem needing a fix or rollback. And time to restore service when something breaks. Together they capture speed and stability, which is what matters, and improving one at the expense of another shows up immediately.
The reason these are worth adopting is the relationship between them. The intuition is that shipping faster means breaking things more, and in practice the opposite holds: teams that deploy frequently deploy smaller changes, which are easier to review, easier to diagnose and easier to reverse. A team deploying once a quarter has a change failure rate driven by the size of its releases. If your instinct is to slow down to be safer, these four numbers are the argument against it.
Instrument them from data you already have rather than asking people to report. Deployment frequency comes from your pipeline. Lead time comes from commit timestamps against deploy timestamps. Change failure rate needs a convention — a tag on incidents caused by a deploy — and time to restore comes from your incident records. If any of these cannot be measured automatically, that itself is the finding: a team that cannot tell you how long its changes take to reach production does not have visibility of its own process.
Use them at the level of a team over time, never to compare teams or individuals. A team maintaining a legacy payments system will have a longer lead time than one building a new internal tool, and that difference says nothing about either. The only comparison that means anything is a team against its own trend, and the moment these numbers are used in performance reviews they become numbers people manage rather than numbers that inform.
Finally, remember what they do not measure. None of the four tells you whether you built the right thing. A team with excellent delivery metrics shipping features nobody uses is efficiently going nowhere. Pair them with something about outcomes — adoption of what shipped, support volume, whether the business result the work was meant to produce actually happened — or you will optimise the machine and never ask what it is producing.
