Your Dashboards Track DORA Metrics—But Gartner Says Creativity and Innovation Will Replace Velocity as Success Metrics in 2026. What Happens When the Industry Stops Measuring What You're Optimizing For?

General
1

Your engineering dashboards track deployment frequency, lead time, change failure rate, and MTTR. You’ve spent two years optimizing for DORA metrics. Your team ships faster than ever—70 deploys per week, lead time under 4 hours.

But here’s the problem: the industry is moving on.

The Metrics Shift Nobody’s Ready For

Waydev’s 2026 analysis identifies the blind spot: we’re measuring more code and fewer releases. AI coding assistants dramatically boost individual output—98% more pull requests merged—but organizational delivery metrics stay flat.

Gartner and other analyst firms are signaling a fundamental shift: creativity and innovation will replace velocity and deployment frequency as success metrics in 2026.

The reason? AI commoditizes productivity. When GitHub Copilot, Cursor, and Claude Code can generate boilerplate, test scaffolding, and configuration changes in seconds, deployment frequency becomes a vanity metric. It measures AI output, not engineering value.

What Actually Matters Now

Research shows DORA alone isn’t sufficient. Elite teams in 2026 are tracking:

1. Code Durability — What percentage of code survives 14 or 30 days without substantial modification? This is the quality signal that matters when AI increases code volume dramatically.

2. Main Branch Success Rate — Industry benchmark is 90%, current average is 70.8%. This is the clearest signal of whether delivery systems are keeping pace with AI-generated volume.

3. Creativity Ratio — Time spent on creative problem-solving vs. AI-generated code review and correction. Are developers spending time on high-value work or babysitting AI output?

4. Business Impact Connection — Does the AI-assisted feature actually move a product metric? Engineering output that doesn’t connect to business outcomes is just technical debt in disguise.

The Uncomfortable Truth

Your DORA metrics are lying to you. They still measure real things, but AI-assisted workflows can dramatically increase deployment frequency without a corresponding increase in meaningful output.

Teams that rely solely on DORA in 2026 are measuring the wrong things—optimizing for an obsolete game while the industry redefines success.

The Question For Leadership

What happens when the metrics you’ve spent two years optimizing for become irrelevant?

I’m not saying DORA is worthless. Deployment frequency and lead time still matter. But they’re input metrics in an AI-assisted world. The output metrics—creativity, innovation, business impact—are much harder to measure.

How do you measure “creativity”? How do you track “innovation” without it becoming a subjective popularity contest? How do you connect engineering work to business outcomes when the causality is complex and delayed?

These are the questions I’m wrestling with as we redesign our engineering metrics framework for 2026. I’d love to hear:

  • What metrics are you tracking beyond DORA?
  • How are you measuring the impact of AI coding tools on your team?
  • Have you found a way to quantify “creativity” or “innovation” that actually works?
  • What happens to teams that keep optimizing for velocity when the industry moves on?

The shift is happening whether we’re ready or not. The question is whether we adapt our measurement systems before or after we realize we’ve been optimizing for the wrong outcomes.

2

This hits close to home. We just finished a 6-month initiative to improve our DORA metrics, and I’m starting to wonder if we optimized for the wrong outcomes.

Your point about code durability is particularly sharp. We’ve seen deployment frequency increase 40% since adopting AI coding tools, but our MTTR actually went up 15%. That shouldn’t be happening if we’re shipping better code faster.

What we’re discovering: AI is great at generating code that looks clean and passes initial review. But it introduces subtle bugs that don’t surface until production—edge cases the AI didn’t consider, assumptions it made about system behavior, integration points it didn’t understand.

The Metric I Wish I Had: AI Code Share

One thing I’m experimenting with: tracking what percentage of code is AI-generated vs. human-authored. Not to limit AI use, but to understand the correlation with other metrics.

Early data from our team:

  • PRs with >70% AI-generated code: 2.3x higher revert rate
  • PRs with 30-50% AI-generated code: 1.1x higher revert rate
  • PRs with <30% AI-generated code: baseline

This suggests there’s a sweet spot where AI augments human thinking rather than replacing it. But we wouldn’t see this pattern if we only tracked DORA metrics.

The Measurement Challenge

Your question about measuring “creativity” is the right one to ask, but I don’t have a good answer yet. The closest proxy I’ve found is tracking time allocation:

  • Time spent on architectural design discussions
  • Time spent reviewing AI-generated code
  • Time spent debugging AI-introduced bugs
  • Time spent on novel problem-solving

If the ratio shifts heavily toward review and debugging, that’s a signal that AI is creating busywork rather than enabling creativity.

But this feels crude. I’d love to hear if others have found better approaches.

What Worries Me

Teams that keep optimizing for velocity metrics will create a false sense of productivity. Leadership sees 70 deploys per week and thinks “we’re crushing it.” But if 40 of those deploys are fixing issues introduced by the other 30, you’re not actually moving forward.

The lag time between vanity metrics and realized failure could be 6-12 months. That’s enough time to make critical business decisions based on misleading data.

3

Michelle, this is the conversation engineering leadership needs to be having in 2026. The metrics shift is real, and most organizations are completely unprepared for it.

I want to push back on one thing though: I don’t think the industry is moving on from DORA—I think we never actually understood what DORA was measuring in the first place.

DORA metrics were designed to measure organizational capability, not individual productivity. The 2024 DORA report introduced seven AI adoption practices precisely because they recognized AI changes how teams achieve high performance, not what high performance looks like.

The problem isn’t DORA. The problem is that we treated deployment frequency as a goal instead of a signal.

What We’re Doing Differently

At our org, we’re implementing a two-layer metrics framework:

Layer 1: Capability Metrics (DORA + Reliability)

  • These measure whether our engineering system is healthy
  • Deployment frequency, lead time, MTTR, change failure rate
  • Plus: main branch success rate (as you mentioned—critical gap)

Layer 2: Effectiveness Metrics (SPACE/DX Core 4)

  • Developer satisfaction and well-being
  • Speed of individual work
  • Quality of output (code durability, business impact)
  • Communication and collaboration health
  • Efficiency without burnout

The key insight: Layer 1 tells you if the system works. Layer 2 tells you if humans are thriving within it.

Both matter. AI changes Layer 2 dramatically but doesn’t eliminate the need for Layer 1.

The Creativity Problem

Your question about measuring creativity is the hardest one. Here’s my current thinking:

You can’t measure creativity directly, but you can measure the conditions that enable it:

  1. Uninterrupted time blocks — Are engineers getting 4+ hour chunks for deep work, or are they context-switching between AI review tasks?

  2. Experimentation rate — How often do engineers prototype solutions that don’t ship? A healthy innovation culture has a “failure” rate.

  3. Architecture decision records — Are teams documenting novel technical decisions, or just implementing the AI’s first suggestion?

  4. Cross-team knowledge sharing — Innovation happens at the boundaries. Are teams learning from each other, or siloed in AI-assisted velocity loops?

This isn’t perfect, but it’s directional. If these signals are declining while deployment frequency increases, that’s a red flag.

What Keeps Me Up At Night

The shift from velocity to creativity as a success metric has massive organizational implications that most companies haven’t thought through:

Hiring: If creativity matters more than velocity, do we hire differently? What does a “creative engineer” interview look like?

Promotion: If innovation matters more than output, how do we design promotion criteria? The IC who ships 10 AI-assisted features isn’t necessarily more valuable than the architect who prevents 3 bad architectural decisions.

Compensation: Do we pay for impact or activity? If AI makes activity cheap, the compensation model breaks.

These are questions leadership teams need to answer before the metrics shift, not after.

I’m curious: Has anyone redesigned their engineering ladder or compensation structure to account for this shift? That feels like the next frontier.

4

As a product leader, I have a different take: the metrics shift isn’t about engineering—it’s about whether engineering work connects to customer outcomes.

Engineers have been optimizing deployment frequency and lead time. Product teams have been shipping features. But neither matters if customers don’t care.

The Disconnect I See

I work with engineering leaders who are proud of their DORA metrics. “We ship 50 deploys per week!” Great. But when I ask:

  • Which of those deploys moved a product metric?
  • Which features drove retention or revenue?
  • Which experiments validated or invalidated a hypothesis?

…I often get blank stares.

There’s a fundamental measurement gap between engineering velocity and product impact. AI makes this gap worse, not better.

Here’s what I mean:

Before AI:

  • Engineering ships 20 features per quarter
  • Product can track which 5-6 actually moved metrics
  • Clear signal-to-noise ratio

After AI:

  • Engineering ships 50 features per quarter
  • Product still only has bandwidth to track 5-6 experiments properly
  • Signal drowns in noise

More output doesn’t equal more impact. It just makes it harder to figure out what’s working.

The Metric That Actually Matters

From a product perspective, the metric I care about is feature validation rate:

  • What percentage of shipped features achieve their success criteria?
  • How long does it take to determine if a feature succeeded or failed?
  • What’s the ratio of validated winners to validated losers to “we don’t know”?

If engineering optimizes for velocity but product can’t validate outcomes fast enough, you end up with a backlog of shipped code that nobody knows if it was worth building.

This is the real crisis of 2026: engineering’s measurement systems (DORA) and product’s measurement systems (experimentation, retention, revenue) are diverging instead of converging.

What We Changed

We implemented a “feature lifecycle dashboard” that connects engineering and product metrics:

Stage 1: Build

  • Lead time from spec to prod (engineering metric)

Stage 2: Launch

  • Time to first user interaction (product metric)
  • Adoption curve shape

Stage 3: Validate

  • Days to statistical significance on success metric
  • Did it hit success criteria? (yes/no/inconclusive)

Stage 4: Learn

  • What did we learn that informs the roadmap?
  • What technical debt did we incur?

The controversial part: we track “inconclusive” as a failure. If you ship a feature but can’t measure its impact, that’s as bad as shipping a feature that failed. It means you built without a clear hypothesis.

This forces product and engineering to align before the work starts. No more “we’ll figure out how to measure it later.”

The Question For Michelle

You asked how to measure creativity and innovation. Here’s my answer from the product side:

Innovation is validated learning per unit of effort.

  • How many customer insights did you generate?
  • How many hypotheses did you test?
  • How much did you reduce uncertainty about what to build next?

If engineering optimizes for velocity but doesn’t reduce product uncertainty, that’s not innovation—it’s just expensive activity.

The teams that win in 2026 will be the ones who measure the learning rate, not the shipping rate.