If you’re a leader at a large corporation, then you’re familiar with the term “organizational silo” – a system, process, or department that operates in isolation from others. Generally, silos have a nasty reputation. They cause unknown dependencies and us vs. them situations that lead to broken handoffs, conflicting priorities, and invisible decisions. The DevOps community is particularly critical of silos, and for good reason: Expensive delays occur when development and operations teams don’t share mutually critical information.
How do we fix our silo problems? The answer often posed at DevOps conferences – where it’s not uncommon to see a speaker or three with images of blown-up silos in their presentations – is to get rid of silos altogether. Their opinion is supported by the belief that blowing up silos will eliminate problems related to teams working in isolation. But research shows that it could have the opposite effect.
[ Some common DevOps wisdom falls flat. Read 7 pieces of contrarian DevOps advice. ]
Why blowing up silos is not the answer
What businesses are having to do in the 21st century is really hard. And it’s getting harder. An Innosight.com study shows that almost 50 percent of today’s S&P 500 will be replaced by 2030.
If you’re consumed with staying afloat amongst your competition, then transforming how your organization performs is likely top of mind. For most companies, transformation of some sort is necessary to enable teams to deliver value faster.
Blowing up the organizational structure may seem like the answer – and if you’re facing an incredibly dire situation, maybe it is. But for most of us, wreaking havoc on people’s organizational systems won’t solve our problems. Big change is so massively disruptive that people resist it and freak out, consumed by anxiety over future unknowns. Not much else disrupts performance more than a reorg.
During one reorg, the IT Ops department was split into three different teams (Ops Engineering, Ops Build, and SRE). Individuals spent six weeks consumed with uncertainty and not delivering any business value. Ripping the Band-Aid off quickly did not reduce concerns over the new boss, lost teammates, or coping with change. Instead, people had even more questions and anxieties: How do I fit into this new hierarchy? What are the new rules? What about Bob?
If you are trying to turn your ship around – quickly – then blowing up silos can weaken your efforts and set you back by weeks or even months. In the age of digital transformation, time thieves hurt and every day counts.
[ Some people get confused about Agile vs. DevOps. We break it down: Read Agile vs. DevOps: What’s the difference? ]
Why silos have value
The problems of miscommunication and unavailability are real. Often the problems begin when teams are unaware of mutually critical information and unable to consider the perspectives and priorities of other groups. Like when product team Bot is fighting a DNS issue and needs someone from the network team to help. But the network team is unavailable working to resolve a firewall incident that broke Product team AI’s web application.
Stories abound of development and operations teams that are in direct conflict with each other. But blowing up silos is a faulty approach. Like most complex systems, the myriad of issues surrounding silos goes deeper than organizational structure.
Silos occur naturally and evolve over time based on human need. For the bulk of human existence, people lived in silos because they were effective. People survived because everyone knew each other intimately. Jane helped Jill fight enemies and Joe helped Jack hunt bear. Social instincts helped our ancestors to form the necessary friendships and hierarchies to hunt and forage together, which allowed them to survive in isolation.
In his best-selling book, “Sapiens,” author Yuval Harari points out, “The social instincts of humans adapted only for small groups. When the band grew too large, its social order destabilized and the band split. There was no way so many strangers could live together.”
The most important thing you need to know about humans and silos is that people don’t trust people that they don’t know well.
Trust is established over time from frequent interaction and mutual support. A startup of 50 people can function well on the basis of close relationships with minimal process. There is no need for bureaucracy or governance to preserve alignment. But when companies grow large, things can no longer work that way. You cannot run a company with thousands of engineers the way you run a small startup. The amount of information that must be obtained and remembered to maintain relationships with lots of different people is prohibitive.
