The same metrics that make developers distrust a dashboard drove a 30 to 70% cycle-time improvement for one of our clients. Same DORA metrics. Same granular SDLC signals. The opposite outcome from what most engineering orgs experience when leadership rolls out a metrics program. The difference wasn’t the dashboard. It was one design choice about who sets the goals and who presents the numbers.
The client was a large healthcare company with about 100 developers and data engineers. They came to us while using a well-known engineering intelligence tool, the kind that promises visibility into delivery performance and instead delivers surveillance fatigue. Developers had already learned to distrust metrics before we walked in the door. That’s the starting point worth sitting with, because it means what happened next wasn’t a matter of introducing metrics carefully to a blank slate. It was rebuilding trust in a category of tooling that had already burned the trust of a department.
Scoreboard Anti-Pattern
We warned against treating DORA metrics as a scoreboard in our take on Accelerate and the research behind DORA metrics. Goodhart’s Law is blunt about what happens when a measure becomes a target: it stops being a good measure. We’ve seen this same pattern when leaders tie metrics directly to compensation, one manifestation we examined in Meaningful Change. Teams start optimizing for the number instead of the outcome, and curiosity gets replaced by defensiveness.
This case study isn’t a reversal of that warning. Here’s what operationalizing a DORA-focused program looked like in practice.
Engineering intelligence tools can create a very different experience for developers than leadership intends. Think DX, Jellyfish, and the products built in their image. These are strong tools, but when the rollout centers on dashboards and targets, developers can quickly experience them as something being done to them.
A manager starts asking why PR counts are down, and the team learns that the metric is what matters. Developers respond predictably. They submit more PRs, make smaller and more frequent commits that do not reflect real progress, and close tickets early only to create duplicates and continue working. The metric improves, but the underlying work does not.
What made this work was not the choice of metrics or the dashboard behind them. It was the ownership model around the data. Teams set their own improvement goals, a peer rather than a manager brought the numbers into the conversation, the framing stayed explicitly blameless, and gaming was treated as a signal that the system needed adjustment, not as misconduct to punish. The metrics became a tool for teams to investigate their own delivery problems, rather than a scoreboard leadership used to judge them. That design is what changed the outcome.
A Team That Had Already Learned to Distrust Its Own Dashboard
Before we started, this client had already lived through the default failure mode. Metrics had functioned as verdicts, on individuals, on teams, on whether someone was “doing enough.” The predictable result followed: people got defensive, numbers got gamed, and the underlying delivery problems the metrics were supposed to surface stayed exactly where they were.
That history left us with a real question, not a hypothetical one. Can the same category of metrics, DORA plus the granular SDLC signals that make DORA actionable, work here without repeating what had already failed? We couldn’t assume trust. We had to build it back, deliberately, with a team that had good reason to be skeptical of anyone showing up with another dashboard.
The Transformation
The Boring Part: Data You Already Have
The data layer is the least interesting part of this story, and it should be. Nightly pipelines pull from the tools the team already uses daily, Jira, GitHub, DataDog, etc, and aggregate that data into a warehouse. No extra step for developers to remember. Developers keep working in the systems they already use. The measurement happens downstream.
On top of the standard DORA metrics (lead time, deployment frequency, change failure rate, and mean time to restore), we track granular signals that give those metrics context: ticket-type mix, PR size, how long human review takes, code coverage, smoke test results, cyclomatic complexity, where and when bugs actually surface in the SDLC, and vulnerability count, age, and turnaround time.
We built several dashboards on top of the data, but they were commodity infrastructure: necessary, unremarkable, and not where the value came from. Any tool that made it easy to trace a metric back to the underlying data would have worked.
Who Sets the Goal and Who Reads the Numbers
This is the part that actually explains the 30 to 70% reductions in developer cycle time.
Each team designates a delegate who sets one or two monthly targets, tied to metrics the team picked for itself. The targets are calibrated to push the team to make a meaningful change to their tooling or process. The team has to come up with their own solutions. Nobody hands them a universal fix. A team that is focusing on cutting lead time has to figure out for itself whether the bottleneck is code review, environment setup, or ticket sizing, and then go fix that specific thing.
The delegate role rotates every two months, and it’s always a peer, never someone with authority over the team. That delegate runs a roughly five-minute daily presentation we call a “weather report”: a quick, data-driven mini-retrospective on yesterday’s numbers and the adjustments needed for today. Five minutes is enough to spot a trend and decide what to try next, without letting the conversation drift into a status report.
Sessions open with Agile’s Prime Directive, the reminder that everyone did the best job they could with what they knew at the time. Targets are never tied to compensation or individual performance reviews. The data is a prompt for a conversation among peers, never a standalone verdict handed down without context.
The limits here are real. Rotation and peer presentation are a real, load-bearing mitigation against the surveillance dynamic that sinks most of these programs. They are not a full solve. A team can still feel watched by a dashboard even when a peer is the one reading it out loud. What this design does is remove the most common trigger for that feeling: a manager, with authority over someone’s review and raise, standing in front of their numbers.
When a Team Started Gaming Its Own Goal
Goodhart’s Law doesn’t go away because you designed carefully around it. It shows up anyway, and the honest move is to expect it rather than pretend a well-intentioned program is immune.
One pilot team saw its lead-time number improve fast, almost too fast, right around day five of the ticket cycle. The team had started splitting tickets specifically to stay under its own lead-time goal. The headline metric showed strong improvement. The delegate and facilitators noticed the drop was precipitous enough to be suspicious, dug into the raw ticket-level detail, and found the pattern within days.
The correction wasn’t punitive. Nobody got called out, and the ownership model didn’t get pulled back or replaced with tighter management oversight. It was a reminder, delivered in the same blameless way as every other conversation in this program: the point is making data-driven decisions about where to focus SDLC energy, not making the number look good.
This is worth sitting with, because it’s the actual proof case for the design, not an embarrassing footnote we’re including for balance. A metrics program that can’t survive a gaming attempt without turning into a blowup was never blameless to begin with. This one absorbed it, corrected course, and kept going.
What Three Months of Ownership Bought Them
Here’s the mechanism before the number: consistent visibility into delivery data, combined with goals the teams set for themselves, was enough to move outcomes before we’d touched anything about their architecture, their tooling, or their process at a deeper level. The ownership design alone did work that usually requires a much heavier intervention.
Across the three pilot teams, cycle time dropped 30% at the low end and 70% at the high end, within the first three months.
Remember where this team started: skeptical, and for good reason, given their prior experience with a surveillance-flavored tool. That skepticism is exactly what makes the shift so telling. What moved the needle was the ownership design, not novelty, and not a short-lived Hawthorne effect from people knowing they were being watched. A team that had already learned to distrust a dashboard doesn’t improve by 30% to 70% just because a new one showed up.
There’s an organizational benefit here too, beyond the pilot numbers. A structured program like this gives systemic delivery health a standing claim on the team’s attention. Without it, that attention defaults to whatever feature is due this sprint, and tech debt gets prioritized ad-hoc, if at all. The daily weather report and the monthly target(s) give delivery health a seat at the table it wouldn’t otherwise have.
Key Takeaway
Same DORA metrics, same granular SDLC signals most engineering intelligence tools track, and an outcome that runs opposite to what most of the industry gets from this category of tooling. The difference was never the dashboard or the tool. It was the ownership design underneath it:
- The team sets its own goals, so it owns the path to hitting them.
- A rotating peer, not a manager, presents the data.
- The framing stays explicitly blameless, every session, every time.
- Gaming gets treated as an expected, correctable event, not a punishable violation.
If you’re evaluating a metrics or dashboard initiative for your own org, design for team ownership from day one. Trust is hard to retrofit into a program that started life as a leadership-facing dashboard.
If you want to talk through what this could look like for your team, get in touch.