Measuring Developer Productivity Without Destroying It
Every engineering leader wants to measure developer productivity. Most attempts backfire. Counting lines of code, tracking hours logged, monitoring commit frequency — these metrics are trivially gameable and actively harmful. Developers optimize for whatever you measure, and if you measure the wrong thing, you get the wrong behavior.
DORA metrics offer a better approach. They measure outcomes (how effectively does your team deliver software?) rather than activity (how busy do your developers look?).
The Four DORA Metrics
The DevOps Research and Assessment (DORA) team, now part of Google Cloud, identified four metrics that correlate with both software delivery performance and organizational outcomes:
Deployment Frequency — How often your team deploys to production. Elite teams deploy multiple times per day. Low performers deploy monthly or less frequently.
Lead Time for Changes — Time from code commit to production deployment. Elite teams: under an hour. Low performers: over six months. This measures your entire delivery pipeline — code review time, CI build time, staging validation, deployment process.
Change Failure Rate — What percentage of deployments cause a failure (rollback, hotfix, degraded service). Elite teams: 0-15%. Low performers: 46-60%.
Mean Time to Recovery (MTTR) — How quickly you restore service after an incident. Elite teams: under an hour. Low performers: over six months.
What Makes These Metrics Good
DORA metrics are balanced. You can't game one without affecting the others:
- Deploying more frequently without testing increases your change failure rate.
- Slowing down deployments to reduce failures increases lead time.
- The fastest path to good numbers on all four is actually building the right engineering practices — automated testing, CI/CD, monitoring, and incident response.
Measuring Lead Time in Practice
Lead time is the most actionable DORA metric because you can break it into measurable segments:
- Coding time — from first commit to PR opened (not very useful to measure, highly variable)
- Review time — from PR opened to PR approved. This is where many teams have the biggest bottleneck. Median review time over 24 hours suggests review process problems.
- Merge to deploy time — from merge to production. This measures your CI/CD pipeline efficiency.
Tools like LinearB, Sleuth, and Faros AI can compute these from your Git and deployment data. If you don't want to buy a tool, a simple approach:
# Measure PR cycle time from GitHub API
gh pr list --state merged --limit 100 --json createdAt,mergedAt | jq '[.[] | {
created: .createdAt,
merged: .mergedAt,
hours: ((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600
}] | {
median_hours: (sort_by(.hours) | .[length/2].hours),
avg_hours: ([.[].hours] | add / length)
}'Beyond DORA: Developer Experience (DevEx)
DORA metrics measure delivery outcomes. Developer Experience (DevEx) metrics measure how developers feel about their tools and processes. Both matter — you can have good DORA numbers and miserable developers (usually through crunch culture and heroics rather than sustainable practices).
The three dimensions of DevEx (from the paper by Noda, Storey, et al.):
Flow State — How often do developers get into a state of focused, uninterrupted work? Measured by: interruption frequency, meeting load, notification volume, context-switching frequency.
Cognitive Load — How much mental effort is required to complete tasks? Measured by: codebase complexity perception, documentation quality, onboarding time, toolchain complexity.
Feedback Loops — How quickly do developers get feedback on their work? Measured by: CI build time, code review turnaround, test execution time, deployment time.
Survey your developers quarterly on these dimensions. The SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency) provides a structured survey approach.
What Not to Measure
Just as important as knowing what to measure:
- Lines of code — A developer who deletes 500 lines while maintaining the same functionality produced more value than one who added 500 lines.
- Commit count — Encourages tiny, meaningless commits.
- Story points completed — Story points are estimation tools, not productivity measures. Teams learn to inflate estimates.
- Individual metrics — Publishing individual developer metrics creates competition instead of collaboration. Measure teams, not people.
The goal of measurement isn't to judge individuals. It's to identify systemic bottlenecks — slow CI, review backlogs, flaky tests, manual deployment steps — and fix them. That's where the real productivity gains come from.