Last week our team shipped 47 deployments. Our DORA dashboard lit up green across the board—deployment frequency
, lead time
, change failure rate
. The VP of Engineering shared it in the all-hands. We got Slack kudos.
Then I looked at what we actually shipped: 31 dependency updates, 9 bug fixes, 4 config changes, 2 performance tweaks, and exactly one feature that required creative problem-solving.
We optimized for velocity. We became a deployment factory. And honestly? I’m not sure we’re building anything innovative anymore. ![]()
The DORA Dominance Era
For the past few years, DORA metrics have been the gold standard. Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Recovery—these four (now five with Rework Rate) became the north star for engineering excellence.
And for good reason. They’re quantifiable. They’re objective. They correlate with high-performing teams. Platform engineering teams built entire observability stacks around them. 40.8% of organizations use DORA as their primary framework, more than any other metric.
But here’s what I’ve noticed: the things we measure shape the things we build. And when you measure velocity, you get… velocity. Not necessarily value.
The Shift Nobody Saw Coming
The industry is starting to whisper something different. Research from 2026 shows that developer experience is a stronger predictor of productivity than technical factors like tooling or infrastructure performance.
The SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency) is gaining traction—14.1% adoption and growing. Teams are asking: “Are our developers in flow state? Do they feel productive? Are we creating cognitive load or reducing it?”
Gartner’s 2026 predictions suggest that creativity and innovation will replace velocity and deployment frequency as the metrics that matter. Not “how fast did you ship” but “what problem did you solve creatively?”
The Uncomfortable Truth
What if we’ve been optimizing for the wrong thing this whole time?
What if DORA metrics turned engineering teams into feature factories—churning out deployments, closing tickets, hitting velocity targets—while the actual creative problem-solving atrophied?
In my failed startup, we had beautiful velocity metrics right up until we pivoted three times and ran out of runway. We were shipping fast. We just weren’t shipping the right things. And nobody on the team felt empowered to stop and ask: “Are we solving a real problem here, or just completing stories?” ![]()
The AI Era Makes This Worse
Now add AI coding assistants to the mix. 26% faster task completion, but 1.7x more defects. We can generate code at machine speed. But are we generating creative solutions?
AI can autocomplete your code. It can’t autocomplete your innovation.
If your metrics reward “lines of code deployed” and “PRs merged,” you’re incentivizing volume. And AI is really good at volume. But creativity? That still requires humans in flow state, with psychological safety, with time to think.
The Measurement Problem
Here’s where I’m stuck: how do you measure creativity and innovation?
DORA works because it’s objective. Deployment frequency is a number. Lead time is a duration. You can trend it, dashboard it, set targets.
But creativity? Innovation? Those feel… squishy. Subjective. Hard to quantify without gaming the system (e.g., “We had 12 innovation ideas this sprint!” where half are renaming variables).
Some teams are trying:
- Developer Satisfaction NPS: Strongest predictor of productivity
- Time in Flow State: Measured through surveys and interruption tracking
- Cognitive Load Reduction: How much context-switching happens
- Rework vs New Work Ratio: Are we maintaining or creating?
But I haven’t seen a framework as clean as DORA that captures “are we actually innovating here?”
What Should We Track Instead?
I’m genuinely curious what others are doing. Are you:
- Sticking with DORA and accepting the limitations?
- Combining DORA + SPACE for a hybrid view?
- Moving to qualitative metrics like team retrospectives and developer surveys?
- Inventing your own framework that balances velocity with creativity?
Because right now, my team’s dashboard says we’re crushing it. But when I look at what we’re actually building, I wonder if we’re measuring the wrong things entirely. ![]()
![]()
What metrics do you track? And more importantly—do they capture whether your team is doing creative work or just fast work?