The VP of Engineering stood at the front of the all-hands meeting, beaming as he projected the new "Developer Productivity Dashboard" onto the massive screen.
Lines of code committed per developer. Pull request cycle time. Tickets closed per sprint. Active hours in the IDE.
"Look at this," he said, gesturing triumphantly. "We've increased our output by 37% since last quarter."
Nobody clapped. The developers in the room exchanged glances—the kind that said we all know what's actually happening.
So I'll say it out loud.
We've built an entire industry around measuring things that don't matter.
The Dashboard Didn't Show
It didn't show the four-hour debugging session caused by rushed, untested code.
It didn't show the architectural debt accumulating because story points reward shipping, not designing.
It didn't show the junior developer who took three days to fix a bug caused by the senior's "efficient" work.
It didn't show the silent exodus of senior engineers who knew productivity theatre wasn't worth their sanity.
We're not measuring productivity. We're measuring activity. And we've convinced ourselves that's the same thing.
The Metrics That Actually Kill Teams
PR Cycle Time — Fast reviews mean shallow reviews. The best code review I ever received took four days. It found a race condition that would've taken down our payment system.
Ticket Closure Rate — We celebrate the developer who closes twenty tickets, ignoring that twelve of them were "fix spelling error" tasks. Meanwhile, the dev who closed five solved the root cause of fifty future tickets.
Lines of Code — My most productive week? I removed 3,000 lines. The dashboard showed "underperforming."
Active Hours in IDE — We don't track the two hours of thinking while walking around. We don't track the whiteboard session that saved three weeks of work. Thinking is the work. Coding is just how we capture it.
What Actually Matters
Here's what I wish we measured instead:
- How quickly new engineers make their first meaningful contribution
- Time wasted on context switching across poorly documented systems
- How much cognitive load is required to keep things running
- How many shipped features actually get used
- Hours spent in flow state versus interrupt-driven chaos
You'll never see this dashboard. Because you can't put these on a slide deck. You can't show "cognitive load reduction" in story points. So we measure what's easy, optimize for what's measured, and wonder why everything feels broken.
The Quiet Truth
The most productive teams I've been on didn't have productivity dashboards. They had:
- Senior engineers who said "slow down, let's think"
- Cultures where asking questions was celebrated
- Time for refactoring in every sprint
- Reviews that were substantive, not fast
- Permission to say "this isn't ready"
They looked slow by every metric. They shipped features that worked, rarely broke, and made customers happy.
So here's my question to every engineering leader:
The next time you look at your productivity dashboard, ask yourself: Am I measuring the work, or am I measuring the activity?
Because right now, we're building the wrong incentives. And real productivity—the kind that builds great software, grows great engineers, and makes customers actually happy—is quietly dying, one dashboard metric at a time.
P.S. — The dashboard was green. The product was failing. Customers were angry. And nobody asked why the numbers looked so good while everything felt so wrong.
Top comments (0)