Engineering KPIs That Actually Matter (and Survive Contact With Reality)

The Six KPIs That Survive

1. Deployment frequency — your heartbeat

How often your team deploys to production. It is cheap to measure and hard to game at the team level — you cannot fake frequent production deploys. A collapsing deployment frequency is the earliest visible symptom of a slowed-down delivery system. The DORA target baseline for elite teams is on-demand, and anything under weekly for small SaaS teams is a red flag.

2. Lead time for changes — end-to-end responsiveness

From first commit to production. This is the highest-signal KPI because it concatenates review speed, CI reliability and release cadence into one number. It also comes with a built-in diagnostic path: when it deteriorates, decode it stage by stage rather than averaging it.

3. Change failure rate — the quality counterweight

The share of deployments that degrade service (rollback, hotfix, incident). Speed without this number is how teams talk themselves into reckless releases. The counterweight exists to be read together with deployment frequency — elite is under 5%, and a rising trend tracks debt accumulating in your release process.

4. Time to restore — recovery beats prevention

When production breaks, how long until service is back. DORA calls it MTTR. The uncomfortable finding behind this metric is that recovery capability correlates more with sustained delivery speed than prevention does: teams that recover fast are the ones that deploy fast, because the same trust that enables frequent deploys enables fearless rollbacks.

5. Review latency — the most actionable one

Time to first review and turnaround on PRs. This is the KPI you can move this week with a norm change, and it feeds directly into lead time. If a KPI deck has one candidate for immediate action, it is this one.

6. Knowledge concentration — predicts your future speed

What share of your critical modules can be changed safely by more than one person? It is a lagging, hidden number — but it predicts whether your lead time survives someone taking a vacation. Bus factor of one on core services is a speed loan you are already repaying.

The rule: if a KPI cannot be stated in one sentence with its trend and its cause, it is dashboard decoration.

What to Cut

Commit count

Measures typing, not delivery. Micro-commits are free to game.

Story points velocity

Estimated units inflate at the exact rate you compare teams or sprints. As a KPI it self-destructs on contact with incentives.

Tickets closed

Closing tickets is a workflow event, not an outcome. Track what shipped to production instead.

How to Run It Without Micromanaging

Every KPI above is derivable from repository and deployment events — no timesheets, no self-reporting, no per-developer surveillance. Track them at the team level, review trends monthly, and share them in a place every engineer can see. Metrics that appear suddenly in a one-on-one are surveillance; metrics visible to the whole team are instrumentation.

DevLyTicks turns your GitHub repositories into a live dashboard covering DORA metrics, review latency and knowledge concentration — no manual reporting, at devlyticks.com.

Conclusion

Six KPIs survive contact with reality: deployment frequency, lead time, change failure rate, time to restore, review latency, and knowledge concentration. Everything else is either a leading indicator feeding into these or dashboard furniture. Start with the heartbeat — deployment frequency — and add the rest as your team learns to read them.