Long ago I worked on a team that was the quintessential story: understaffed, overassigned, always on the verge of completely flying apart at the seams. Our backlog continually grew despite the heroic efforts of this super-dedicated little crew.
Management, however, didn't see it that way.
Our director’s analytics team began sending shiny dashboards to our manager: charts full of trends and deltas. According to the data, our “velocity” was dropping and our “defect rate” was rising. But we weren’t slacking off; we were deep in the trenches untangling years of organization-wide technical debt.
That’s when I learned something important: the data wasn’t wrong, it was just disconnected.
When the Numbers Don't Match the Reality
Metrics don’t lie; they just don’t know the truth. Without context, they become stories told by strangers about work they’ve never seen. If you’ve ever watched a team of engineers react to a dashboard review, you’ve seen it happen: the quiet eye-roll, the sideways glance, the unspoken “that’s not what’s actually happening.”
It’s not cynicism... It’s pattern recognition.
Engineers live close to the work. They see the merge conflicts, the on-call pages, the half-finished migrations. When a slide full of metrics claims something wildly different, like “velocity is down 20%" or “PR throughput is up 50%”, it signals that the measurement system and the reality system are out of sync. The data isn’t necessarily wrong, it’s just been abstracted past the point of usefulness. Somewhere between the build logs and the boardroom, the story got summarized into numbers that no longer mean what they used to mean. And that’s where trust breaks.
*Because when engineers can’t connect the numbers on the screen to the work in their hands, those numbers stop being information and start feeling like judgment. *
What Engineers Really Want from Metrics
Metrics are credible when they:
- Reflect what’s actually happening. They have clear definitions. They're collected consistently. Everybody knows what they mean and what's expected.
Connect to goals the team values. By this I mean Quality, Reliability, Impact... not "optics"! If the team relates to the reason for the metric, they'll move heaven and earth to hit it!
Have drill-down paths. It might be impressive that you've condensed all your productivity data to a single scorecard, but... if nobody can follow up and debug when things seem "off", you'll engender zero trust in your mighty dashboard. You might say: “Metrics should feel inspectable, like source code.”
It seems simple; maybe even a no-brainer... so how is it so easy to end up so far off the mark?
The Three Metric Traps
Here's when metrics become problematic:
The Vanity Trap
Your metrics look amazing... but mean nothing. These are usually the easy ones to measure, but they're useless. Think "lines of code written" or "commits per week".
The Volume Trap
You've instrumented every aspect of your system and you're measuring everything “just in case”. "More" is not "better"! This is problematic in a couple ways: for one, you're going to spend more time and money managing the deluge of measurements. You'll also have to sift all those measurements constantly, slowing down the time to insight. It's much better to simply pick a few key points and focus on those.
The Proxy Trap
We fall into the Proxy Trap when things get complicated to measure. Say you wanted to know about Code Quality... you might be tempted to pick something simple to measure, like "Pull Request Count" or "Unit Test Coverage", and stop there. In the words of John Cutler, "Powerful Ideas Imperfectly Measured > Perfect Measures For Not as Powerful Ideas". You'll learn more from measuring the right things, even if the measurement isn't as exact.
Notice anything about these traps? Each of the traps erode trust because they signal measurement for management, not measurement for learning. Be honest about your goals... why are you actually measuring this?
Building a Trustable Metric Set
What makes your metrics trustworthy?
Few, meaningful metrics aligned to goals (quality, delivery, learning, user value).
Clear provenance: It's well-known where the data comes from and what it excludes.
Leading and lagging pairs: e.g., “lead time” (delivery) vs. “user satisfaction” (outcome).
Ability to question or explore: anyone should be able to trace how the number is made.
The Real Message: Measure Less, Understand More
Once I saw the metrics used to measure our team, I transferred to the analytics group and worked to change those reports. I used my firsthand experience to design metrics that told our story more accurately: ones that aligned what management saw with what the team actually lived.
It didn’t take long for things to improve. Once we reached agreement on what the numbers meant, the tension disappeared. We didn’t fix the team by optimizing the metrics, we fixed it by rebuilding trust through shared understanding.
Metrics don’t create alignment: Conversations do.
The numbers only help when they’re an invitation to talk, not a substitute for it.
The moment your dashboard becomes a shared language, one where everyone knows what the numbers include, exclude, and imply, that’s when the eye-rolls stop. That’s when engineers start nodding instead.
Maybe that’s the real secret to a good dashboard:
it doesn’t prove you’re doing well.
It reminds you that you’re on the same team.
Top comments (0)