Every quarter, someone asks: “How do we measure developer productivity?”

Every quarter, the wrong metrics get chosen. Lines of code. Story points completed. PRs merged. Commits per day. And every quarter, engineers game whatever metric you chose, ship lower-quality software, and resent the people who imposed the measurement.

The problem isn’t measurement. The problem is measuring the wrong things — and measuring them for the wrong reasons.

The Metrics That Destroy Teams

Let me be direct about what not to measure, and more importantly, why each one fails:

Lines of Code

A developer who writes 500 lines has often done worse work than the developer who deleted 500 lines. The best code is code that doesn’t need to exist. The most impactful engineering work often involves removing complexity, simplifying systems, and finding solutions that require less code — not more.

Measuring lines of code incentivizes verbosity, code duplication, and over-engineering. It punishes the engineer who refactors a 500-line function into a 50-line function that’s more readable, testable, and maintainable. And it completely ignores the work that produces zero lines of code but enormous value: architecture design, code review, debugging, documentation, and mentoring.

Story Points

Story points were designed for estimation, not performance evaluation. They’re a planning tool — a way for a team to gauge how much work they can commit to in a sprint based on relative complexity.

The moment you tie story points to performance reviews, the metric is corrupted. Teams inflate their estimates: a story that should be a 2 becomes a 5. Everyone “delivers” more points. The sprint velocity chart goes up and to the right. Dashboard looks great. Nothing actually ships faster. Feature delivery might even slow down because inflated estimates mean fewer stories are committed per sprint.

Worse, story points are subjective and incomparable between teams. Team A’s 5-pointer is Team B’s 2-pointer. Comparing teams by story point velocity is meaningless, but management does it anyway because the numbers exist and humans are compelled to compare numbers.

Hours Logged

Knowledge work doesn’t correlate with hours. A developer who solves a critical architecture problem during a 20-minute shower has created more value than the developer who spent 60 hours building a feature nobody needs.

Measuring hours incentivizes presence, not productivity. Engineers stay late because time-at-desk is visible and valued. They take longer to complete work because finishing quickly would mean being assigned more work at the same hourly rate. The organization optimizes for busyness rather than outcomes.

PRs Merged / Commits per Day

These metrics create an incentive to split work into tiny, trivial PRs that inflate the count. Ten PRs that each change one line of code aren’t more productive than one PR that changes ten lines — they’re less productive because each PR requires review, CI/CD execution, and merge coordination.

What Actually Matters

DORA Metrics

The four DORA metrics — developed by the team behind the “Accelerate” research program spanning seven years and thousands of engineering teams — are the closest thing we have to validated engineering performance indicators:

1. Deployment Frequency: How often you ship to production. High-performing teams deploy on demand, multiple times per day. Low-performing teams deploy monthly or less frequently.

2. Lead Time for Changes: Time from commit to production. High-performing teams measure this in hours. Low-performing teams measure it in months.

3. Change Failure Rate: Percentage of deployments causing incidents or requiring rollback. High-performing teams are below 5%. Low-performing teams exceed 45%.

4. Mean Time to Recovery (MTTR): How fast you recover from failures. High-performing teams recover in under an hour. Low-performing teams take days.

These work because they’re system-level metrics, not individual metrics. They measure the capability of the engineering system — the CI/CD pipeline, the testing infrastructure, the deployment process, the monitoring stack — not the output of specific humans.

Why DORA metrics are resistant to gaming: Deploying more frequently without maintaining stability increases your change failure rate. Reducing lead time by skipping tests increases incidents. The four metrics create a balanced system where optimizing one at the expense of another is immediately visible.

Developer Experience (DevEx)

The SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency) adds dimensions that DORA misses — particularly the human dimensions that predict long-term team health:

Satisfaction: Do developers enjoy working here? Are they proud of the systems they build? Would they recommend their team to a friend? Survey-based, measured quarterly, and the strongest predictor of engineer retention.

Performance: Can developers accomplish their goals? Not “how much did they produce” but “did they achieve what they set out to achieve?” This is outcome-based, not output-based.

Activity: Are developers engaged? Activity metrics (commits, PRs, code reviews) are signals, not targets. They indicate engagement patterns but should never be used as performance goals.

Communication: Do teams collaborate effectively? Measured through PR review turnaround time, cross-team collaboration frequency, and documentation quality.

Efficiency: How much time is spent on productive work versus waiting, context-switching, or fighting tooling? The most revealing DevEx metric: “How often do you have to wait for something you need to do your job?” This single question captures build times, PR review delays, environment provisioning waits, unclear requirements blocking progress, and approval bottlenecks.

The Implementation Framework

Here’s how to actually implement metrics without creating a surveillance culture that drives your best engineers to competitors:

Rule 1: Measure Teams, Not Individuals

Individual metrics are inherently gameable and destroy collaboration. If one developer helps three teammates debug critical issues — spending their entire week unblocking others — their “individual productivity” looks terrible while their actual contribution is the most valuable on the team.

Team-level metrics incentivize the behavior you actually want: collaboration, knowledge sharing, collective ownership, and mutual support. When the team’s deployment frequency is the metric, helping a teammate ship is as valuable as shipping yourself.

Rule 2: Use Metrics for Diagnosis, Not Judgment

A declining deployment frequency doesn’t mean the team is lazy. It might mean the test suite has become too slow to run efficiently. It might mean the code review process is bottlenecked on a single Senior Engineer. It might mean the architecture has become so brittle that nobody wants to deploy on Friday.

Metrics reveal symptoms. Humans diagnose causes. When a metric moves in the wrong direction, the correct response is curiosity (“why is this happening?”) not blame (“who caused this?”). The moment metrics are used punitively, engineers stop trusting the measurement system and start optimizing for metric appearance rather than actual productivity.

Rule 3: Let Teams Choose Their Own Improvement Targets

Present the data. Let the team decide what to improve and how. They understand their context better than any dashboard or management directive ever will.

A team that decides to improve their PR review turnaround time because they’ve identified it as their biggest bottleneck will implement a solution that works for their workflow. A management directive to “reduce PR review time to under 4 hours” will produce rubber-stamp reviews that approve everything quickly without actually reviewing the code.

Rule 4: Measure the System, Not the People

How long does it take to get a PR reviewed? How often do builds break? How many hours per week are spent on operational toil? How long does it take to provision a development environment? How many manual steps are in the deployment process?

These are system problems with system solutions. They improve through infrastructure investment, process design, and tooling — not through individual performance management.

Rule 5: Make Metrics Visible and Voluntary

Post the DORA metrics on a team dashboard. Make them visible to the team. Don’t send them to leadership in a weekly report that compares teams against each other. Teams that can see their own metrics improve naturally because engineers are intrinsically motivated to do good work. Teams that are compared against each other in management reports optimize for appearances.

The One Metric I’d Choose

If I could only track one thing — one single number that tells me whether an engineering organization is healthy — it would be this:

Time from “idea validated” to “running in production.”

This captures everything — planning efficiency, development speed, code review latency, CI/CD performance, testing coverage, deployment risk tolerance, infrastructure reliability, and organizational trust. If this number is going down, your engineering organization is getting healthier. If it’s going up, something is broken — and the breakage could be anywhere in the system.

It also captures the non-engineering factors: do product and engineering agree on priorities? Does the approval process add value or overhead? Does the organization trust engineers to ship without excessive gate-keeping?

This is the metric that matters because it directly measures the thing companies actually care about: how quickly can we deliver value to customers?

---

The Garnet Grid perspective: We help engineering organizations measure what matters and fix what’s slow. Our DevOps maturity assessment identifies exactly where your delivery pipeline is losing time and what to fix first. Explore the assessment →