What To Do (And What Not to Do) When Breaking Down Silos

We’ve come a long way in the last couple hundred years. Humanity, that is. Our technological pace of change has been unprecedented, creating previously unfathomable strides in the standard of living. And we’ve done this directly because of the Industrial Revolution and labor specialization.

Now, labor specialization is as old as civilization itself. In fact, many historians would argue that specialization is a requirement for civilization. But the Industrial Revolution kicked it into an exponential growth cycle. How? Via automation.

Over the last 200 years, we’ve continually automated our simplest tasks. This, in turn, means that humans are constantly tackling more complex — -more specialized — -tasks. We’ve built global commercial empires on the back of this specialization. We capture economies of scale by creating complex systems.

There is, perhaps, no better illustration of this than the iconic assembly line. Thousands of people work on a big task, like assembling a car. Each individual has a highly specialized task at which he can become incredibly efficient. These tasks make no sense on their own. But when you combine them en masse, they become a symphony of industrial engineering, coming together improbably into a cost-minimizing gestalt.

This is the blueprint for the modern corporation. And it has a significant downside.

The Silo Problem

In the 21st century, a lot of work has moved out of the industrial realm and into the digital, knowledge-work economy. Sure, we still assemble cars. But we also “assemble” SaaS products and billion-dollar phone apps.

And as we’ve made this transition, we’ve carried familiar models with us. As companies scale, they assemble knowledge workers into intricate and complex systems, none of which makes sense alone. One guy does the database, while another gal writes the code that interacts with the database, and so on up and down the stack. It seems great in principle. But in practice, it creates a byzantine nightmare of bureaucracy.

Specifically, you wind up with organizational silos.

I’ve seen some impressive ones in my travels as a consultant. Companies slice their applications across vertical layers, forcing at least five teams to collaborate in order to achieve even the simplest feature. They create reporting structures where front-end developers and back-end developers share no common reporting role below the executive level. The paperwork, phase-exits, and hand-offs pile up to the point where overhead dwarfs actual work. Things become Dilbert-level inefficient. And, boy, do the knives come out then.

You have turf wars and a silo problem. Let’s look at how to fix it (and how not to).

Don’t: Start With a Blame Game

When organizations try to fix this issue, they usually start with leadership. This is, of course, necessary since addressing silos often means changing the org chart.

So picture it. You bring a group of department heads together and sit them down. You then proceed to tell them that they have a silo problem. What do you think happens next?

They start pointing fingers at each other. “Well, things would go a lot faster if the UX group would just stick to the schedule for producing wireframes.” The UX group counters that the app dev group doesn’t fill out the right CR forms. And things degenerate from there.

Instead: Take Inventory of Current State and Politics

Office politics are real and unavoidable. When you have organizational silos, any existing politics become amplified and often cast in stone.

So don’t pretend politics don’t exist. Instead, conduct separate interviews, listen to people’s concerns and ideas and assemble a holistic picture of the organization. This will tell you, in advance, where the fault lines and sore spots lie. This is powerful information.

When you do facilitate some kind of kick-off to address “the silo issue,” it won’t be some kind of fact-finding (finger-pointing) exercise. You’ll already have done this recon. Instead, you can introduce it in a non-blaming context that just treats it as a problem you’ll all be working to solve.

Don’t: Blow It All Up and Mash Everyone Together

Once you’ve sized up current state and informed relevant leadership, it’s time to formulate a remediation plan. You’ll be tempted to go big, dramatic, and scorched earth. You’ll be tempted to mash everyone together.

Resist this impulse. Silos are often a toxic and sub-optimal solution to a real problem. And that’s a problem of scale. With more than about 10 people, you can’t simply have everyone communicating willy-nilly with everyone else. You need structure and protocols to manage this.

If you just take a sledgehammer to everything, you’ll lose the silos, sure. But you’ll also lose the thing currently standing between you and bedlam.

Instead: Align Around Business Value

Leave the status quo alone until you have a solution you’re confident will work. And how do you make yourself confident that a solution will work? Run a representative experiment with a hand-picked pilot team.

Picking that team is no easy feat, and there are too many organizational specifics for me to offer a universal way to do it. So instead I’ll offer the heuristic that you should form the team around business value. Dysfunctional silos create a situation where individuals, and even whole teams, are so specialized that no one can autonomously do anything useful.

So fix that. Build a team that can do something useful on its own — -something with business value. For instance, if you’ve historically had an app dev team, a deployment team, and an operations outfit, embrace the DevOps movement and create a team that can handle all those concerns autonomously.

Don’t: Create Elaborate Matrix Structures

Here’s something that you see a lot: an organization has historically had silos, so they run an experiment. They give everyone eight different bosses, Bob.

Take the aforementioned hypothetical silos around development, deployment, and operations. They’ll assign each dev a “deployment manager” and an “operations manager.” Then, when those groups need to coordinate, the alternate manager assigns the developer some work. Of course, this includes coordinating with his development manager and his deployment manager.

This winds up not being any better, in terms of bureaucracy, than the silo approach. Sure, you no longer have the stovepipe, information-hoarding problems that accompany silos. But now you have the logistical nightmare of every individual contributor juggling many competing priorities.

Don’t trade one kind of complexity nightmare for another.

Instead: Favor a Cross-Functional Approach

I mentioned a moment ago that you should build teams that can operate autonomously. Well, to counteract the impulse to complect the organization structure with matrices, we’ll build on that theme.

You want teams that can autonomously deliver business value. To empower them to do that, you need to encourage them to be “T-shaped,” or cross-functional. Sure, they’ll have specialties, but these teams don’t mimic the assembly line and do only those tasks. They pitch in where needed. A software developer specializing in database access codes might pitch in to help with client-side concerns or even QA/project management if need be.

From a management perspective, these teams have a single boss, a charter, and the autonomy to get things done. Leadership handles external communication management and priorities while the team operates kind of like a startup, doing whatever needs doing to deliver value.

Don’t: Roll Things Down Through the Organization by Fiat

Once you’ve created a prototype or figured out a good division of business value, there’s a natural temptation to convene an all-hands meeting and announce the organizational shakeup. That’s perfectly natural, but people get comfortable in their routines, and old political loyalties and fault lines die hard.

Do this, and you may wind up with a bunch of cross-functional teams full of people that resent and blame one another. You may wind up with mid-level management more interested in claiming new turf than helping the organization succeed.

You need to involve everyone in the realignment, and you need to do it in a way that they believe in.

Instead: Create a Thematic Goal

I’ll close this post by suggesting that you read Patrick Lencioni’s excellent business fable about silos and how to fix them. In it, he introduces the idea of a thematic goal.

Here’s the gist. When organizations face an existential crisis — -a possible closing of the doors, for instance — -people tend to forget about silos and turf and come together in an “us against the world” fashion. A thematic goal is an idea of manufacturing that kind of urgency by making sure that the entire organization is always marching toward some goal common to everyone.

So when you roll out the plan for the silo-busting reorg, don’t make it some kind of dry pronouncement that you’re shaking things up. Instead, talk about how the organization faces a critical juncture in its life and it needs everyone in the building. Toward that end, you’re asking for their help with the reorg. You’re telling every one of them that they can make a material difference in helping the company reach that goal.

At the end of the day, silos are about bureaucracy, but they’re also about politics and turf. To get rid of them, you need to get rid of the bureaucracy, yes. But you also need to redraw the turf lines to be productive instead of toxic.

Originally published at https://aspetraining.com/resources/blog/breaking-down-silos.