Engineering leaders are under pressure to measure everything. Lines of code, velocity, code coverage, pull request metrics — there's no shortage of data. But most of it is noise.
The challenge isn't finding metrics. It's finding the right metrics — the ones that actually correlate with team performance and business outcomes.
The Problem with Most Metrics
Most engineering metrics fall into one of these traps:
**Vanity metrics.** Lines of code, commits per day, pull requests merged. These measure activity, not outcomes. They're easy to game and don't correlate with value delivery.
**Local optimization metrics.** Code coverage, test count, deployment frequency. These are important in isolation, but optimizing them without context can lead to suboptimal outcomes.
**Lagging indicators.** Bug count, incident count, technical debt. These tell you what happened, not what's going to happen. By the time they're visible, the problem has already occurred.
The Metrics That Matter
After years of working with engineering teams, we've found that a small set of metrics consistently correlates with team performance:
### DORA Metrics
The DevOps Research and Assessment (DORA) team has identified four key metrics that predict software delivery performance:
**Deployment frequency.** How often you deploy to production. High-performing teams deploy multiple times per day.
**Lead time for changes.** How long it takes to go from code committed to code running in production. High-performing teams have lead times of less than one day.
**Mean time to recovery (MTTR).** How long it takes to restore service when a service incident occurs. High-performing teams recover in less than one hour.
**Change failure rate.** What percentage of changes to production result in degraded service. High-performing teams have change failure rates of less than 15%.
These metrics work because they measure outcomes, not activity. They're hard to game. And they correlate with business performance.
### Team Health Metrics
Beyond delivery performance, team health matters:
**Developer satisfaction.** Happy developers are more productive, write better code, and stay longer. Measure this regularly through surveys or one-on-ones.
**Cognitive load.** Are developers spending their time on valuable work, or fighting with tools, processes, and legacy systems? High cognitive load reduces productivity and increases burnout.
**Flow state.** How often are developers able to work uninterrupted on complex problems? Frequent interruptions and context switching destroy productivity.
### Business Alignment Metrics
Engineering exists to deliver business value. Measure how well you're doing that:
**Time to market.** How long does it take to get a new feature or product from idea to production? This is the ultimate measure of engineering effectiveness.
**Business impact.** Are the things you're building actually moving business metrics? Track the correlation between engineering output and business outcomes.
**Customer satisfaction.** Are customers happy with the software you're building? Use NPS, support tickets, and user feedback to measure this.
How to Use Metrics
Metrics are only useful if you use them correctly:
**Don't use metrics as targets.** Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure." Use metrics to identify trends and problems, not to set goals.
**Look at trends, not absolutes.** A single data point is meaningless. Look at trends over time. Are things getting better or worse?
**Context matters.** Metrics without context are misleading. A high deployment frequency is good — unless it's accompanied by a high change failure rate.
**Don't optimize locally.** Optimizing one metric at the expense of others leads to suboptimal outcomes. Look at the system as a whole.
**Talk to your team.** Metrics are a starting point, not the whole story. Regular conversations with your team will reveal issues that metrics can't capture.
The Bottom Line
Most engineering metrics are noise. Focus on the few that matter: DORA metrics for delivery performance, team health metrics for sustainability, and business alignment metrics for value delivery. Use them to identify trends and problems, not to set targets or evaluate individuals.
And remember that metrics are a tool, not a goal. The goal is building great software that delivers value to your customers and your business.
If you're trying to improve your engineering organization's performance and want guidance on what to measure, we're happy to share what we've learned.