How I stopped wanting to break silos and why
Two siloed teams trying to work together.
For the last few years, DevOps transformation has been everywhere in the IT and software development world. The idea of changing the way software is shipped and maintained has gained a considerable fanbase – for a good reason. In the 21st century, we have the tools and experience to release reliable software in very short intervals.
In this article, I explore one of the essential ideas of the DevOps movement: the concept of breaking down silos in IT and software development. I’ll define what it means in various constellations and consider its feasibility as a goal.
Who am I, you say? I am Yair Etziony, Head of Operations for Polar Squad in Germany. We are a consulting company specializing in DevOps; I have been breathing and living in DevOps for the last three years. I’ve done various assessments where we’ve learned how teams work on their software cycles; what kinds of things work, and what kinds of patterns are problematic. I believe I’ve gotten a good view concerning the subject, and I would like to share it.
First I would like to ask: can we break down silos? Is this our main goal? Is this even possible? If not, what is our primary goal when we undergo a DevOps transformation?
Let's start with the definition of the word silo:
A tall tower or pit on a farm used to store grain.
An underground chamber in which a guided missile is kept ready for firing.
How can siloed teams communicate?
What does ‘silo’ mean in IT and software development?
Silos are developed when specific departments work as separate entities with their separate visions, goals, and responsibilities. If the people in development aren't passing information to the operations team, workflow quickly becomes bottlenecked and productivity suffers.
Silos can create a situation where coordination is hard or impossible, or where specific teams and departments are fighting for no good reason.
Are you breaking down silos?
If silos are slowing things down, then let us break the silos and set our people free.
It's a great concept when you hear it first. But even from the core meaning of the word, we see the problem; silos are designed to shelter grains or rockets, and breaking them is hard physical work. One might say that it's a violent task.
I think it's a bit of a naive perception of human behaviour. What we call silos is part of the way we operate and think. From my perspective and experience, companies and people need silos to create things before going “public” with them. If we try and break those areas, we might lose those shelters of creativity. If you look at it from a less binary perspective, silos at certain phases might help teams, and we need to ask ourselves and have some criteria as to when we need to destroy them and when to keep them.
Is the goal of DevOps to break down silos? Or something else?
I don't think we are here to break the silos in IT and software development. I believe that DevOps is a path to having better software and better prospects for our business. I feel that working towards the same goals together as an organisation and having joint possible motivations make for better business.
If our goal is to work together, let's define it as working together. I genuinely believe that silos are and will be a part of any company that will ever exist. By definition, any project needs its own time to bloom and prosper, and by default, we humans and teams need our safe places to innovate and experiment. Silos are a bit like “Hydra,” the many-headed serpent or monster in Greek mythology that grew two heads for each one cut off.
Even if we break all the silos, it does not mean we communicate or work together. It's a good idea to point out some areas that are siloed. This makes the DevOps transformation easier. But maybe, instead of breaking things, let’s find something more empowering as a goal? I would argue that opening things will make the communication cumbersome and thus would not be a practical solution.
Breaking down silos sounds like a utopian goal; after we break them, where will we keep all the grains?
What about working together?
I like soft definitions, and maybe instead of having a binary concept that is constantly looming over our heads, we should try and create more peaceful goals for our transformations?
Maybe we don't need to break the silos. What we need is to communicate and work together. This means we put less effort into breaking those silos, slowly making teams share the same goals, and understanding that they are all part of a more prominent organisation.
Creating shared goals for different teams and aligning team members to work together is more important than slogans. Yes, we would like to see other units that collaborate and exchange knowledge about what is needed and how to solve problems. For example, how should we define which metrics should be monitored and what would represent the criteria for the exception that should trigger alerts? In other words, who defines what is our production dashboard? What are the criteria for a reliable product?
A classic Ops team would define everything by themselves and usually resort to the traditional metrics, but I think it's better to use infrastructure experts, platform experts, developers, and product teams to define metrics and exceptions. The reliability of a product should be a shared responsibility – each team should bring in their perspective, and together they should all help define what is needed.
This is an example where all those units share knowledge and responsibilities. They can work on certain projects together for some time and then emerge from their silos to share their work. Then, they go back there and work on their stuff. I think if you have the ability to enjoy both worlds, backed with good communication and collaboration, life is a bit better.
Creating shared goals
Conclusion
My notion is that silos will always exist to some extent in IT and software development teams. Furthermore, I think they are part of our behaviour and can be used as a safe place when we understand them.
I would advocate that for us, the enablers who are doing the transformation, we need to be more critical of our tasks and methodologies and have a better understanding of what we want to achieve when we do them. Otherwise, we would be chasing ghosts that we cant destroy.
It’s a very good practice to understand and map the silos in any organization, but my recommendation is to try and find a way to work together without destroying them.
—
Yair Etziony is the head of operations for Polar Squad Germany. He has over twenty years of experience in various roles, such as QA engineer, System Engineer, and System administrator. He is constantly researching new ways how to improve software development, team practices, and his client’s company culture. Yair holds a BA in modern history and philosophy.