We hear this phrase constantly: “I worked at breaking down silos.” “We need to break down silos.” “What did I do in my last role? I broke down silos.”
It sets my fucking teeth on edge.
What is a ‘silo’, anyway? What specifically wasn’t working well, and how did you solve it; or how was it solved, and what was your contribution to the solution? did you just follow orders, or did you personally diagnose the problem, or did some of your suggestions pan out?
Solutions to complex problems rarely work on the first go, so … what else did you try? How did you know it wasn’t working, how did you know when to abandon earlier ideas? It’s fiendishly hard to know whether you’ve given a solution enough time to bake, for people to adjust, so that you can even evaluate whether it works better or worse off than before.
Communication is not magic pixie dust
Breaking down silos is supposed to be about increasing communication, removing barriers and roadblocks to collaboration.
But you can’t just blindly throw “more communication” at your teams. Too much communication can be just as much of a problem and a
burden as too little. It can distract, and confuse, and create little eddies of information that is incorrect or harmful.
The quantity of the communication isn’t the issue, so much as the quality. Who is talking to whom, and when, and why? How does information flow throughout your company? Who gets left out? Whose input is sought, and when, and why? How can any given individual figure out who to talk to about any given responsibility?
When someone says they are “breaking down silos”, whether in an interview, a panel, or casual conversation, it tells me jack shit about what they actually did.
cliches are a substitute for critical thinking
It’s just like when people say “it’s a culture problem”, or “fix your culture”, or “everything is about people”. These phrases tell me nothing except that the speaker has gone to a lot of conferences and wants to to sound cool.
If someone says “breaking down silos”, it immediately generates a zillion questions in my mind. I’m curious, because these problems are genuinely hard and people who solve them are incredibly rare.
Unfortunately, the people who use these phrases are almost never the ones who are out there in the muck and grind, struggling to solve real problems.
When asked, people who have done the hard labor of building better organizations with healthy communication flows, less inefficiency, and alignment around a single mission — people who have gotten all the people rowing in the same direction — tend to talk about the work.
People who haven’t, say they were “breaking down silos.”
I am still learning this lesson the hard way.
What I have learned in the last few years is that silos will always exist as long as things are in separate org structures which will have to exist to scale the people management side of things. Just telling leadership that silos don’t work and even presenting some sort of communication plan at least for me didn’t work. What does seems to work is getting operations team to use the same high level development process for project and tool development work as our product development colleagues. Stakeholders like product managers and dev managers understand how a business need becomes a feature in production. The operations team needs the same shield the product teams have which is their roadmap and the development process to set expectations.
The other part that has seemed to work is instead of telling a development team you need them to deploy their service or datastore using best practices the ops engineers define, just create the automation for them. It is easy for a development team to ignore your confluence/documentation page of best practices. However, a tool that integrates automatically into their existing deployment workflow/pipeline is much harder to ignore. Then the developers who don’t agree with you have to explain to their leadership why the extra man hours to provide their own solution they then have to support is worth it.
Be a development accelerator and not a gate.
I love that. Be an accelerator, not a gate!
Love it!
Minor typo: “These phrases tell me nothing except that the speaker has gone to a lot of conferences and wants to to sound cool.”