Engineering Metrics Guide: What to Measure and How to Use It

Metrics are one of the most powerful and most dangerous tools in a tech lead's arsenal. Used well, they illuminate problems, track progress, and enable data-driven conversations with stakeholders. Used poorly, they create perverse incentives, destroy trust, and make teams optimize for the wrong things. The difference lies not in which metrics you track but in how you think about them, communicate them, and act on them.

After leading engineering teams through two decades of evolving measurement practices — from lines of code (a terrible metric) to DORA metrics (much better) to developer experience surveys (essential) — I have developed a practical framework for engineering metrics that drives real improvement without the toxic side effects. This guide shares that framework.

1. The Metrics Philosophy: Measure Systems, Not People

Before tracking a single metric, establish the right philosophy with your team. The most important principle is this: metrics measure system performance, not individual performance. The moment you use metrics to evaluate, rank, or compare individual engineers, you have created an adversarial dynamic that will corrupt every measurement you take.

Engineers are smart. If commits per day affects their review, they will make smaller, more frequent commits. If lines of code matter, they will write verbose code. If PR merge time is tracked, they will rubber-stamp reviews. Every metric you tie to individual evaluation will be gamed — not because engineers are dishonest, but because incentives shape behavior.

The Right Framework

• Metrics are diagnostic tools, like vital signs in medicine. They indicate health, they do not prescribe treatment.
• Track trends over time, not absolute values. A team improving from 40% to 60% test coverage is healthier than a team that has always been at 80% but is declining.
• Use metrics to ask better questions, not to jump to conclusions. A spike in cycle time is not a problem — it is a prompt to investigate why.
• Always pair quantitative metrics with qualitative input. The numbers tell you what is happening. The team tells you why.

The best use of engineering metrics is not to prove something to management. It is to create a shared understanding within the team of how they are doing and where they can improve. When the team owns the metrics, they own the improvement.

2. The DORA Metrics: Your Foundation

The DORA (DevOps Research and Assessment) metrics are the most well-validated engineering metrics available, backed by years of research published in the annual State of DevOps reports and the book "Accelerate." They measure software delivery performance through four key metrics:

Why DORA Metrics Work

Unlike most engineering metrics, DORA metrics are outcome-oriented. They measure what matters to the business (delivery speed and reliability) without prescribing how teams should work. A team can improve their DORA metrics through better automation, better testing, better architecture, better processes, or any combination — the metrics are agnostic about approach.

Implementing DORA Metrics

Start with what you can measure easily. Most teams can instrument deployment frequency and lead time for changes within a day by querying their CI/CD system. Change failure rate requires defining what constitutes a "failure" (I recommend any deployment that triggers a rollback, hotfix, or incident). Mean time to recovery requires incident tracking. Get the basics in place first, then refine the definitions over time.

3. Beyond DORA: Additional Metrics That Matter

DORA metrics are necessary but not sufficient. Here are additional metrics I track with every team:

Cycle Time

The total time from when work starts (first commit or ticket moves to "in progress") to when it is in production. This is more granular than DORA's lead time for changes and helps you identify bottlenecks in your development process — long review times, slow CI, manual deployment steps, or excessive work-in-progress.

Work in Progress (WIP)

The number of items actively being worked on by the team at any given time. High WIP is a leading indicator of problems — context switching, long cycle times, and increased risk of conflicts. I have consistently found that reducing WIP is the single fastest way to improve team throughput, even though it feels counterintuitive.

Rework Rate

The percentage of completed work that requires changes after review or after deployment. High rework rates suggest unclear requirements, insufficient design upfront, or gaps in code review quality. Track this separately for pre-production rework (caught in review) and post-production rework (bugs and incidents). See our technical debt management guide for how rework rate connects to debt accumulation.

PR Review Turnaround

Time from PR submission to first review and time from PR submission to merge. Slow reviews create WIP, reduce flow, and frustrate engineers. I recommend targeting less than 4 hours for first review and less than 24 hours for merge on standard PRs.

On-Call Burden

Number of pages per on-call shift, time spent on incident response, and the distribution of on-call burden across the team. An inequitable or heavy on-call rotation is a major factor in engineer burnout and attrition.

4. Developer Experience Metrics

Quantitative metrics tell you what is happening. Developer experience (DevEx) metrics tell you how engineers feel about what is happening. Both are essential.

Developer Satisfaction Surveys

Run a quarterly developer experience survey with questions like:

• "How productive do you feel on a typical day?" (1-5)
• "How often are you blocked waiting for something outside your control?" (Never / Rarely / Sometimes / Often / Always)
• "How confident are you that our codebase is well-tested and reliable?" (1-5)
• "How confident are you that deploying code will not cause issues?" (1-5)
• "Would you recommend this team to a friend looking for an engineering role?" (1-10, NPS style)

Track trends over time. A declining satisfaction score is an early warning signal that precedes attrition, reduced velocity, and quality problems.

Flow State Metrics

Track interruptions: meeting load (percentage of time in meetings), context switches per day, and unplanned work ratio. Engineers do their best work in flow state, and your job as a tech lead is to protect flow time. If your engineers spend more than 30% of their time in meetings, something is wrong.

Build and Test Times

How long does it take to run the full test suite locally? How long does CI take? These are direct measures of developer experience that compound across every commit, every day, for every engineer. A CI pipeline that takes 30 minutes instead of 5 minutes costs your team hundreds of hours per year in context switching and waiting.

5. Quality and Reliability Metrics

Escaped Defects

Bugs that reach production, categorized by severity. Track the trend over time and look for patterns — are certain areas of the codebase producing more defects? Are specific types of changes riskier? This data should inform your testing strategy and code review focus areas.

Test Coverage (With Caveats)

Test coverage is useful as a floor, not a target. A minimum coverage threshold (e.g., 70% for new code) prevents untested code from accumulating, but chasing 100% coverage leads to brittle, low-value tests. Focus coverage on critical business logic, edge cases, and historically buggy areas rather than chasing a number.

Incident Metrics

Track incident frequency, severity distribution, time to detect, time to resolve, and time to recover. Over time, you should see fewer incidents, lower severity, and faster resolution. If incidents are increasing despite stable or growing traffic, your reliability investment is insufficient.

SLA/SLO Compliance

If you have defined service level objectives, track compliance. Error budget consumption rate tells you whether you can afford to move fast or need to slow down and invest in reliability.

6. Vanity Metrics to Avoid

Not all metrics are created equal. Some look impressive in dashboards but provide no actionable insight or actively mislead:

• Lines of code: Measures volume, not value. The best code changes are often deletions.
• Number of commits: Easily gamed and incentivizes splitting work into meaningless fragments.
• Story points completed: Points measure complexity estimates, not output. Teams that inflate points look productive without being productive.
• Number of PRs merged: Incentivizes small, trivial PRs over meaningful work.
• Hours worked: Measures presence, not productivity. If anything, long hours are a negative signal — they indicate unsustainable pace, poor estimation, or scope creep.
• Test count: More tests are not better tests. A few well-designed tests provide more confidence than hundreds of shallow ones.

7. Goodhart's Law and Perverse Incentives

"When a measure becomes a target, it ceases to be a good measure." — Charles Goodhart

This is the single most important principle in engineering metrics. The moment you turn a metric into a target that has consequences (positive or negative), rational actors will optimize for the metric rather than the outcome it was supposed to represent.

Real-World Examples

• Target cycle time, and teams will skip code review to merge faster
• Target deployment frequency, and teams will deploy trivial changes
• Target bug count, and teams will reclassify bugs as "feature requests"
• Target test coverage, and teams will write tests that exercise code without actually testing behavior

How to Avoid Perverse Incentives

• Use balanced scorecards: Never track a speed metric without a corresponding quality metric. Deployment frequency should be paired with change failure rate. Cycle time should be paired with rework rate.
• Measure trends, not targets: "We want to see cycle time trending downward" is healthier than "Cycle time must be under 3 days."
• Rotate focus: Highlight different metrics at different times based on current priorities. This prevents permanent optimization for one dimension.
• Trust but verify: When a metric improves dramatically, investigate. Genuine improvement is gradual. Sudden jumps often indicate gaming.

8. Building Effective Dashboards

A good dashboard tells a story at a glance. Here is how to build one that is actually useful:

The Three-Layer Approach

1. Executive layer: 4-6 high-level metrics that a VP or CTO cares about. DORA metrics, team satisfaction score, reliability SLOs. One page, updated weekly.
2. Team layer: 10-15 metrics that the team uses for self-improvement. Cycle time breakdown, WIP, PR review turnaround, CI performance, on-call burden. Updated daily or in real-time.
3. Deep-dive layer: Detailed data available for investigation. Individual service metrics, per-component error rates, historical trend analysis. Available on demand.

Design Principles

• Show trends, not snapshots. A single number is meaningless without context. Show the last 12 weeks minimum.
• Use traffic-light colors sparingly. Green/yellow/red creates anxiety and anchors attention on lagging indicators. Use them only for SLO compliance.
• Include commentary. Next to each metric, add a brief note explaining what it means and what the team is doing about it. Dashboards without narrative are just data.
• Make it accessible. If the team cannot access the dashboard easily, they will not look at it. Pin it in Slack, review it in stand-up, display it on a monitor in the office.

9. Communicating Metrics to Stakeholders

Different audiences need different metrics presented differently. This is a critical skill for tech leads — translating technical measurements into business-relevant insights. For a complete framework, see our stakeholder management playbook.

To Engineering Leadership

Focus on DORA metrics, reliability, and team health. Frame the conversation around capability: "We are a high-performing team by industry standards and improving. Here is where we are investing to move toward elite performance."

To Product Leadership

Focus on throughput and predictability. "Our cycle time is 4 days on average with a standard deviation of 2 days. For your Q3 roadmap of 8 features, we can commit to delivering 6 with high confidence and will attempt all 8." Product leaders value predictability over speed.

To Executive Leadership

Focus on business outcomes: reliability (uptime, incident impact), delivery velocity (features per quarter), and efficiency (cost per transaction, infrastructure spend trends). Connect technical metrics to revenue, customer satisfaction, and competitive positioning.

10. Using Metrics for Continuous Improvement

The ultimate purpose of metrics is improvement. Here is the cycle I use:

1. Observe: Review metrics weekly as a team. What changed? What is trending?
2. Hypothesize: Why did this metric change? What is driving the trend?
3. Experiment: Design a small experiment to test your hypothesis. "If we reduce WIP to 3 items per person, will cycle time decrease?"
4. Measure: Track the impact of the experiment over 2-3 sprints.
5. Adopt or abandon: If the experiment worked, make it permanent. If not, learn from it and try something else.

This is the scientific method applied to engineering process improvement. It is rigorous, evidence-based, and avoids the trap of cargo-culting practices that worked for other teams but may not work for yours.

Use retrospectives as the primary forum for metrics-driven discussion. Bring the data, let the team interpret it, and collaboratively decide on experiments. When the team drives improvement based on their own metrics, the improvements stick. When improvement is imposed from above based on metrics the team does not own, resistance is inevitable.

Engineering metrics are a means, not an end. The goal is not to have great numbers on a dashboard — it is to have a high-performing engineering team that delivers value consistently and sustainably. Metrics help you get there, but only if you use them wisely. Master this, and you will be the tech lead who brings clarity and direction to every conversation about engineering performance.