Engineering Flow — Part 5
A series exploring how high-performing engineering organizations improve the flow of software delivery through DevOps, Platform Engineering, DORA Metrics, and systems thinking.
In most engineering organizations, the actual work doesn’t take nearly as long as the delivery process suggests.
A developer may need a few hours to make a change. Testing might take another hour. Deploying it could take minutes.
Yet somehow, that change takes two weeks to reach production.
Where did the rest of the time go?
Usually, it was spent waiting.
Waiting for an approval. Waiting for another team to provision an environment. Waiting for a ticket to be assigned. Waiting for a CAB meeting. Waiting for someone to perform a manual deployment.
None of those waits necessarily look significant on their own. Together, they can dominate the lead time of an engineering organization.
Most lead time isn’t engineering work. It’s waiting.
Every Handoff Creates a Queue
Whenever work moves from one person or team to another, it rarely begins immediately.
It waits.
Consider a common delivery process:
Developer → Code Review → QA → Security → Change Approval → Operations → Production
At first glance, that looks like a straightforward serial pipeline. But it’s really seven steps plus the queues between them.
The developer finishes the change, but QA is working on something else. QA finishes testing, but security hasn’t reviewed it yet. Security approves it, but the change has to wait for the next CAB meeting. CAB approves it, but operations has a deployment window Thursday night.
The actual work at each stage may take minutes or hours.
The queues between those stages can take days.
Busy Teams Can Still Create a Slow System
Queueing theory studies what happens when work arrives faster—or less predictably—than a system can process it.
One of its most useful lessons for engineering leaders is simple: as a system approaches full utilization, wait times increase dramatically. In fact, Little’s Law gives us another useful way to see the relationship: as work-in-progress increases relative to throughput, lead time increases with it.
Yet organizations still continue to try to maximize utilization.
We want every engineer busy. Every security analyst busy. Every DBA busy. Every operations engineer busy.
On a spreadsheet, that looks efficient.
In a delivery system, it creates queues.
If the database team is already at capacity when your request arrives, it waits. If security has ten reviews ahead of yours, it waits. If operations has a backlog of deployments, yours joins the queue.
Each team may be highly productive.
The system can still be slow.
Optimizing individual teams for utilization does not necessarily optimize the flow of value.
Tickets Are Often Queues in Disguise
One of the easiest ways to find queues is to look at the ticketing system.
Need a firewall rule? Open a ticket.
Need a database? Open a ticket.
Need an environment? Open a ticket.
Need something deployed? Open a ticket.
The ticket itself isn’t necessarily the problem. Tracking work can be valuable.
The problem is what happens next.
Someone triages it. Someone assigns it. Someone prioritizes it. Eventually, someone performs the work and sends it back.
A task requiring ten minutes of engineering effort can easily spend three days moving through that process.
When this happens hundreds or thousands of times across an organization, the cost isn’t primarily the work.
It’s the waiting.
Governance Doesn’t Have to Mean Waiting
Approvals are another common source of invisible queues.
Many exist for legitimate reasons: security, compliance, stability, separation of duties, or risk management. But organizations often accumulate approvals without continuously asking whether each one still reduces meaningful risk.
CABs are a good example.
A weekly Change Advisory Board creates an automatic queue. Miss Tuesday’s meeting and a change may wait another week—even if the actual review takes five minutes.
The question isn’t whether governance matters. Of course it does.
The better question is:
Can we enforce the same control without making the work wait?
Automated testing, policy as code, security scanning, peer review, deployment controls, and standardized pipelines can often provide stronger controls while dramatically reducing queue time.
Good DevOps doesn’t remove governance.
It engineers governance into the delivery system.
Remove the Handoff, Remove the Queue
The same pattern appears with infrastructure.
An engineer needs an environment and submits a request. The infrastructure work takes 30 minutes.
The environment arrives four days later.
The provisioning time wasn’t really four days. The queue time was three days, 23 hours, and 30 minutes.
This is why platform engineering and self-service matter.
Infrastructure as code, standardized environments, golden paths, automated pipelines, and internal developer platforms aren’t valuable simply because they’re convenient.
They remove handoffs.
And removing a handoff often removes a queue.
The same applies to deployments. If an application team has to schedule an operations engineer to manually deploy its software, the organization has created another queue.
CI/CD changes that flow by allowing teams to safely move changes through standardized, automated pipelines without waiting for another team to perform the next step.
The benefit isn’t simply automation. It’s eliminating waiting from the system.
Measure the Wait
This changes how leaders should think about delivery performance.
When something takes ten days to reach production, don’t just ask why development took ten days.
Ask:
How much of those ten days was someone actually working on it?
You may discover engineering took eight hours. Testing took two. Security review took 30 minutes. Deployment took 15.
Everything else was waiting.
Making the developer 20% faster won’t materially change a ten-day lead time.
Removing a three-day approval queue might.
Automating a two-day provisioning process might.
Eliminating a weekly deployment window might.
The biggest opportunities are often found not by making individual steps faster, but by removing the queues between them.
Optimize for Flow, Not Activity
A development team can hit every sprint commitment. Security can meet every SLA. Infrastructure can maintain high utilization. Operations can execute every scheduled deployment.
Every team can look successful while the end-to-end delivery system remains painfully slow.
Customers don’t experience our organizational boundaries.
They experience how long it takes us to turn an idea into something valuable.
If we want to improve that flow, we have to look beyond how quickly people are working and start looking at how long the work is waiting.
Map the handoffs.
Find the queues.
Then ask which ones actually need to exist.
Because most lead time isn’t engineering work. It’s waiting.
Brendan McCaffrey 