Stop measuring developer productivity the wrong way

The shift already is happening in developer productivity

Most teams don’t have a productivity problem. They have a measurement problem.

Ask ten engineering leaders how they define developer productivity, and you’ll get twelve different answers. One says PRs merged. Another points to DORA metrics. A third mentions time to onboard new engineers. They’re all measuring something—but are they really measuring what matters?

For years, engineering organizations have tried to increase productivity by counting more things: more lines of code, more issues closed, more commits per engineer. But those metrics often tell us about activity, not impact. And worse, they can hide the real problems: burnout, brittle systems, or missed opportunities to build lasting quality.

The truth is, productivity isn’t a single concept. It’s an ecosystem.

A growing body of research shows that teams thrive not by pushing harder, but by focusing on how they work. The strongest predictor of output isn’t how many tickets your team moves. It’s something deeper: Developer Thriving.

Thriving isn’t just happiness. It’s agency, learning, motivation, and belonging. And it’s a more reliable predictor of performance than any raw metric.

Productivity ≠ performance: here’s what we’re actually measuring

Let’s clear something up: productivity is often used as a catch-all, but it actually breaks down into three distinct layers. Each one tells a different story:

• Production = raw output, no context
• Productivity = output relative to effort, time, or resources
• Performance = sustained, high-quality outcomes over time

Example: Two teams might ship the same number of features this quarter. But one built maintainable code, mentored juniors, and paid down tech debt. The other burned out doing it. One team was busy. The other was performing.

When we blur these layers, we misread what our metrics are telling us. That’s how high activity can mask systemic issues or how great teams get overlooked because their contributions don’t show up in the charts.

Why engineering teams get stuck in shallow metrics

Most engineering leaders know traditional metrics fall short. So why do we keep using them?

Because they’re easy to count.

It’s simple to tally PRs or tickets. But those numbers ignore what makes engineering work actually valuable: collaboration, technical learning, mentorship, and resilience. And when we use those activity-only numbers to make decisions, we risk incentivizing the wrong things.

Even worse, metrics without context fuel unfair comparisons between teams. That leads to morale issues, internal competition, and a culture of performance theater.

Here’s the fix: Treat metrics as a reflection of your values. Make sure they match how your teams define success.

That’s where the Developer Thriving framework comes in. It helps leaders look beyond surface activity and toward the conditions that actually support great software work.

Making sustainable performance visible (and measurable)

To support thriving, teams need visibility into more than code volume. They need signals that reflect quality, collaboration, and momentum. Tools like Flow can help spot these when used with intention.

Sustainable performance doesn’t mean working slower. It means working smarter, with quality, clarity, and shared visibility into tradeoffs.

What does that look like in practice?

• Seeing early risk signals like high churn or rework
• Spotting invisible contributions like onboarding and mentorship
• Tracking learning trends and resilience patterns, not just output
• Normalizing retros and reviews that focus on effectiveness, not just speed

These are the patterns linked to Developer Thriving. And they’re what allow performance to compound over time.

Best practices to reframe your productivity strategy

If you want to shift from shallow activity metrics to meaningful performance insights, start here:

• Audit your existing metrics. What are they rewarding? What’s missing?
• Track over time, not in snapshots. Look for trends, not just weekly velocity.
• Don’t benchmark across teams. Productivity is contextual. What works for Team A may not apply to Team B.
• Use shared definitions. Is your team aligned on what “productive” looks like? Are you valuing glue work, onboarding, mentoring?
• Layer in quality and context. Metrics like lead time or cycle time only make sense when you understand what’s behind them.
• Treat glue work like velocity insurance. It won’t move your burndown chart—but it prevents burnout and makes everything else run smoother.

Remember: the goal isn’t just faster work. It’s better outcomes.

Common traps and what they cost you

It’s time to stop asking “how much?” and start asking “what matters?”

Great teams don’t just ship more. They learn faster. Solve smarter. And create healthier, more sustainable outcomes.

That starts with changing the way we measure. Not just to count more things but to surface the stories those numbers can’t tell on their own.

Want to measure what actually matters to your teams?