We Hit "Elite" on DORA Metrics But Product Is Still Late—What Are We Actually Optimizing For?

General
1

Last quarter, my team hit “elite” status on all four DORA metrics. We were deploying multiple times per day, our lead time for changes was under an hour, change failure rate was below 5%, and we could recover from incidents in minutes. The dashboard was beautiful. Leadership was thrilled.

Then the VP of Product walked into our retro and asked why we’d shipped only two of the eight planned features, and why the features we did ship weren’t moving customer metrics.

That hit differently.

The Paradox We’re Not Talking About

Here’s the uncomfortable truth: we optimized our deployment pipeline to perfection while the business outcomes lagged behind. We became incredibly efficient at shipping code—but apparently not at shipping value.

The data backs this up:

  • Research shows that 66% of developers don’t trust the metrics used to evaluate their work
  • Studies reveal that 40% of engineering time goes toward work that doesn’t actually matter
  • Traditional DORA metrics miss the 47% of developer time spent in communication and coordination

The Questions That Keep Me Up

  1. Are we measuring the right things? DORA tells us we’re fast. But fast at what? Deploying features nobody asked for? Refactoring code that was already fine? Building technical monuments?

  2. Where’s the business outcome connection? Our deployment frequency is elite. But did that make customers happier? Did revenue grow? Did churn decrease? I honestly don’t know how to connect these dots.

  3. What about the work DORA doesn’t see? Customer conversations. Architecture decisions. Mentoring junior engineers. Preventing disasters that never happened. How do we measure the value of work that doesn’t result in a deployment?

What I’m Seeing in 2026

The industry is shifting. Gartner talks about “outcome-focused metrics.” Google reports that 25% of their code is AI-generated but velocity only improved 10%—suggesting that code volume and business value aren’t the same thing. Companies are starting to connect engineering metrics to revenue, customer satisfaction, and strategic goals.

But I’m struggling to figure out what this looks like in practice.

Where I Need Your Perspective

For those of you who’ve navigated this:

  • How do you balance engineering excellence metrics with business outcome metrics?
  • What does “value delivery” actually mean for your team, and how do you measure it?
  • When DORA metrics and business goals conflict, which one wins?
  • Are there frameworks or approaches that have worked for you?

I’m especially interested in hearing from folks in product, design, and other functions. Maybe the answer isn’t better engineering metrics—maybe it’s better cross-functional alignment around what actually matters.

What are you optimizing for?

2

Luis, this resonates deeply. We faced almost the exact same situation during our cloud migration last year—perfect DORA metrics, but we were six months behind on strategic initiatives that actually mattered to the business.

The fundamental problem: DORA measures pipeline efficiency, not value creation. It tells you how well your deployment machinery works, not whether you’re building the right things.

The Output vs Outcome Trap

Here’s what I learned the hard way: deploying fast doesn’t equal delivering value. We were measuring outputs (deployments, lead times, recovery speed) when what the business cared about was outcomes (revenue growth, customer retention, market expansion).

Think of it this way: DORA metrics are like measuring how fast your assembly line runs. That’s important—but only if you’re building products people actually want to buy.

What Actually Works

After that wake-up call, we implemented a dual-metric framework:

Engineering Excellence (DORA)

  • Still track deployment frequency, lead time, CFR, MTTR
  • These measure our technical capability and operational maturity

Business Impact (Outcome Metrics)

  • Revenue enabled by new capabilities
  • Customer satisfaction scores for specific features
  • Time-to-market for strategic initiatives
  • Cost reduction from infrastructure improvements

The critical insight: both matter, but outcome metrics are the north star. Engineering excellence is how we get there efficiently, not the destination itself.

The Hard Question

When these metrics conflict—and they will—you have to choose outcomes over outputs.

Example: We had a choice between refactoring our deployment pipeline (would improve our DORA scores) or building an integration that three enterprise customers were demanding (would improve revenue).

We chose the integration. Our deployment frequency actually dropped that quarter. But revenue grew, and we closed deals worth millions.

Was that the wrong decision because our DORA metrics suffered? Absolutely not.

Connecting Engineering Work to Business Value

This is where the real work happens. Every quarter, I sit down with product, sales, and finance leadership to map engineering work to business outcomes:

  • “This infrastructure investment will reduce our cloud costs by and enable us to serve Y more customers”
  • “This feature enables us to enter the enterprise market (TAM of )”
  • “This reliability improvement reduces churn risk for our top 10 customers”

It’s uncomfortable at first—engineers don’t like talking in CFO language. But it’s essential. If you can’t explain how your work creates business value, you’re probably optimizing the wrong things.

The real question isn’t “Are we hitting elite DORA metrics?” It’s “Are we enabling the business to win?”

3

Coming from the product side, I can tell you exactly what this looks like from our perspective: engineering teams shipping faster doesn’t help if we don’t have product-market fit clarity.

Last year we had a similar situation. Engineering was crushing it on DORA metrics—deploying multiple times per day, incredibly fast iteration cycles. But here’s what actually happened:

  • We shipped 40% more features than the previous year
  • Customer satisfaction scores were flat
  • Revenue growth was below target
  • Churn was creeping up

The Brutal Truth

Fast deployment of the wrong features is worse than slow delivery of the right ones.

Your engineering team might be operating at peak efficiency, but if product strategy isn’t clear, or if customer research is weak, or if we’re building based on HiPPO (Highest Paid Person’s Opinion) instead of validated demand—none of that deployment speed matters.

Where the Disconnect Happens

Here’s the product-engineering alignment gap that DORA metrics don’t reveal:

  1. Feature factory mindset - Measuring success by output (features shipped) rather than outcomes (customer problems solved)

  2. Lack of product success metrics - Engineering tracks deployment frequency, but we’re not measuring feature adoption, usage depth, or impact on key customer journeys

  3. Discovery vs delivery imbalance - Teams optimize for fast delivery but underfund discovery. We ship fast but ship the wrong things.

What Product Needs from Engineering

Honestly? I’d rather have:

  • Slower deployment cadence with better product-market fit validation
  • Longer lead times but features that actually move the needle on customer retention
  • Lower deployment frequency if it means we’re doing proper user research first

Michelle’s point about outcome metrics is spot-on. From a product perspective, the metrics that matter are:

Customer Outcomes:

  • Feature adoption rate (% of users who try new capability)
  • Usage depth (how integral it becomes to their workflow)
  • Customer satisfaction (NPS/CSAT for specific features)
  • Customer effort score (is this actually making their lives easier?)

Business Outcomes:

  • Conversion rate impact
  • Retention/churn impact
  • Revenue per customer
  • Market expansion (new segments we can serve)

The Framework That’s Helped Us

We now run a quarterly “alignment sprint” where product and engineering jointly define:

  1. What customer problem are we solving? (validated with research)
  2. What does success look like? (business and customer metrics)
  3. How will we measure impact? (instrumentation plan)
  4. What’s the smallest version that tests the hypothesis? (scope)

Only after we have clarity on #1-4 do we optimize for fast deployment.

The uncomfortable question I’d ask: Are your elite DORA metrics enabling you to learn faster and iterate based on customer feedback? Or are they just helping you build the wrong things more efficiently?

4

This thread is highlighting something I’ve been grappling with for the past year: DORA metrics completely miss the human and organizational factors that actually drive sustainable performance.

Let me share a story that crystallizes this.

When Elite Metrics Hide Organizational Dysfunction

Two years ago, I led a team that achieved elite DORA scores. From the outside, we looked like a high-performing engineering organization. Leadership loved us.

Behind the scenes? The team was miserable.

  • Engineers were burning out from the pressure to maintain deployment frequency
  • Code review became a bottleneck—people were cutting corners to hit metrics
  • Junior engineers felt like they couldn’t ask questions because it might slow down lead time
  • Attrition was 30% that year

We were optimizing for speed at the expense of sustainability, learning, and team health.

What DORA Doesn’t Measure

Research shows that DORA metrics miss 47% of the time developers spend on coordination, communication, and collaboration. These activities are essential to high-functioning teams, but they’re invisible to deployment-focused metrics.

What else is missing?

Developer Experience:

  • Flow state and deep work time
  • Cognitive load and context switching
  • Psychological safety to raise concerns
  • Mentoring and knowledge transfer
  • Time for learning and skill development

Team Health:

  • Morale and engagement
  • Retention and career growth
  • Cross-functional relationships
  • Trust and collaboration quality

Organizational Effectiveness:

  • Alignment on priorities
  • Decision-making speed and quality
  • Learning from mistakes
  • Adaptability to change

The DevEx Framework

We’ve since adopted a more holistic approach that combines DORA with the DevEx (Developer Experience) framework:

1. Feedback Loops - How quickly can developers validate their work?
2. Cognitive Load - How much mental overhead does our tooling/process create?
3. Flow State - Can developers get into sustained deep work?

These aren’t soft metrics—research shows they correlate directly with productivity and retention. But more importantly, they help us understand why we’re fast or slow, not just that we’re fast or slow.

The Retention Wake-Up Call

Here’s the metric that got our CFO’s attention: cost of attrition.

When we lost three senior engineers in one quarter, finance calculated the replacement cost:

  • 6-12 months to hire and onboard replacements
  • 3-6 months for new hires to reach full productivity
  • Knowledge loss and project delays
  • Total cost: over M for those three engineers

Suddenly, investing in developer experience wasn’t a “nice to have”—it was a financial imperative.

A Different Question

Luis, you asked what we’re optimizing for. I’d flip the question: What’s the long-term cost of optimizing purely for speed?

Michelle and David are right about connecting to business outcomes. But I’d add: elite engineering requires both technical excellence and team sustainability.

You can’t maintain elite DORA metrics if your best engineers are leaving, if junior engineers aren’t being mentored, or if the team is burned out.

The metrics that matter for sustainable performance:

  • DORA metrics (pipeline efficiency)
  • Business outcome metrics (value delivery)
  • Developer experience metrics (team health and sustainability)

All three. Not just one.

5

Coming from design, this conversation hits close to home—I lived through a version of this with my failed startup.

We optimized obsessively for shipping speed. We deployed multiple times a day. We had incredibly fast iteration cycles. From a technical standpoint, we were executing flawlessly.

The product failed anyway. Because we were shipping fast, but we weren’t shipping right.

The User Experience Blind Spot

Here’s what DORA metrics don’t tell you: Whether what you’re building actually improves users’ lives.

At my startup, we shipped 40+ features in our first year. Our deployment frequency was incredible. But here’s what we didn’t measure:

  • Did users actually discover these features?
  • Were the features intuitive or did they create confusion?
  • Did we introduce new friction while solving old problems?
  • Was the cumulative experience getting better or more bloated?

Turns out: we were adding complexity faster than we were adding value. Our NPS score dropped even as our feature count grew.

Technical Debt Shows Up in the User Experience

This is where Keisha’s point about sustainability connects to users: technical debt accumulated from “move fast” cultures doesn’t just burden engineers—it degrades the user experience.

Quick example from our design system work:

A team optimized for deployment speed by copying/pasting component code instead of using our shared library. Fast? Absolutely. But three months later:

  • Inconsistent button styles across 8 different screens
  • Accessibility regressions (the shared component had proper ARIA labels, the copies didn’t)
  • User confusion from inconsistent interaction patterns
  • Massive rework cost to fix it properly

The DORA metrics looked great during those three months. The user experience degraded silently.

Design Quality Can’t Be Rushed

One of the hardest lessons from my startup: good design requires time that deployment frequency metrics actively discourage.

  • User research takes time
  • Iterating on interaction design takes time
  • Accessibility testing takes time
  • Waiting to see how users actually behave with v1 before building v2 takes time

If your optimization framework is “deploy as fast as possible,” you create pressure to skip these steps. And then you ship features that technically work but aren’t actually usable.

The Metric That Actually Matters

From a design perspective, the only metric that truly matters: Are users’ lives actually better after we ship this?

Not:

  • Did we deploy it quickly?
  • Did it pass our technical tests?
  • Did it match the spec?

But:

  • Can users accomplish their goals more easily?
  • Is the experience more delightful or less frustrating?
  • Did we solve a real problem or create new ones?

What I Wish Engineering Teams Would Measure

If I could add metrics to complement DORA:

Discovery Metrics:

  • Time spent in user research before building
  • Number of prototypes tested with actual users
  • User feedback incorporated pre-launch

Experience Metrics:

  • Feature adoption rate (do users even find it?)
  • Task success rate (can users complete their goal?)
  • Time-to-value (how quickly do users see benefit?)
  • Accessibility compliance (WCAG standards)

Quality Metrics:

  • Design system compliance (consistency)
  • User-reported bugs vs engineering-caught bugs
  • Customer support tickets per feature

David’s right that shipping the wrong feature fast is worse than shipping slowly. From design: shipping a confusing or broken experience fast is worse than shipping nothing at all.

At least with nothing, you haven’t actively made users’ lives worse.

This isn’t about slowing down for the sake of it—it’s about measuring the right outcomes. Fast deployment is valuable only if you’re deploying things that make users’ lives meaningfully better.