Why Your Developer Productivity Metrics Are Measuring the Wrong Thing

Ak Thoha — Fri, 26 Jun 2026 07:46:20 +0000

Your DORA metrics are elite. Your velocity is up. Releases still slip.

You're measuring the pipeline, not what's blocking it.

DORA Sees the End, Not the Wait

DORA metrics are real. Google's research validates them. But they only see one moment: when code ships.

They don't see:

The 6 days a feature sat waiting for security review
The two teams building the same dependency, unaware of each other
The Slack thread where the real blocking decision lives

DORA sees elite teams ship fast. It doesn't see why those same elite teams still slip releases while mediocre teams ship on time.

The answer: visibility. One team can see its dependencies. The other can't.

Story Points Are a Confidence Game

Ron Jeffries invented story points and now regrets it—not because estimation is bad, but because points became a proxy for productivity when they measure neither.

Watch this pattern:

Q1: 45 → 45. Aligned.
Q2: 52 → 50. Velocity up.
Q3: 58 → 54. Charts green.
Reality: Same shipping speed all three quarters.

Teams learned to estimate generously without changing output. It works great until you cross team boundaries and suddenly Team A's 5 points has nothing to do with Team B's 5 points.

SPACE Found the Problem—Then Stopped

GitHub and Microsoft's SPACE framework added communication as a dimension of productivity. Good instinct.

Then it suggested measuring communication with surveys: "Do you feel informed?"

That's a feeling, not a signal.

The real signals hide in Slack threads nobody linked to tickets. PRs waiting on async reviews. Code shipped that silently broke another team's API contract.

SPACE named the problem. It didn't solve the visibility problem.

Three Signals That Show You're Blind

If you want to see what's actually slowing you down, measure this:

Phantom Dependencies How many pieces of work touch code across multiple repos without a formal dependency ticket? Most teams discover these only after merge. Panic mode activated.
Async Resolution Time Slack threads: 5-7 days to resolve blockers. Jira: a few hours. Same information, different container. This tells you something about where knowledge actually lives.
Context-Switching Interrupts UC Irvine research: 23 minutes to regain focus after one interrupt. Count the "who owns this?" moments in one engineer's week. Multiply that across your team. That's real velocity drag.

What Actually Works

Layer 1: Flow Metrics (Keep DORA) Use cycle time, not velocity. Velocity is a number teams learn to adjust. Cycle time is measured time.

Layer 2: Coordination Signals (The Missing Layer) Measure:

Untracked dependencies discovered post-merge per release
How long cross-team blockers sit in async channels
Pre-merge vs. post-merge dependency discovery rate
Unplanned context switches per engineer per week

Connect your tools and ask: "What's actually blocking work across all these systems?"

Layer 3: Outcome Confidence (Forward-Looking) Turn vague status updates into risk forecasts. "We're on track" becomes "72% confidence, main risk is untracked payment team dependency."

The Experiment

Try this on your last 3 releases:

Blind spots: How many cross-team dependencies did you discover only after code shipped?
Async channels: Which Slack threads contain blocking conversations? How long open?
One team, one week: Count "who owns this?" moments.

Most teams find the numbers shocking.

The Real Question

If releases slip despite strong metrics, you're measuring the wrong things.

Not "are developers fast?" but "can we see what's blocking them?"

Teams that surface dependency risk early ship 30-40% faster. Not because they code faster—because they can see.

Start measuring handoffs.

Mythreyi Chandoor builds execution intelligence tooling. 15+ years as a technical program director watching smart teams ship slower than they should—usually because visibility stopped at team boundaries.

Discussion

What's the biggest coordination blocker you see in your engineering org? Where do you lose the most time in handoffs nobody tracks?

Drop your experience in the comments—genuinely curious how others are solving this.

DEV Community: Ak Thoha