A Halloween Post About De-Siloing All the Things: “Be Not Afraid, Be Very Not Afraid”

Happy Halloween!

In this post we are talking about breaking through silos; a topic that can be scary for some, but I am here to tell you that you have nothing to fear. Call it an anti-Halloween post.

My disclaimer here that true Silo-busting means that everyone is truly part of the same team. No “throwing things over the wall” and so on. De-siloing, at the deepest level, is a huge organizational change and doesn’t usually happen overnight. Here, I will be talking about silos that do exist, perceived or otherwise. Therefore, this post can apply to most situations.

Scary Things People Say

Let’s start with a few sayings that are legitimately scary, like:

“I am sorry sir, we are all out of gin.” . . . That is a nightmare scenario.

Or, my engineering pet peeve phrase: “We do it that way because that’s the way we’ve always done it.” This one shuts my brain down entirely for a few minutes.

But there is a saying in our line of work that shouldn’t scare you because it is easily remedied. It goes like this:

“Once you know about a thing, and people know you know about the thing, you are now responsible for the thing.”

I have noticed some PTSD from some of my peers over this, and it makes them afraid to break through silos as a result. They are deathly afraid that if they break through a silo, they will have ever-increasing responsibilities they don’t want.

This happens either because:

1. Weak Leadership. Or,
2. They don’t know how to say no define expectations while engaging with another team.

Properly done, breaking through a silo, perceived or otherwise, will lead to better engineering all around, and forgive me for the painfully obvious statement, but it needs to be said out loud:

What you do is interconnected with what other people do whether you like it or not, sometimes quite literally.

And, in fact, I will go one further and say that breaking through a silo, in the long run, actually means less work because if you break “their thing” out of fear of talking to “them” about “their thing”, it is orders of magnitude harder and more work to fix “a thing” after launch than it would be to simply “integrate all the things” properly in the first place. Not to mention, fixing “that thing” pulls you away from developing “new things”.

My Personal Struggle with Silos

I wish I could say that I am immune from this fear, but I am not. I have struggled with my own fears on this one. It’s hard to be the first zebra that jumps into the crocodile-infested waters. I have heard this flak more than a few times:

“Make sure when you talk to that team they are made aware that we won’t do X or Y for them.”

I get it. Boundaries.

But, it’s not about doing more, it’s about knowing more, and using that knowledge to work together to ensure everything plays nice. We’re breaking down information silos.

Differentiating Silos: Information vs. Responsibility

If you remember anything from this post, remember this very important point:

Information silos and responsibility silos are two different things.

. . . And, they are easily defined and/or enforced, assuming you have good leadership and are willing to define boundaries. Dealing with poor leaders is another blog post altogether. . . .

When you engage with another team about their thing, you’re looking to do information sharing, not responsibility sharing. State your intentions up front. You can even be blunt about it: “We are doing ‘this thing’ and I want to make sure it doesn’t break ‘your thing’. Let’s work together on it.”

90% of the teams I have ever worked with have always embraced this.

The more you know about other people’s systems the better; not just for engineering and design, but also for troubleshooting. It’s a win-win.

How to Break Through

Here’s what works for me, but YMMV:

1. Before engaging, have a list of defined engineering-specific questions or concerns about what you’re doing and how it might relate to “their thing”. What is it that you want to do? What engineering implications might it have for their team that you may not know?
2. Meet with that team and start saying words.

You’re welcome.

I can also tell you what not to do.

1. Don’t be a dick.
2. And related to that, encourage a no-blame culture.
3. With very few exceptions, politely, do not let them give you credentials to “their thing”. This is “saying no”. Organize a meeting so they can show you what you need to know. Don’t let them get away with the ‘ol, “I don’t have time. I’ll get you a login so you can see for yourself.” I have literally told people not to give me a login and forced them to spend time with me.

And by the way, of course, breaking through silos is a two-way street. You should be more than happy to share information. Everyone has a vested interest in ensuring information is shared to create properly integrated systems.

What Happens if They Don’t Engage?

People can refuse to engage for numerous reasons:

1. People can be territorial. They are afraid you want to take over their responsibilities.
2. People may think you are going to criticize their work.
3. They have been instructed not to share information by their peers or by their management: The Overtly Enforced Silo from Within! OOOoohhhhhh scccaaaaaaaaaarrrrrryyyy!

The best you can do with these scenarios is use people skills. You may have to be blunt and literally state your intentions. Sometimes you may have to build a rapport with members of the team. Being humble also goes a long way.

If they still don’t engage, it’s time for the, “CYA Email” where you spell out what you are doing as a last ditch effort. Be specific. List out your questions and concerns. At the very least you have it on record for future reference.

Over the long haul, it may also take some persistence. Keep doing it.

Screw the haters.

Hit me up on twitter @RussianLitGuy or email me at bryansullins@thinkingoutcloud.org. I would love to hear from you.