Fast and Fragile?
Measuring Software Quality with DORA Metrics
You’re Deploying Fast, But Can You Trust It?
Velocity can be deceptive.
You see code being merged. Features released. Sprints closed.
There’s movement. You’re shipping.
But then it hits you: an incident, a rollback, a regression no one saw coming.
And suddenly, that sense of progress collapses into doubt.
We were moving fast. But were we building safely?
That’s when the realization sets in:
Speed is meaningless if the system can’t handle it.
Confidence in your delivery process isn’t built on how fast you go, it’s built on how well you recover, adapt, and improve over time.
The Problem: Quality is Invisible Until It Fails
Unlike delivery flow, which you can observe in Jira or Git, operational quality doesn’t show up in your backlog.
It reveals itself through pain:
Developers hesitating to deploy on Fridays (or at all).
Firefighting becomes routine.
Bug queues grow faster than feature requests.
Teams quietly avoid touching certain parts of the codebase.
What you’re seeing is fragility.
And what’s missing is a shared, actionable way to talk about it.
The Solution: DORA Metrics as System Health Indicators
In the DevOps world, one set of metrics has emerged as the industry standard to answer a simple but critical question:
Are we delivering software with quality, consistency, and confidence?
These are the DORA Metrics, born from research at Google and backed by years of data from elite-performing teams across the world.
They’re not arbitrary.
They’ve become de facto standards because they capture what most other engineering metrics miss:
✅ stability,
✅ resilience,
✅ flow effectiveness,
✅ and learning rate.
Here they are:
🚀 Deployment Frequency
How often do we deploy to production?
High frequency suggests smaller batch sizes, faster feedback, and a healthy delivery culture. But only if it doesn’t lead to instability.
⏱️ Lead Time for Changes
How long does it take from code commit to production?
This shows your system’s responsiveness. If it's too long, it likely means handoffs, bottlenecks, or fear are slowing you down.
🔥 Change Failure Rate
What percentage of deployments cause issues?
A high failure rate often signals brittle architecture, unclear ownership, or insufficient testing, and it's one of the most underreported problems.
🛠️ Time to Restore Service
How quickly can we recover from an incident?
This is the metric of operational maturity. It's not about perfection, it’s about learning fast, diagnosing issues, and reducing blast radius.
These metrics are powerful because they’re outcome-focused.
They don’t reward busywork. They reflect how your system behaves in real conditions, under real pressure.
How We’re Using Them
We’ve integrated DORA Metrics into our delivery conversations, not as performance targets, but as health signals.
Each product team:
tracks and reflects on its own DORA values,
discusses trade-offs between speed and stability,
and learns how architecture, test strategy, and team habits affect all four metrics.
We don’t obsess over benchmarks.
We ask better questions.
For example:
Is our recovery time improving or getting worse?
Why are we avoiding deployments in certain domains?
What patterns do we see before incidents happen?
📌 We don’t use DORA to measure people. We use DORA to measure learning.
And what matters most isn’t where we are, but whether we’re seeing what needs attention, and having the right conversations.
Conclusion: Delivery Without Trust is Risk, Not Progress
Speed without quality is like acceleration without steering.
As tech leaders, we’re accountable not just for “how much we ship”, but how safely, sustainably, and confidently we evolve our systems.
The DORA Metrics give us a way to make quality visible. To reduce fragility. To build trust, both in the process, and in each other.
And ultimately, they help shift the focus from “did it deploy?”
to “are we building something we can stand behind?”
What’s Next: From Code to Business Value, Becoming a Product Organization
In the next article, we’ll step back and look at the bigger picture.
How do you go from being a company that delivers software…
to a company that builds products?
We’ll explore how we restructured us from a project-based delivery model to a product organization, starting with one of the hardest and most powerful shifts:
📍 discovering our business value streams, and mapping our teams accordingly.
Because metrics help, tools support, but real impact starts with knowing who you’re serving and why it matters.
📩 Curious how others are approaching this transition? Reach out, I’d love to hear your story.
very good points Francesco!