It’s time to bring back silos
Transport yourself back to college. You’re in the middle of studying for your final exam: a singular task that you’ll likely have inexplicable nightmares about for many decades to come. Behind you, your roommate hums Thrift Shop by Macklemore. An open window brings with it cars honking and people shouting: the most charming sounds of vibrant nature at play. A pigeon lands and looks at you. You look back and you forget everything.
DevOps people are psychopaths
Yeah, sure. We all dabbled with DevOps, it’s nothing to be ashamed of. But did it make us better people? Did it really? Or did it just make us spend the best years of our lives, the most precious moments of our careers, pinging someone on Slack for miscategorizing a Jira ticket?
I’m not going to make a case against DevOps today: It’s fine. But one of the most insidious legacies of DevOps has become the incessant need to break down the silos — particularly without asking questions, such as:
- Who put this silo here?
- Could this silo potentially serve a purpose?
- And, critically, when I break this silo, what comes pouring out?
While “breaking down the silos” sounds good on paper, the major issue is that it goes against who we fundamentally are as people. Because you see we, as people, have limited cognitive energy with which to work.
Breaking down the breaking down
Every organization has silos, just as every organism eventually evolves into a crab. We should ask ourselves why: Do organizations naturally trend toward silos because they are, like the crab, an evolutionary perfect being?
No, of course not: Silos do have problems.
But they exist because they are, singularly, the most efficient method of getting things done within the framework of the human mind. The human mind wants to concentrate on tasks near and present. It wants to forget tasks distant and far.
And if the human mind is asked to consider all extraneous factors — to constantly heighten internal and external visibility to the point of hyper-vigilance — the human mind kernel dumps and you’re left debugging that which is left.
So, let’s ask ourselves first: Why do we break down silos?
Silos within an organization lead to separate teams working separately, sometimes at odds and sometimes in parallel. They create inefficiencies and redundancies, because people are not communicating between silos. They reduce collaboration and cooperation.
All these things are true. In common philosophy, the answer is to break these silos down. But this is an inherently destructive action: It’s disruptive and, importantly, it doesn’t ask itself whether there is a benefit to maintaining these silos.
To each a specialization
Silos are composed of departments and teams — individuals who are working closely together on a given task. Think about it this way: Your lungs breathe air and your kidneys filter your blood. Your lungs are very good at breathing air and your kidneys very good at filtering blood.
So why, then, do we insist that our kidneys should know everything about what our lungs are doing?
Experts will say that cross-training improves overall function, customer happiness, and ROI. But that really eliminates the human cost: The fact that there is a very real person on the other end of this, likely facing burnout, that needs to take time out of their day to shovel something that is probably useless to them into their brain.
For the most part, instinctive actions are protective actions. People build silos not maliciously but protectively: They do so because they need a safe and understood place in which to reside. They need a place where everything makes sense — a place in which they can concentrate on their goals and metrics and, hopefully, achieve them.
When naturally formed, silos are specialized repositories of knowledge and talent. These repositories become siloed because the individuals involved are concentrating on the internal goals that they believe will be most useful to them. And, ideally, somewhere in the body, there is a central nervous system keeping everything on task.
But now we’ve broken down all the silos and — oh look, we’re coughing up blood.
A system-wide breakdown
So, what are the consequences when we break down silos?
Understand: I’m not saying there aren’t appropriate ways to break down silos. The best DevOps experts improve productivity and ROI; that’s inarguable. But we all know that we can’t judge any broad strategy on the assumption of perfect implementation.
When silos are simply broken down and not rebuilt, it leads to a whole lot of noise. There are more meetings, standups, Slack channels, and action teams. Everyone must touch base all the time. Everyone is cross-functional: everyone owns a little part of something and everyone is named somewhere on every RACI chart.
And it isn’t healthy. It’s not healthy to be informed and consulted on every single initiative within an organization. This type of increased visibility actually leads to more people working on the same things in tandem — now, everyone has their idea of how something should be, and no one is truly considered the owner or the specialist.
Which brings me to perhaps my most critical point…
Dysfunctional silos are the result of poor leadership
Silos themselves aren’t a problem: Silos become a problem when communication breaks down between them. And breaking down silos without addressing leadership only causes a cascade of all-consuming chaos. Suddenly, every spoon is in every pot.
The onus should not be on every employee to be cross-functional — the onus should be on team leaders, managers, directors, and executives to understand their talent pool and to network between them. The protective spirit of the silo should be maintained, while leaders take on the additional cognitive burden of managing them as a whole and holistic system.
Silos can be unhealthy — but breaking down silos isn’t inherently healthy. Critically, we must always look to the human, look to nature, and ask ourselves whether the systems we are trying to implement are human enough.
