How silos wreak havoc and block your outcome dreams
Dependencies cripple Scrum Teams.
Have you ever seen teams who are truly agile — having honed the ability to move with quick, easy grace?
I have, and it is a sight to see. Such teams can own their product from concept to cash. They collaborate with their customer, and anything less than customer delight annoys them.
These teams use learning to chart their next step. They treat every step as uncertain until evidence proves it was right. These teams use rapid experiments to deliver what their customers need, sooner.
And they don’t consider a feature “Done” until they reach the desired customer outcome. They stand behind what they create and evolve it if it is not “Right.”
“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
— The 2020 Scrum Guide¹
How many hand-offs do these agile teams need to get product features into their customer’s hands? As few as possible. These teams move with agility as they have nearly complete control over their value flow.
Yet, I regret to say, in my experience, many organizations don’t experience this type of agility. Their teams slow to a crawl due to the sheer weight of the silo-induced dependencies tied to their ankles. They are neither autonomous nor empowered, and silos are to blame.
In an organizational context, a silo is essentially a boundary that contains and isolates one department, function, team, or person from others. The boundary can be put in place through behavior or formal means.
Dependencies and many other undesirable effects result from silos. Teams and organizations today feel the pain. Silos inflict far-reaching chaos, misdirect focus, and strip away purpose.

The system effects map above shows the havoc silos inflict. I like these types of maps as they show the downstream, often wicked, impacts better than words alone.
I have some experience breaking down silos. Soon, I will share some advice so you can also start removing the wasteful silos blocking your flow of value. But first, let’s walk through the key aspects of this map.
Why do we have silos?
We don’t form silos with the intent of wreaking havoc on our value flow. Our intentions are good. But we often don’t realize the far-reaching negative impacts of silos.
Our love for silos runs deep, originating in Taylorism and Scientific Management. In 1919, Frederick Winslow Taylor formulated The Principles of Scientific Management². With this, Taylor instigated the silo habit, and it has proven impervious to change.
The popular interpretation of Taylor’s principles is one of mechanistic thinking that favors separation of duties based on job function. For example, Scientific Management splits mental and physical labor to isolate thinkers from doers. And the management and doers are aligned to specific jobs or functions.
This separation has evolved further over time to a state of extreme specialization today. Each functional team has its own required skill, workers skilled in that job, a specific series of steps to follow, and a manager to do the thinking and direct the team.
The unfortunate result reduces humans to robots following their programs, building their widgets. This recipe following may work for repetitive factory work. But it does not match the creative needs of modern, complex, custom product development.
We turn to silos as an answer to our constraints. A few of the constraints we solve with silos are below:
- Not enough people with a particular skill or knowledge
- Managing complexity at scale
- Budget constraints
- Offshore team members in a time zone inconvenient for collaboration
- Not enough experienced team members for complex tasks such as strategy and design
- A fear of failure or a lack of safety
- No authority to change the system
Our habits become hardened over time to prefer silo building. We accept it as the “way we work.” Moving outside this status quo is like trying to swim against the current. It’s a ton of effort and consumes too much time and space we often don’t have to give.
Before long, we give in to the strong current of silos and let it sweep us into its treacherous flow.

Havoc №1: Dependencies and waiting — a loss of control
When you have silos, you will have dependencies. The notion of the cross-functional team gets lost. Team control over its end-to-end flow of value evaporates.
When dependencies exist in high numbers, the barriers to breaking them seem impenetrable. We get stuck in the mentality of believing this is the way things have to be. After all, this is the way many organizations, including yours, have always worked.
When we give in to dependencies being a way of life, we allow waiting to become a part of our system of work. We expect it. And the value we need to realize gets lost in a sea of waiting.
This is about the time we begin to fight back. We attempt to gain back control with big upfront planning. Our belief: if we map out everything and all the dependencies, we are in control. But we never have complete control when dependencies are in play.
When we see our control continue to dissolve despite our efforts, we fall to a dark place. We set deadlines for other silos, focus on our interests, and blame other silos for delays. It’s ugly and does nothing to put our customer’s concerns first.
Havoc №2: Turf building and self-interests
Turfs destroy teamwork. And functional silos create the perfect Petri dish for turfs to build up and take hold. Turfs form boundary lines and lead to unfavorable anti-teaming conditions in the workplace.³
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
— The 2020 Scrum Guide¹
A cross-functional team is central to Scrum. But a silo puts the silo’s functional interests first. It ignores the fact all functions necessary to deliver product features must be in play.
When functional interests are the focus, collective ownership across functions diminishes. The idea of “one team” delivering customer value can’t materialize.
This leads to local optimization of the silo’s interests. The silo tries to stay busy building its specialized widget. And when it reports out how well it is doing this, “green” is usually the status.
The self-interest of the silo leads to these local optics and doesn’t help with value flow transparency. Being “done” to the functional silo means its type of widget is “done.” The customer feature is not “done” when a silo is “done.” The silo’s widget is not integrated with other silos’ widgets, and a customer can’t use it.

What we have is a bunch of unintegrated pieces and parts. The late integration hides problems and leads to late learning. This slows value flow to a crawl and often stops it completely with late-stage “code red” scenarios. Here blaming takes hold and psychological safety takes a big hit; nobody is happy.
Turfs take the focus off the customer and put it instead on selfish local concerns. Nothing good comes of them.
Havoc №3: Decreased collaboration
A silo reduces cross-functional collaboration by reinforcing communication barriers.
Within a silo, we collaborate great with our fellow like-function team members. But communication outside of the walls becomes contrived.
We often fall back on low-bandwidth, asynchronous forms of communication. Documentation or emails become the way we pass information between silos. Face-to-face or video-to-video communication has a hard time penetrating the silo walls.
And shared understanding takes a steep fall when we don’t collaborate well. When we miss details, the familiar failure mode of late learning returns. And with it comes “code red” scenarios and a diminished flow of value.
It’s not easy to collaborate when you are not on the same team.
Havoc №4: The death of customer empathy
When we are in a functional silo, the customer is far, far away.
On-time, high-quality, on-budget delivery of our functional silo’s widget is our concern. Customer? What customer?
A silo obscures the customers’ needs we are trying to solve. It washes them from our vision. We often don’t know why we are building the widget or how it will help our customers.
This leads to robot teams, low innovation, and producing the wrong thing late. And we are once again in the pain loop of late learning and its wicked effect on value flow and our well-being as a team.
Without our customers in view, how can we drive in the right direction?
What to do about this predicament
At the root of the four havocs described above is the silo. Dissolve the silo and you break the cycle.
But many organizations rarely see this as an option. Either the sheer number of silos seem insurmountable, there is no authority to change, or there is no time.
But making one step in a better direction can show value. And this can build confidence and momentum for more. Simple math can prove every dependency you break doubles your chance of delivering on time.⁴
Below is a three-step process I’ve used to help dissolve silo dependencies.
Step 1 — Select one high-impact silo dependency
We will never be able to eradicate all silo dependencies for a team. It is often impractical to remove them all. Given this, we should focus our effort on the highest impact silos often plaguing our flow of value.
Figure 1 shows an impact mapping tool you can use to pick a high-impact silo to dissolve. First, note the frequency of the silo dependency. Then, assess the pain felt when you encounter it.

Map all your known silo dependencies. Then, pick one of the silo dependencies in the top right quadrant and proceed to Step 2.
Step 2 — Break the silo dependency
There are three strategies you can use for breaking a silo dependency as shown in Figure 2.

Strategy 1: Do It Their Way
Develop the dependent item yourself in the way the other silo you are dependent on would do it. This can be a hard pill for the dependency silo to swallow if they keep tight control over their turf. But it can be the best solution for all if they are willing.
This option often requires upfront guidance from the dependency silo on their standards. Also, you will need ongoing mentoring from them during your development. But after you have done this once, you now have this capability for similar situations in the future.
Strategy 2: Do It Your Way
Develop your own mechanism, a workaround to bypass the silo dependency for now. Sure, this creates duplicate parallel efforts, but it avoids the dependency havoc. And most important, it keeps your value flowing.
The dependent silo will eventually be ready to do the work you desire for a more permanent solution. You can provide the workaround you created as the ultimate specification. When the other silo finishes, you refactor it in place of your workaround.
Strategy 3: Wait For It
With this strategy, you simply wait for the dependent silo to complete its part. When the dependency completes, then do your work. Don’t waste time trying to predict or coordinate when the silo dependency will finish your need. Start working when the silo dependency finishes…period.
This option is the least desired. We are still creating incomplete pieces and parts. But we are avoiding wasteful coordination and the painful impacts of deadlines.
Step 3 — Repeat
When you have removed one silo dependency, inspect your success. Bathe in the bliss of bringing more control to your team to deliver value on its own. Then, don’t waste time, go to step 1 and repeat the process.
Taking it forward
We can’t afford to settle for silos. Silos delay value for our customers and cause us much pain as we attempt to deal with their fallout.
Silos have been a part of the way we work for so long we have accepted them as our fate. But accepting them delays our value flow in many ways:
- Increases dependencies, leading to a loss of control and lots of waiting
- Builds turfs and self-interest, fostering disjointed ownership and ultimately a blame-centric environment
- Decreases cross-functional collaboration, reducing shared understanding and causing missteps
- Takes the customer out of our sights, leading to teams without customer empathy and a clear purpose
We must take the time to form small, cross-functional teams that can deliver ideas to customers. This task can seem insurmountable. But we can take incremental steps and start seeing value fast with three easy steps:
- Select your highest impact silo dependency
- Break the silo dependency
- Rinse and repeat
Taaichi Ohno, the father of the Toyota Production System, said it best.
“All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes.”
— Taiichi Ohno
Can you afford to waste your customer’s time by living with silos? Why not pick one thwarting your flow of value, and dissolve it today? Your customers, your teams, and your organization will be better for it.
Did you enjoy this post? Why not become a Medium member today and support Todd along with thousands of other writers.
Related reads
You can find other related posts from the author below:
References
- The 2020 Scrum Guide, Jeff Sutherland and Ken Schwaber, November 2020, scrumguides.org
- The Principles of Scientific Management, Frederick Winslow Taylor, 1919, Harper & Brothers Publishers
- How to Navigate a Turf War, Amy Gallo, HBR.org, September 27, 2017
- Impact of Multiple Team Dependencies in Software Development, Troy Magennis, ObservableHQ.com, July 28, 2019

