Engineering metrics dashboard shows all green. Engineering team says everything is red. Someone is wrong, and I’m pretty sure it’s the dashboard.
I’m David, VP of Product at a Series B SaaS startup, and I’ve been wrestling with a credibility crisis: two-thirds of developers don’t believe their productivity metrics reflect their actual work. When the people doing the work don’t trust the measurements, what are we actually measuring?
The gap between what our metrics say and what engineers experience is a fundamental problem. And it’s costing us in ways that don’t show up on dashboards: trust, morale, the willingness to engage honestly about problems.
Here’s what I’ve observed: metrics designed by leadership for leadership rarely reflect reality on the ground.
At my previous company (Airbnb), we had this beautiful engineering dashboard. DORA metrics all trending up and right. Leadership loved our sprint reviews. Meanwhile, engineering team morale was in the toilet, and we didn’t know until people started leaving.
The root cause: we measured outputs (deploys, commits, story points) because they’re easy to track. We missed outcomes (customer value, quality, sustainable pace) because they’re harder to quantify. The metrics told us we were productive. The reality was we were burning people out while accumulating technical debt.
Here’s a story that crystallized this for me: two teams, identical velocity metrics, completely different business impact.
Team A deployed constantly, hit every sprint commitment, showed amazing DORA numbers. Team B was slower, sometimes missed commitments, had “worse” velocity on paper.
When we looked at actual customer data, Team B’s features drove 3x higher engagement and 2x better retention. Team A was shipping fast. Team B was shipping value.
The metrics couldn’t tell them apart because we were measuring the wrong things.
The shift happening now - from DORA to DevEx - is fundamentally about this trust problem. Engineers don’t trust metrics that measure them like surveillance systems. They will trust metrics that help them identify and remove blockers.
DevEx framework focuses on feedback loops, cognitive load, and flow state - things developers actually care about and can act on. That’s not coincidence. When metrics serve the people being measured instead of the people doing the measuring, trust follows.
But here’s the uncomfortable truth: building trustworthy metrics requires humility from leadership. We have to admit that our current dashboards might be measuring the wrong things. We have to involve engineers in deciding what to track. We have to be willing to act on what metrics tell us, even when it’s inconvenient.
Some practical approaches I’ve found helpful:
Pair engineering metrics with product metrics. Don’t just track deployment frequency - track deployment frequency AND feature adoption. Don’t just track PR velocity - track PR velocity AND customer satisfaction with new features. This connects engineering effectiveness to business outcomes in ways both functions can align around.
Joint retrospectives. Engineering and product review both code metrics and customer impact together. This builds shared understanding of the full picture.
Guardrail metrics. Use customer NPS and satisfaction as guardrails for engineering velocity. If velocity is up but satisfaction is flat or down, that’s a red flag.
The business reality: engineering effectiveness only matters if it translates to customer value and business growth. The happiest engineering team in the world doesn’t matter if we’re building the wrong things or shipping low-quality features.
But the causation is important: good developer experience → quality engineering → valuable products → business success. You need the whole chain, not just one link.
When I’m in planning sessions, I push for metrics that answer: Are we building the right things? Are we building them well? Are customers benefiting? Are we sustainable?
The AI metrics paradox makes this urgent. If we’re shipping 40% more code but creating 65% more bugs, net customer impact is negative. That’s not productivity from a product perspective - that’s technical debt creating customer debt.
Here’s the framing that works with executives: “Engineering productivity isn’t about how much code we write. It’s about how much value we create per dollar spent on engineering. If we’re shipping more but fixing more bugs and losing customers, our true productivity is down.”
The challenge for our industry: we need shared frameworks that connect engineering health to business health in ways both functions trust.
Questions for the community:
How are you building metrics that engineers actually find valuable vs metrics that exist for management reporting?
How do you connect developer experience metrics to business outcomes in ways that convince non-technical leadership?
What does success look like when engineering teams trust and use their metrics instead of gaming or ignoring them?
We can’t keep measuring engineering with systems engineers don’t trust. The measurement crisis is ultimately a trust crisis, and trust requires building metrics collaboratively with the people being measured.