Engineering Metrics: What to Measure and What to Avoid

Engineering Metrics: What to Measure and What to Avoid

Engineering metrics can surface genuine insights about team health, delivery performance, and software quality — or they can create perverse incentives and measurement theatre that wastes time and damages morale. Choosing what to measure, and what not to measure, is more important than the metrics themselves.

DORA Metrics

The DORA (DevOps Research and Assessment) metrics are the most evidence-backed set of engineering delivery metrics. Derived from research across thousands of organisations, they correlate strongly with business outcomes:

• Deployment frequency: How often code is deployed to production. High performers deploy multiple times per day.
• Lead time for changes: Time from code committed to running in production. Shorter is better.
• Change failure rate: Percentage of deployments that cause a production incident. Target <5%.
• Failed deployment recovery time: How long to recover from a production failure.

Metrics to Avoid

• Lines of code: Easy to game, meaningless as a productivity measure
• Tickets closed: Encourages ticket farming and closing without resolution
• Code coverage alone: 90% coverage with bad tests is worse than 70% with good ones
• Velocity as a cross-team comparison: Story point estimates are relative within a team, not comparable between teams

The Right Question

Ask "what behaviours will this metric encourage?" before adopting it. Good metrics create incentives that align with good outcomes. Bad metrics create incentives that are separate from or oppose good outcomes.