DORA Metrics Show 4-5× Performance Gap, Yet Most Teams Don't Measure—Cultural Barrier or Leadership Gap?

alice_security · March 22, 2026, 3:51pm

Three months ago, I walked into an engineering all-hands and announced we’d start tracking DORA metrics. The silence was deafening. Not excitement—resistance. One senior engineer asked, “Are you building a dashboard to fire people?”

That question haunts me because it reveals the core paradox we face: DORA metrics show a 4-5× performance gap between top and bottom teams—elite teams ship software in under 22.5 days while bottom-quartile teams take over 62 days. Yet 67% of companies don’t measure these metrics at all.

If the framework works, why don’t we use it?

The Competing Theories

I’ve heard two explanations for this adoption gap:

Theory 1: Leadership doesn’t know what to measure

Most executives ask for “velocity” or “lines of code” (nearly meaningless)
DORA isn’t taught in business schools or most engineering programs
The framework exists but isn’t part of standard leadership playbook

Theory 2: Engineers resist being measured

Fear metrics will be misused for individual performance reviews
Concern about gaming (when a measure becomes a target, it ceases to be a good measure)
Worry that metrics oversimplify complex work

My Take: It’s Both, But Weighted Toward Leadership

After implementing DORA at three companies, I believe the bigger barrier is leadership education and commitment. Here’s why:

When I introduce metrics poorly—framing them as “accountability” or “visibility into team performance”—engineers rightfully resist. They’ve seen metrics weaponized. They know that once data exists, it can be misused regardless of initial promises.

But when I introduce them right—with explicit commitments that metrics will never be used for individual evaluation, that teams will own their improvement plans, that we’re measuring systems not people—the resistance drops significantly.

The problem is most leaders don’t understand this framing. They want simple answers: “Which team is slowest? Who’s underperforming?” DORA metrics can’t answer those questions (or shouldn’t be used that way), but leaders expect them to.

The AI Complication

Here’s where it gets more urgent: our research shows a 7.2% reduction in delivery stability when teams increase AI adoption, despite code quality improvements. AI tools like Copilot help developers generate better code faster, but delivery performance often degrades.

This suggests the bottleneck was never code creation—it was always validation, review, testing, deployment. And now that AI removes the coding constraint, the other bottlenecks become obvious.

We need better measurement, not less. Without DORA metrics, teams think “AI made us faster” when reality is more complex. Metrics reveal that faster code generation can overwhelm review capacity and destabilize deployments.

The Path Forward

The 67% non-adoption stat doesn’t surprise me, but it does frustrate me. The solution isn’t more sophisticated tools or better dashboards. It’s:

Leadership education: Teach executives what DORA means and doesn’t mean
Trust building: Proactive commitments about how data will and won’t be used
Team ownership: Let engineers define improvement plans based on their data
System focus: Measure systems and processes, never individuals

At my current company, we’re four months into DORA measurement. Our deployment frequency improved 40%, lead time dropped 28%, and—most importantly—engineers now ask for more metrics because they see the value. It took explicit trust-building and leadership discipline, but it worked.

What’s your experience? Have you implemented DORA successfully? What barriers have you hit—leadership, engineering, or both? For those in the 67% not measuring: what would it take to start?

alex_dev · March 22, 2026, 3:51pm

Michelle, this hits close to home. I went through DORA implementation twice at my current company—first attempt failed spectacularly, second succeeded. The difference? How we introduced it.

First Attempt: The Wrong Frame

Year one, leadership positioned DORA as “accountability metrics.” The message from our VP: “We need visibility into team performance to ensure everyone is pulling their weight.”

Predictably, engineers revolted. Senior developers started gaming deployment frequency by breaking features into tiny, meaningless deploys. Code review times ballooned because people were terrified their metrics would look bad. We abandoned the initiative after 3 months.

Second Attempt: The Right Frame

Year two, new approach. I worked with HR and our CTO to draft a “Metrics Charter” before turning anything on:

Team-level only: No individual tracking, ever
Team ownership: Each team defines their own improvement goals
No performance reviews: Metrics cannot be used in evaluations, promotions, or layoff decisions
Transparency: Everyone sees the same dashboards leadership sees

We had engineering leaders sign off publicly. Then we turned on DORA tracking.

The Results

Within one quarter:

Average lead time dropped from 9 days to 6 days
Deployment frequency increased 2.5×
Incident recovery time halved
Most importantly: Engineers started asking for more metrics

That last point is critical. When developers see metrics helping them identify problems (long review times, flaky tests, deployment bottlenecks), they want more visibility, not less.

The Trust Factor

To your question about whether it’s leadership or engineers—I think it’s how metrics are introduced that determines which group resists.

When executives frame measurement as “finding underperformers,” engineers resist (and should).

When engineering leaders frame measurement as “improving our systems,” leadership resists because they wanted individual accountability.

The companies in the 67% non-adoption group probably have leadership that wants accountability data and engineers who (correctly) don’t trust them with it.

My Biggest Question

Here’s what I still struggle with: Once the data exists, how do you prevent it from being misused?

Our charter says metrics won’t be used for performance reviews. But when a VP asks me privately, “Why is Team X slower than Team Y?” I have to answer. And now I have data that makes that comparison easy.

How do you maintain the trust you built when executives start asking uncomfortable questions backed by the data you created?

maya_builds · March 22, 2026, 3:52pm

This whole thread is fascinating from a design perspective because we face the exact same resistance with UX metrics—but I think the root cause is different than you’re discussing.

The Uncomfortable Truth

I think measurement reveals uncomfortable truths that people would rather not quantify.

When I was running my startup (RIP 2024), we tracked design iteration speed, user testing cadence, design debt—all the “DORA for design” metrics. And you know what we learned? Our design process wasn’t the problem. We were just building the wrong product.

But admitting “we don’t know what to build” is way harder than saying “our process could be faster.” Metrics let you focus on process improvement instead of fundamental strategic questions.

The Gaming Problem Is Real

Luis’s story about engineers gaming deployment frequency by making tiny, meaningless deploys? We did the exact same thing with design iterations.

Our metrics looked great:

15 design iterations per feature ✓
User testing every sprint ✓
95% of designs implemented as specified ✓

Meanwhile, our NPS was 23 and churn was 12% monthly. The design metrics were perfect while the product was failing.

Bad metrics are worse than no metrics because they give you false confidence.

The AI Angle That Scares Me

Michelle, your point about the 7.2% reduction in delivery stability despite better code quality is exactly what I’m seeing in design tools.

I can generate 10 Figma mockups with AI in the time it used to take me to create 2. But:

Stakeholder review capacity didn’t increase
User testing capacity didn’t increase
Engineering capacity to implement didn’t increase

So now I have a backlog of “AI-generated designs” that nobody has time to evaluate properly. We’re optimizing for quantity over craft, and the metrics would show “design productivity up 5×” while the actual output quality is questionable.

My Fear

What if we’re measuring because we can, not because we should?

Engineers already know when code review is slow. Design teams already know when iteration cycles are too long. Product teams already know when deployment takes forever.

Do DORA metrics tell you anything you don’t already feel? Or do they just quantify what’s obvious to anyone on the team?

I’m genuinely asking because my startup experience made me skeptical of measurement theater. We tracked everything and still built the wrong thing.

alex_technical · March 22, 2026, 3:53pm

From the product side, I have to admit: leadership absolutely doesn’t know what to measure, and I include myself in that criticism.

What I Asked For (Wrong)

When I joined my current company 18 months ago, I asked engineering: “Can you give me team velocity metrics so I can forecast roadmap delivery?”

They (correctly) pushed back that velocity isn’t comparable across teams and doesn’t predict delivery. I got frustrated because I needed SOME way to answer the board’s questions about “why isn’t engineering shipping faster?”

I had never heard of DORA metrics. They weren’t taught at Wharton. No product leader I knew used them. I learned about the framework from our engineering director, not from other business leaders.

The Knowledge Gap

Here’s the uncomfortable truth: Most executives ask for meaningless metrics because we don’t know better alternatives exist.

Common questions I hear from other VPs:

“What’s your engineering team’s velocity?” (meaningless without context)
“How many story points do they complete per sprint?” (gaming paradise)
“What’s their code output?” (literally measures the wrong thing)

DORA provides the answers we actually need:

How fast do changes go from commit to production? (lead time)
How often do we deploy? (deployment frequency)
What percentage of deployments cause incidents? (change failure rate)
How fast do we recover from incidents? (recovery time)

But I didn’t know to ask these questions until engineering taught me.

The Business Case Problem

Even when I learned about DORA, I struggled to justify engineering investment in measurement infrastructure. The conversation with our CFO:

Me: “We need to invest in DORA metrics tracking.”
CFO: “What’s the ROI?”
Me: “It will help us understand engineering performance.”
CFO: “How much faster will we ship?”
Me: “…unclear?”

How do you justify measuring engineering when the value of measurement isn’t immediately obvious to finance/leadership?

The Comprehension Gap

Even when teams DO measure DORA, leadership often doesn’t understand what the numbers mean.

“Is a 48-hour cycle time good or bad?”
“Should we worry about 5% change failure rate?”
“How does our 8 deploys/week compare to industry benchmarks?”

Most executives can’t answer these questions. We see numbers on a dashboard but lack the context to know if they represent success or failure.

My Challenge to Engineering Leaders

If 67% of companies don’t measure DORA, part of the blame is on engineering for not educating business leadership about what matters.

Michelle, your framework is great—but how do you teach non-technical executives what DORA means in business terms? How do you bridge the “this is a good lead time” gap?

Because right now, there’s a knowledge barrier where:

Engineers know what to measure but don’t have buy-in
Leaders want to measure but don’t know what

We need to meet in the middle.

product_david · March 22, 2026, 3:53pm

Michelle, this entire thread validates what I’ve learned implementing DORA at three different companies: it’s a system problem, not a people problem. Both leadership education AND engineer trust must be addressed—you can’t solve one without the other.

The Pattern I’ve Seen

Company 1 (Series A startup): Leadership wanted metrics, engineers trusted them

Implementation took 3 weeks
Metrics drove immediate improvements
Team culture was already transparent

Company 2 (mid-size tech): Leadership wanted metrics, engineers didn’t trust them

Implementation stalled for 9 months
When finally launched, engineers gamed the data
Metrics abandoned after one quarter

Company 3 (current, EdTech scale-up): Leadership didn’t know what to measure, engineers were ambivalent

Took 4 months to educate executives on what DORA means
Then 6 weeks to implement
Now running successfully for 8 months

My Implementation Framework

I don’t start with tools or dashboards. I start with alignment:

Phase 1: Leadership Education (2-4 weeks)

What DORA metrics actually measure (and don’t measure)
Why “velocity” and “story points” are misleading
Industry benchmarks and realistic targets
Commitment: metrics will never be used for individual performance evaluation

Phase 2: Trust Building (2-3 weeks)

Engineering-led design of dashboards
Team-level metrics only (explicitly no individual tracking)
Self-service access (everyone sees same data)
Written charter: how metrics will and won’t be used

Phase 3: Pilot (1 quarter)

One team, manual tracking if needed
Weekly retrospectives on what data is useful
Iterate on definitions and collection methods

Phase 4: Scale (ongoing)

Expand to additional teams quarterly
Teams define their own improvement goals
Leadership reviews system health, not team performance

The 67% Doesn’t Surprise Me

Luis asked how you prevent misuse once data exists—that’s the critical question. My answer: organizational maturity.

Some companies cannot responsibly use metrics because their culture is toxic. In those environments:

Any data gets weaponized
Trust doesn’t exist
Measurement will fail

But high-performing teams in my experience WANT metrics. When I joined my current company, the senior engineers asked ME: “When can we get DORA tracking? We want to know if our new CI/CD pipeline is actually helping.”

Struggling teams resist measurement because it quantifies their struggle. That’s not a measurement problem—it’s a psychological safety problem.

Responding to David’s Challenge

David, you asked how to teach executives what DORA means in business terms. Here’s my translation guide:

DORA Metric → Business Impact

Lead time → Time-to-market for features
Deployment frequency → Ability to respond to market/customer needs
Change failure rate → Cost of quality issues and customer trust
Recovery time → Revenue impact of downtime

Frame it as: “DORA tells us how fast we can respond to business opportunities and how reliably we execute.”

To Michelle’s Original Question

Is the 67% non-adoption a leadership gap or engineering resistance?

Both, sequentially:

Leadership doesn’t know what to measure (education gap)
Leadership asks for wrong metrics (velocity, story points)
Engineers resist because bad metrics are worse than none (trust gap)
Leadership gets frustrated that “engineers don’t want to be measured”
Stalemate

The way out: Leadership learns DORA, commits to proper use, engineers gain trust, measurement succeeds.

But it requires leadership willing to learn and engineers willing to give them a chance. The 67% are stuck because one or both of those conditions aren’t met.

My question back to you: How do you handle when metrics show a team is genuinely underperforming? Not “needs support” but actually has structural problems or wrong people? At what point does measurement reveal hard personnel decisions, and how do you square that with “metrics won’t be used for evaluation”?