Engineering Flow – Part 1
A series exploring how high-performing engineering organizations improve the flow of software delivery through DevOps, Platform Engineering, DORA Metrics, and systems thinking.
For years, I’ve seen organizations try to improve software delivery the same way:
Push engineers to work harder.
Increase velocity.
Add more meetings.
Hire more developers.
Work nights and weekends.
Yet somehow, delivery never gets much faster. In fact, it often gets slower.
I’ve come to believe that, more often than not, the problem isn’t the people.
It’s the system they work in.
Where Does Work Actually Spend Its Time?
Think about a typical feature request.
The actual engineering work might take a few hours or a few days.
But before and after that work, it often sits idle.
Waiting for:
- Infrastructure to be provisioned.
- Requirements to be clarified.
- A pull request review.
- Another team’s approval.
- Code promotion.
- QA testing.
- UAT testing.
- CAB approval.
- A production release window.
The code isn’t moving.
The feature isn’t creating value.
The work is simply waiting.
Those waiting periods often exceed the time spent actually building the feature.
Every Handoff Is a Queue.
One idea that has really changed how I think about software delivery is this:
Every handoff creates a queue.
Every queue creates delay.
Every delay increases risk.
When work moves between teams, tools, or approval steps, it almost always slows down.
Individually, each queue may seem reasonable.
Together, they can stretch a two-day feature into a two-week delivery.
The more dependencies a team has on others to deliver solutions, the less control it has over its own delivery speed. High-performing organizations work to reduce those dependencies, not just to move faster, but to give each team greater ownership of its own outcomes.
That is why improving engineering isn’t just about writing better code—it’s about improving how work flows through the entire system.
Technology Can Help, But Only If It Removes Friction
Practices like Continuous Integration, Continuous Delivery (CI/CD), automated testing, and Platform Engineering aren’t valuable simply because they’re modern.
By reducing batch sizes and accelerating feedback, these practices help teams learn faster and deliver with greater confidence.
They’re valuable because they reduce friction.
They eliminate unnecessary waiting.
They shorten feedback loops.
They make it easier, and safer, for work to move from idea to customer.
Measuring What Matters
This is why I believe DORA Metrics matter.
They don’t measure how hard engineers are working. They measure how effectively work flows through the delivery system.
Optimizing one team doesn’t necessarily optimize the entire system. A team can become more efficient while the organization as a whole becomes slower.
They shift the conversation away from questions like:
- “How many story points did we complete?”
- “Are developers busy enough?”
And toward questions like:
- How long does it take to go from idea to production?
- How often can we safely deploy?
- How quickly can we recover from failures?
- Where is work getting stuck?
Those are system questions, not individual performance questions.
A Different Way To Think About Engineering
I’ve become increasingly convinced that high-performing engineering organizations don’t optimize for busy people.
They optimize for smooth flow.
When work flows well:
- Customers receive value sooner.
- Teams spend less time waiting.
- Deployments become less risky.
- Engineers experience less frustration.
- The business can adapt more quickly.
The best engineering organizations don’t optimize people, they optimize the systems so people can do their best work.
That’s the philosophy behind everything I’ll be writing about in this series.
This is the first post in the Engineering Flow series, where I’ll explore how DevOps, Platform Engineering, DORA Metrics, and organizational design help teams deliver software faster, safer, and with less friction.
Engineering Flow Series
- Your Team Isn’t Slow. Your Delivery System Is. (Current Article)
The foundation of Engineering Flow: why software delivery is constrained more by systems than by individual effort. - Every Dependency Is a Tax on Delivery
why team dependencies reduce autonomy and slow delivery - Why Platform Engineering Exists
How platforms enable autonomy without sacrificing governance. - CI/CD Isn’t About Automation. It’s About Reducing Risk.
Why smaller deployments are actually safer deployments. - Every Handoff Is a Queue
The hidden cost of waiting, approvals, and organizational bottlenecks. - Stop Measuring Output. Start Measuring Flow.
Why engineering effectiveness starts with measuring systems, not activity. - DORA Metrics Aren’t KPIs
How to use DORA Metrics to improve systems, not evaluate people. - CI/CD Is Easy. Culture Is Hard.
Why trust, ownership, and feedback matter more than tooling. - Why Engineering Leaders Should Care About DORA Metrics
Using engineering metrics to improve organizational performance. - 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.
Where does work spend the most time waiting in your software delivery process?
Share your experience in the comments.
Brendan McCaffrey 