Engineering Flow – Part 2
A series exploring how high-performing engineering organizations improve the flow of software delivery through DevOps, Platform Engineering, DORA Metrics, and systems thinking.
In the first article, I argued that software delivery rarely slows down because engineers aren’t working hard enough. It slows down because work spends too much time waiting.
So the obvious next question is:
What creates all of that waiting?
More often than not, it’s dependencies.
Dependencies Cost More Than We Think
Every engineering organization has dependencies.
Some are technical.
Some are organizational.
Some exist because of regulations or compliance requirements.
Others simply exist because that’s how the company has always been structured, or someone simply wanted additional oversight in the delivery process.
On their own, most dependencies seem reasonable.
But software delivery doesn’t experience them one at a time.
It experiences them together, and very additional dependency compounds the cost of delivery.
One dependency may add very little overhead.
Ten dependencies can fundamentally change how the team delivers software.
A feature may depend on infrastructure, security, networking, a shared API, a database team, architecture approval, and a coordinated release.
None of those are necessarily bad.
But, collectively, they become expensive.
Every Dependency Is a Tax on Delivery
One idea has fundamentally changed how I think about software delivery.
Every dependency is a tax on delivery.
The question isn’t whether you’re paying the tax. The question is whether it’s worth paying.
Like any tax, every dependency adds cost.
Sometimes it’s measured in time.
Sometimes it’s measured in meetings.
Sometimes it’s measured in competing priorities.
Sometimes it’s measured in context switching.
Sometimes it’s measured in uncertainty.
Not every tax is unnecessary.
But every tax should have a purpose.
The same is true for dependencies.
The more dependencies a piece of work accumulates, the harder it becomes to predict when it will reach customers.
Dependencies Reduce Autonomy
The biggest cost of dependencies isn’t speed.
It’s autonomy.
Imagine two engineering teams.
The first owns everything it needs to design, build, test, deploy, and operate its application.
The second depends on five other teams before anything can reach production.
Which team controls its own delivery?
The answer is obvious.
The second team may have outstanding engineers.
They may write excellent software.
They may start every sprint committed.
But they simply can’t control when their work reaches the customer.
Every dependency transfers part of that control somewhere else. As dependencies increase, ownership becomes diluted. Delivery becomes less about engineering and more about coordination.
That raises another important question.
Why Do Organizations Accumulate Dependencies?
Over the years, I’ve noticed another interesting pattern. The dependencies in our software often mirror the dependencies in our organization. When five teams have to coordinate to deliver a feature, it’s often because the organization itself is structured that way.
This observation is known as Conway’s Law, and I’ll explore it in more detail later in this series.
For now, it’s enough to recognize that organizational design influences delivery more than most of us realize.
Not Every Dependency Should Disappear
None of this suggests that every dependency is bad.
Security reviews exist for a reason.
Compliance protects customers.
Specialized expertise creates better outcomes.
The goal isn’t to eliminate collaboration. It’s to eliminate unnecessary dependencies.
High-performing engineering organizations constantly ask questions like:
- Does this team really need another group to complete this work?
- Can this capability become self-service?
- Can this approval become automated?
- Can ownership move closer to the people doing the work?
Every unnecessary dependency that’s removed gives a team greater control over its own outcomes.
A Different Way To Think About Engineering
High-performing engineering organizations don’t simply build faster delivery pipelines.
They build teams that can move independently.
Because autonomy improves flow.
Ownership improves accountability.
And every unnecessary dependency that’s removed shortens the time between idea and customer.
The goal isn’t to remove every dependency.
The goal is to make every remaining dependency intentional.
Engineering Flow Series
- 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. - Every Dependency Is a Tax on Delivery (Current Article)
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.
Brendan McCaffrey 