How Functional Silos Can Damage Your Company

We’re a small company and Pete officially handles customer support calls. A few minutes ago the phone rang but Pete had just stepped out to grab a coffee. Nobody reacted. When we get voicemail in the support inbox, the ‘beep’ is audible throughout the office since we’re in an open concept office.

The phone rang again. Again nobody reacted so I grabbed it figuring that the odds are a client is having a serious problem. My spidey sense was right. I didn’t know exactly what to do but I’ve done customer support before so I gathered some data and asked somebody else in the office to help me. Client issue resolved.

Why is it that nobody reacted? Well, I will assume that people don’t think it’s their job to answer the support phone. Again, it’s not that people are bad and feel that “hey, it’s not my job”, it’s probably the result of the desire to have functional silos. After all, if we’re all responsible for everything, that means nobody is responsible. From my experience, that’s typically the argument people have against Agile and general specialists.

That’s a load of bull.

Generalizing specialists and a team commitment to excellence is a world apart from the airy-fairy “hey, we’re all in this together!” stuff. So how can functional silos damage your business? Well, let’s suppose I don’t answer that call. The client calls back. And then again. And again. Then the client calls the sales person who sold them the solution. She tells her boss who tells the CEO who marches over to the CTO and comes down on him.

What’s likely to happen? Pete gets in trouble. The process gets tweaked for whatever reason and a whole lotta blame gets tossed around. Who’s fault is it? Pete for not being at his desk every second for the whole day? The CTO for not having enough “process governance” or documentation? The customer for over-reacting? The sales person for escalating the call?

The effects are systemic. That means when your organization has, and encourages, functional silos you get what you design. You have set the expectation that Pete is responsible for support. You have set the expectation that process and individual responsibility is more important than organizational goals, whether it be implicit or not. Who am I referring to as “You”? I don’t know. Leaders and executives organize companies based on what they know. Their entire career they’ve been taught, trained and have experienced how organizational structures are created, how to make process, how to dangle the carrot and how to wield the stick. They too make decisions that are a result of systemic effects.

The solution is pretty simple. Hierarchy and organizational structure don’t matter. No way, shape or form do they matter. Let me repeat that to everyone who, in the heads, said “this guys has no idea what he’s talking about, if you don’t have well defined responsibility, you have chaos!” (or some variation on that). Create your organization to support the work you are doing. This means the more you apply the concept of ‘generalizing specialists‘, the better your chance at being a great company.

Understand the work your company does and understand the impact functional silos and process have on how your employees behave. Don’t simply create a structure because that’s the way everybody else does it. As soon as your focus shifts to hierarchy, titles and how to create responsibility though silos, you’ve created the work system and you need to live with those impacts.

Lisa Crispin

+1 on all that! In addition, it’s critical for the software team to learn the business, and you can’t do that by never venturing out of your team’s area. Our team has invested time in learning all aspects of the business. So not only do we help with production support, the business folks seek our input into priorities and business decisions. For me that makes our work even more fun & satisfying.

Great post! In your example above, what if there weren’t enough customer support calls to keep Pete busy for 8 hours a day? Then you have Pete getting bored and becoming mayor of Farmville while the rest of the team not doing customer support is getting burnt out. In addition to bored and burnt out employees, the company is wasting money and time.

That’s cool! That would make a great topic for a blog. I’d be interested to see how you went about creating that type of culture. I struggle with trying to influence managers with the value of letting people ‘see what its like on the other side’.

exactly! That scenario really creates a vicious circle of wanting to make sure everyone is busy instead of focusing on what’s important. Poor Pete will get more process dumped on him and if he’s not busy all the time, he’ll have to make it look like he’s busy just so his manager doesn’t think he’s not doing any work.

Amy Thorne

First, let me say that I completely agree with you.

Another reason organizations have functional silos, though, is to help reduce the variability of what each person is doing in hopes of gaining predictability.

For example, say you or the person who helped you were working on something you were scheduled to complete that day and you didn’t complete it because you spent time on support. Maybe you were working on a feature that some other client really wanted, and now they have to wait an extra day for it, because you were too busy supporting another client to finish it.

That’s one of the issues functional silos may be trying to address.

Again, I’m definitely not saying silos are good, just that sometimes the issue may not only be about wanting to assign responsibility, but about trying to force predictability.