DORA metrics provide a proven foundation for measuring software delivery performance. But they're not the whole picture. Successful engineering organizations track additional metrics that provide deeper insight into team health, code quality, and developer experience.

The key is choosing metrics that drive the right behaviors. A metric that gets gamed helps no one. A metric that reveals genuine insight and motivates improvement is invaluable.

Cycle Time: The Full Picture

While DORA's lead time measures commit-to-deploy, cycle time captures the full journey from work starting to work delivered. This includes time spent before the first commit: understanding requirements, design, and planning.

Cycle time reveals bottlenecks that lead time misses. If your team spends two weeks understanding requirements before writing code, improving CI/CD won't help much. Cycle time shows where work actually spends its time.

Break cycle time into phases: time in backlog, time in progress, time in review, time in testing, time in deployment. Each phase can be optimized independently. Often, the biggest opportunities are in the phases before coding begins.

Code Review Metrics

Code review is where quality happens—or doesn't. Review metrics help you understand if your review process is healthy.

Time to first review measures responsiveness. Long waits frustrate authors and extend lead time. Many teams target 4 hours or less during business hours. Track this metric and discuss it in retrospectives.

Review cycle time measures how long from opening a PR to merging it. This includes back-and-forth discussion and revision time. Long cycle times might indicate unclear requirements, insufficient context in PRs, or reviewers being too busy.

Review depth is harder to measure but important. Are reviewers actually engaging with the code, or rubber-stamping? Track comments per review, but recognize that some changes legitimately need little feedback.

PR size correlates with review quality. Large PRs get superficial reviews because they're cognitively overwhelming. Track PR size and set guidelines. Many teams target under 400 lines of changes.

Developer Satisfaction

Happy developers are productive developers. Measuring satisfaction helps you identify and address friction before it causes turnover.

Regular surveys capture developer sentiment. Keep them short and frequent—quarterly works for many teams. Ask about tool satisfaction, process friction, learning opportunities, and team dynamics.

The SPACE framework provides a structured approach to developer experience: Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow. Track metrics across these dimensions for a complete picture.

eNPS (Employee Net Promoter Score) asks: would you recommend this team/company to a friend? It's a simple proxy for overall satisfaction and predicts retention.

Flow Metrics

Flow metrics come from lean manufacturing and measure how smoothly work moves through your system.

Work in progress (WIP) measures how much is being worked on simultaneously. High WIP often means lots of context switching and nothing getting finished. Many teams limit WIP to force focus and completion.

Flow efficiency compares active work time to total time. If a task takes two weeks but only has four hours of active work, flow efficiency is poor. Most time is waiting—in queues, for reviews, for deployments.

Throughput measures completed items per time period. Unlike velocity (which measures estimates), throughput measures actual delivery. Consistent throughput is often more important than high throughput.

Technical Debt Indicators

Technical debt is real but hard to measure. Several proxy metrics help assess code health.

Code complexity metrics like cyclomatic complexity identify functions that are hard to understand and maintain. Set thresholds and flag violations in code review. Track complexity trends over time.

Test coverage isn't perfect, but very low coverage usually indicates problems. More useful than overall coverage is tracking coverage of critical paths and new code.

Dependency freshness measures how up-to-date your dependencies are. Outdated dependencies miss security patches and accumulate upgrade work. Track and visualize dependency age.

Hotspot analysis identifies files that change frequently and have high complexity—likely sources of bugs and friction. Prioritize refactoring based on hotspot data.

On-Call Health

On-call burden affects developer quality of life and indirectly affects retention and productivity.

Alert volume per on-call shift should be manageable. More than a few alerts per shift indicates noisy alerting or underlying reliability issues. Track and work to reduce.

Time spent on incidents measures actual disruption. Even if alerts are few, if each incident takes hours to resolve, on-call is burdensome.

Alert actionability measures what percentage of alerts require action. If most alerts are noise, engineers stop paying attention. Aim for high actionability.

Documentation Metrics

Good documentation accelerates onboarding and reduces friction. Measuring documentation quality is tricky but worthwhile.

Documentation coverage asks: do your services, APIs, and processes have docs? Track what percentage of codebases have README files, API documentation, and runbooks.

Documentation freshness measures when docs were last updated. Stale docs are often worse than no docs because they mislead. Flag docs that haven't been touched in months.

Search success rate tracks whether people find what they're looking for in your documentation. High search failure rates indicate gaps.

Onboarding Metrics

How quickly new engineers become productive reveals process and documentation health.

Time to first commit measures how long before a new hire pushes code. Long times indicate setup friction or unclear onboarding paths.

Time to first production deploy is more meaningful—it means the engineer can deliver value independently. Track this and work to reduce it.

Onboarding satisfaction asks new hires about their experience. They see friction that tenured engineers have normalized.

Using Metrics Wisely

Metrics are tools, not goals. When metrics become targets, people optimize for the metric rather than the underlying goal. This is Goodhart's Law: when a measure becomes a target, it ceases to be a good measure.

Use metrics to identify problems, not to evaluate individuals. Metrics should prompt questions and investigations, not punishments. "Why is cycle time increasing?" not "Your cycle time is too high."

Balance quantitative metrics with qualitative insight. Numbers don't tell the whole story. Combine metrics with retrospectives, one-on-ones, and observation.

Review and retire metrics regularly. If a metric isn't driving improvement, stop tracking it. If circumstances change, update what you measure.

Getting Started

Don't try to track everything at once. Start with DORA metrics as your foundation. Add cycle time and developer satisfaction for broader context. Layer in additional metrics as specific needs arise.

Automate collection wherever possible. Manual metric collection is error-prone and unsustainable. Use tools that pull data from your existing systems automatically.

Make metrics visible. Dashboards that nobody looks at don't drive change. Put metrics where teams see them daily. Discuss trends in standups and retrospectives.

Beyond DORA: Engineering Metrics That Actually Matter