Brendan McCaffrey

Engineering Flow — Part 9

A series exploring how high-performing engineering organizations improve the flow of software delivery through DevOps, Platform Engineering, DORA Metrics, and systems thinking.

DORA metrics are often treated as engineering metrics.

Deployment frequency. Lead time for changes. Change failure rate. Recovery time.

Put them on a dashboard, give engineering teams access, and periodically review whether the numbers are moving in the right direction.

But that misses much of their value.

DORA metrics can tell engineering leaders something much more important than how quickly developers are shipping software.

They can provide visibility into the health of the entire software delivery system.

And that makes them leadership metrics.

Your Delivery System Is a Leadership Concern

If lead time is increasing, the immediate reaction might be to ask why developers are taking longer to deliver.

But development may not be the problem.

• Maybe changes sit for days waiting for approval.
• Maybe teams depend on another group to provision infrastructure.
• Maybe testing is largely manual.
• Maybe releases require coordination across six teams.
• Maybe developers spend significant time navigating security reviews, change management processes, or production access restrictions.

Those aren’t necessarily engineering productivity problems. They’re organizational system problems. And many of them cannot be solved by the engineering team alone, or through the use of Agentic AI.

They require leadership.

That is where DORA becomes particularly valuable. The metrics don’t simply tell leaders whether engineering is performing well. They provide signals about where the delivery system may be creating friction.

From Dashboard to Diagnosis

Executive dashboards have a tendency to turn complex systems into red, yellow, and green boxes.

That can be useful for visibility, but it can also encourage the wrong conversation.

If deployment frequency is red, the question shouldn’t immediately be: How do we get this number green?

A better question is: What is preventing teams from delivering safely and frequently?

That question changes the conversation.

• A long lead time might reveal excessive approval gates.
• A high change failure rate might expose weak automated testing or poor deployment practices.
• Slow recovery might point toward observability gaps, architectural complexity, unclear ownership, or fragile operational processes.
• Low deployment frequency might reveal large batch sizes, tightly coupled systems, or release processes requiring significant manual coordination.

The metric is the starting point.

Leadership’s job is to investigate the system behind it.

DORA Can Help Guide Investment

Technology leaders constantly make investment decisions.

• Do we need more engineers?
• Should we build a platform engineering capability?
• Should we invest in CI/CD modernization?
• Do we need better observability?
• Should we automate infrastructure provisioning?
• Is technical debt becoming an organizational constraint?

Without visibility into the delivery system, those decisions can easily become driven by anecdotes, escalations, or whoever makes the strongest case.

DORA provides another source of evidence.

Suppose lead time is consistently high because engineers wait several days for environments to be provisioned.

Hiring more application developers probably won’t solve the problem. But, improving self-service infrastructure might.

Or suppose deployment frequency is low because every production release requires extensive manual validation.

The constraint may not be development capacity at all. The better investment could be automated testing and deployment.

This is where engineering metrics become leadership tools.

They help leaders distinguish between capacity problems and system problems.

Look for Organizational Friction

Some of the most valuable insights from DORA appear when leaders stop looking at individual teams and start looking across the organization.

Imagine one team can deploy multiple times per day while another deploys once every few weeks.

The instinct might be to compare the teams.

Instead, compare their systems.

• Does one team own its deployment pipeline while the other depends on a centralized release team?
• Does one have automated testing while the other relies on manual regression testing?
• Does one have loosely coupled architecture while the other must coordinate releases across several applications?
• Does one have self-service infrastructure while the other submits tickets?

Those differences matter.

DORA can help leaders find places where organizational structure, architecture, tooling, and process are constraining engineering flow.

That is much more valuable than simply ranking teams by performance.

The Bottleneck May Be Above the Team

One of the uncomfortable realities of engineering leadership is that many delivery problems aren’t caused by engineers.

They’re caused by the environment we’ve built around them.

• Approval structures.
• Funding models.
• Organizational boundaries.
• Legacy architecture.
• Centralized dependencies.
• Security processes.
• Change management.
• Infrastructure constraints.

Teams can continuously improve their own practices and still hit a ceiling if the larger organization doesn’t change with them.

That is why improving software delivery cannot be delegated entirely to engineering teams.

At some point, the constraint moves outside their control.

When that happens, leadership has to remove it.

Connect Engineering Flow to Business Outcomes

Executives ultimately don’t care how many deployments occurred last month. Nor should they.

They care about what the organization can accomplish.

• How quickly can we respond to customers?
• How long does it take to move an idea into production?
• How safely can we make changes?
• How quickly can we recover when something goes wrong?
• How much organizational effort does it take to deliver new capabilities?

Those are business questions.

DORA gives technology leaders a way to connect engineering practices to those broader outcomes.

Faster, safer delivery means the organization can experiment more quickly, respond to changing customer needs more quickly, reduce the risk associated with releases, and get value from technology investments sooner.

The metrics matter because the capabilities behind them matter.

DORA Belongs in Leadership Conversations

DORA shouldn’t become another executive scorecard where teams are ranked and leaders demand that every number improve each quarter.

That would miss the point.

Instead, DORA should help leadership ask better questions.

• Where is work waiting?
• Where are teams dependent on other teams?
• Where are manual processes slowing delivery?
• Where is architecture limiting our ability to change?
• Where would investment remove the greatest constraint?

And perhaps most importantly: What part of the delivery system are we, as leaders, responsible for improving?

Because engineering flow isn’t simply an engineering problem.

It’s an organizational capability.

And improving that capability is ultimately a leadership responsibility.

The Takeaway

DORA metrics aren’t just engineering metrics. They provide leaders with visibility into the health of the software delivery system and evidence for where leadership attention and investment may be needed.

The goal isn’t to make the dashboard green. The goal is to build an organization capable of delivering value quickly, safely, and sustainably.

And sometimes the most important thing DORA reveals isn’t what engineering needs to change.

It’s what leadership needs to change.

Engineering Flow Series

1. Your Team Isn’t Slow. Your Delivery System Is.
   The foundation of Engineering Flow: why software delivery is constrained more by systems than by individual effort.
2. Every Dependency Is a Tax on Delivery
   Why team dependencies reduce autonomy and slow delivery
3. Why Platform Engineering Exists
   How platforms enable autonomy without sacrificing governance.
4. CI/CD Isn’t About Automation. It’s About Reducing Risk.
   Why smaller deployments are actually safer deployments.
5. Every Handoff Is a Queue
   The hidden cost of waiting, approvals, and organizational bottlenecks.
6. Stop Measuring Output. Start Measuring Flow.
   Why engineering effectiveness starts with measuring systems, not activity.
7. DORA Metrics Aren’t KPIs
   How to use DORA Metrics to improve systems, not evaluate people.
8. CI/CD Is Easy. Culture Is Hard.
   Why trust, ownership, and feedback matter more than tooling.
9. Why Engineering Leaders Should Care About DORA Metrics (Current Article)
   Using engineering metrics to improve organizational performance.
10. Why Most Data Engineering Teams Aren’t Practicing DevOps
    Applying modern software delivery principles to data platforms.

If you enjoyed this article, consider subscribing for future posts in the Engineering Flow series.