Engineering Flow — Part 6
A series exploring how high-performing engineering organizations improve the flow of software delivery through DevOps, Platform Engineering, DORA Metrics, and systems thinking.
In Part 5, we looked at one of the biggest hidden problems in software delivery: most lead time isn’t engineering work. It’s waiting.
That raises an important question.
If we want to improve the flow of software delivery, how do we know whether we’re actually getting better?
Engineering organizations certainly aren’t short on metrics.
Story points. Velocity. Tickets closed. Sprint commitments. Utilization.
We measure a lot.
But many of these metrics tell us how busy individual teams are—not how effectively the engineering system delivers value.
A development team can increase its velocity while lead time gets worse. Infrastructure can maintain 95% utilization while requests spend days waiting. QA can hit every SLA while releases still take weeks to reach production.
Every team’s dashboard can be green while the delivery system is red.
What we measure shapes what we optimize.
Story Points Aren’t a Business Outcome
Story points have a legitimate purpose.
Within a team, they can help estimate relative complexity, plan work, and understand how much work the team can reasonably take on. Velocity can help that same team understand its historical capacity.
The problem begins when these planning tools become measures of engineering performance.
A team completed 60 story points this sprint.
Is that good?
Story points aren’t standardized units. Five points on one team may have little relationship to five points on another. More importantly, the number tells us nothing about whether the work reached production, improved the customer experience, or created business value.
Once leaders set velocity targets, teams also begin optimizing the metric. The number can increase without anything about the delivery system actually improving.
Story points can help teams plan work. They shouldn’t be confused with measuring value.
Utilization Tells Us Who Is Busy
The same problem exists with utilization.
As we saw in Part 5, maximizing utilization can actually make delivery slower by creating queues.
If engineers are 95% utilized, that sounds efficient. But a highly utilized team can still have a growing backlog and increasingly long lead times.
Some available capacity allows teams to review work quickly, respond to incidents, absorb unexpected demand, or help remove constraints elsewhere in the system.
The question isn’t: How busy is everyone?
It’s: How effectively is work moving?
That requires different metrics.
Measure the Delivery System
One of the most useful ways to measure this comes from DORA (DevOps Research and Assessment) and its software delivery performance metrics.
Rather than measuring how much activity engineering produces, DORA metrics help us understand how effectively software changes move through the delivery system.
Four measures are especially useful:
Deployment Frequency — How often can we successfully deploy changes to production?
Lead Time for Changes — How long does it take a change to move from committed code to running in production?
Change Failure Rate — What percentage of production changes result in degraded service and require remediation?
Mean Time to Restore (MTTR) — When something goes wrong, how quickly can we restore service?
Notice what these metrics don’t measure.
They don’t ask how many story points developers completed, whether everyone was fully utilized, or how many tickets operations closed.
They measure the behavior of the delivery system.
Together, they also balance two things engineering organizations sometimes treat as opposites:
Speed and stability.
Deployment frequency and lead time tell us how quickly changes can move. Change failure rate and recovery time tell us whether we can move them safely.
The objective isn’t simply to deploy faster.
It’s to build a system capable of delivering changes quickly, safely, and repeatedly.
Lead Time Exposes What Team Metrics Hide
Lead time is particularly powerful because it crosses organizational boundaries.
Imagine a change requires four hours of development, one hour of testing, 30 minutes of security review, and 15 minutes to deploy.
Measured individually, every team might look efficient.
But if the change takes nine days to reach production, something is missing from those measurements.
The elapsed time exposes it.
This is exactly the problem we explored in Part 5.
The work isn’t necessarily slow. The system is.
Lead time forces us to look at the entire journey instead of celebrating the efficiency of individual steps.
Once we measure that journey, we can ask better questions.
Where is work waiting? Where does it repeatedly get blocked? Where are batches forming? Where are handoffs adding delay?
Those questions take us beyond DORA and into broader flow metrics.
Flow Metrics Help Explain Why
DORA metrics tell us a great deal about software delivery performance.
Flow metrics help explain what’s happening inside the system.
How much work is currently in progress?
How long does work remain active before completion?
How much work is completed over time?
How much time is spent working compared with waiting?
Consider two teams that each complete 20 items this month.
On an output dashboard, they look identical.
But Team A typically moves work from start to finish in three days while Team B takes three weeks.
That’s a very different delivery system.
Or perhaps Team B has 75 items simultaneously in progress while Team A has 15.
The problem may not be how quickly people are working. There may simply be too much work moving through the system at once.
Measuring flow helps us see the system instead of just its individual parts.
Be Careful What You Turn Into a Target
There’s another danger with engineering metrics.
The moment a measure becomes a target, behavior begins changing around it.
Measure developers by lines of code and you’ll get more code. Measure teams by tickets closed and you’ll get more closed tickets. Measure velocity and story points tend to increase.
That doesn’t mean measurement is bad.
It means metrics need context.
Even DORA metrics shouldn’t become another scoreboard used to rank teams. The value comes from establishing a baseline, identifying constraints, and seeing whether changes actually improve delivery.
Metrics should create conversations.
They shouldn’t replace them.
Optimize the System, Not the Scorecard
This brings us back to one of the central ideas behind Engineering Flow.
Local optimization does not guarantee system optimization.
Development can increase velocity. QA can increase throughput. Infrastructure can increase utilization. Operations can close more tickets.
Every individual metric can improve while customer lead time remains unchanged.
Customers don’t care how many story points were completed, how many tickets changed status, or whether infrastructure reached its utilization target.
They experience how effectively we turn an idea into something valuable.
That’s the system we should measure.
Start with deployment frequency, lead time, change failure rate, and recovery time. Look deeper with flow metrics to understand where work is slowing down. Use team-level metrics like velocity for the purposes they were designed for: helping teams plan—not proving productivity.
Because engineering organizations eventually optimize around the things leaders choose to measure.
Takeaway: You get what you measure. Measure activity, and teams optimize activity. Measure flow, and organizations optimize delivery.
Brendan McCaffrey 