Engineering metrics can be a powerful tool for understanding team health and driving improvement - or a destructive force that incentivises the wrong behaviours. As an engineering manager, knowing what to measure, how to interpret it, and what to avoid is critical. This guide covers the metrics that matter and how to use them wisely.
Why Metrics Matter - and Why They Are Dangerous
Metrics provide visibility into patterns that are otherwise invisible. Without data, you are relying entirely on intuition and anecdote to understand your team's performance, health, and trajectory. Good metrics surface problems early, validate improvements, and create a shared language for discussing performance.
However, metrics are dangerous when they become targets. Goodhart's Law - when a measure becomes a target, it ceases to be a good measure - applies relentlessly in engineering. If you measure lines of code, you get bloated code. If you measure velocity in story points, you get inflated estimates. The key is to use metrics as diagnostic tools, not as performance targets.
- Metrics surface patterns that intuition and anecdote cannot reveal
- They create a shared language for discussing team performance
- Metrics become destructive when they are used as targets or incentives
- Always pair quantitative metrics with qualitative context
DORA Metrics and Delivery Performance
The DORA (DevOps Research and Assessment) metrics - deployment frequency, lead time for changes, change failure rate, and mean time to recovery - are the gold standard for measuring delivery performance. They are well-researched, well-validated, and difficult to game because they measure outcomes rather than activities.
Use DORA metrics to identify bottlenecks and track improvement over time. If your lead time is high, investigate where work gets stuck - is it in code review, testing, deployment, or approval processes? If your change failure rate is climbing, examine your testing practices and deployment safeguards. These metrics are most valuable as starting points for investigation, not as final verdicts.
Avoid comparing DORA metrics across teams with different contexts. A team maintaining a legacy monolith will have fundamentally different metrics from a team building a greenfield microservice. Context matters more than absolute numbers.
Team Health and Engagement Metrics
Delivery metrics tell you what your team is producing. Health metrics tell you whether that production is sustainable. Track indicators such as overtime hours, on-call burden distribution, sprint completion consistency, and voluntary attrition. These signals often predict future delivery problems long before they appear in output metrics.
Regular pulse surveys - short, frequent, anonymous questionnaires - are invaluable for measuring psychological safety, engagement, and satisfaction. Ask questions like: Do you feel safe raising concerns? Are you learning and growing? Do you have clarity about your priorities? Track trends over time rather than fixating on absolute scores.
- Health metrics predict future delivery problems before they materialise
- Track overtime, on-call burden, and attrition as early warning signals
- Use pulse surveys to measure psychological safety and engagement
- Focus on trends over time rather than point-in-time snapshots
Metrics to Avoid
Some metrics cause more harm than good. Lines of code written, number of pull requests merged, and individual velocity scores all incentivise quantity over quality and create perverse incentives. They are easy to measure, which makes them tempting, but they tell you almost nothing about the value being delivered.
Stack ranking engineers based on any metric is particularly destructive. It creates competition where you need collaboration, discourages engineers from helping each other, and drives the behaviours you least want to see. If you must evaluate individual performance, use a combination of qualitative assessment and contextualised metrics rather than raw numbers.
Building a Healthy Metrics Practice
Start with a small number of metrics - three to five - and use them consistently for at least a quarter before adding more. Make your metrics visible to the team and discuss them regularly in retrospectives. When a metric changes, ask why rather than reacting immediately. A single data point is noise; a sustained trend is a signal.
Involve your team in choosing and interpreting metrics. When engineers understand why a metric is being tracked and how it will be used, they are far more likely to engage with it constructively. Transparency about measurement builds trust; measurement conducted in secret breeds anxiety.
Key Takeaways
- Use metrics as diagnostic tools, never as performance targets
- DORA metrics are the best starting point for measuring delivery health
- Pair delivery metrics with health and engagement indicators
- Avoid individual productivity metrics that incentivise quantity over quality
- Involve your team in choosing and interpreting the metrics you track
Frequently Asked Questions
- How do I introduce metrics to a team that is resistant?
- Resistance usually stems from fear that metrics will be used punitively. Address this directly: explain that metrics are for the team's benefit, not for individual performance evaluation. Start with team-level metrics that everyone can influence, such as deployment frequency or lead time. Share the data openly and use it to drive improvements that the team cares about. Once engineers see metrics being used constructively, resistance typically fades.
- What is the right number of metrics to track?
- Three to five core metrics is a good starting point. Fewer than three gives you an incomplete picture; more than seven creates noise and dilutes focus. Choose metrics that cover delivery performance, quality, and team health. You can always add more once your team is comfortable with the initial set.
- Should I measure individual developer productivity?
- This is one of the most debated topics in engineering management. The consensus among experienced managers is that individual productivity metrics - such as commits, PRs, or story points per person - do more harm than good. They incentivise gaming, discourage collaboration, and fail to capture the most valuable contributions engineers make, such as mentoring, code review, and architectural thinking. Focus on team-level outcomes instead.
Access Metrics Dashboards
Explore engineering metrics dashboards, DORA tracking templates, and team health survey tools designed for data-informed engineering managers.
Learn More