Three things you need to break down those company silos

Why soft skills matter in the drive to shared services

Agricultural silos in Paraguay

If you’re the guy tasked with breaking down silos, should you be breaking down the people who police those silos first? We explore how to de-mine your team ahead of your brownfield project.

I've worked with a number of companies, as both an employee and a contractor, since I started working in IT in the late 1980s. And of course some have been more fun and rewarding than others to work for … not to mention some being more frustrating than others.

Something common between all of the frustrating employers and clients has been when the place has operated as a collection of separate silos. If you're wondering what “a tall tower or pit on a farm used to store grain” (my Mac's dictionary definition of a silo) has to do with business, the answer is: not a lot – unless you're a farmer, I suppose. What does matter is the third of the three definitions in that same entry: “a system, process, department, etc. that operates in isolation from others”.

Basic company structure

Companies have structure: all but the smallest couldn't work without one. They're split into divisions, the divisions may be further split into departments, and so on. It's a necessary thing to do in order to preserve order.

Did you just read that last bit, nod to yourself, and then carry on to this next sentence? The gist of the sentence is largely right, but did you question any of the words? No, neither did I until I thought about it, but then it occurred to me that I wrote “split” twice in a single sentence. In hindsight I ought to have written “arranged”, or “organised”: why would a business with a common aim need to be “split” and work as separate silos at all?

You sometimes have to …

The title of this feature makes it pretty clear that we think a company operating in a silo mentality is a Bad Thing and that the structure needs to be sorted out. Before we get to how you do that, though, let's look at instances where a silo approach is absolutely essential to some things we do.

Take the information security function of your business. Can you let individual departments look after their security? Of course not, because they don't know how to and they won't do it anyway – particularly the sales function because given the choice of employing a security specialist (who costs money) or a salesperson (who does quite the opposite) the decision is a no-brainer. More important, though, the audit function of the security department absolutely must be independent of the other divisions, as no part of the company should be permitted to “mark its own homework”, so to speak, when it's audit time.

Let's have another quick example, which I'll come back to in more detail later: the publishing world in which the likes of The Register live. In any decent publisher there's a big metaphorical wall between the advertising sales people and those like me in the editorial team who write the words. And this is the way it has to be: if you're a tech writer like me and you're (say) writing a review of a product, you have to do so independently and not be influenced by the sales guys telling you: “Don't be too harsh, they spend a fortune with us”.

… but usually you don't

So we've established that sometimes businesses need to have components that are deliberately and forcefully separate. Generally speaking, though, a company will be most successful if its bits work together to some extent. This doesn't mean a complete, unstructured free-for-all, but it does mean erring on the side of being informative and co-operative and working with colleagues – even when they're not part of a department in which you have no influence.

Influence?

Influence is an interesting concept. How many times, when you've been idly browsing JobServe for that elusive role as Head of Sunbathing for a Caribbean beach bar conglomerate, have you seen “influencing” on the bullet list of desired skills and abilities?

If you're a manager you have direct, explicit influence on those who report to you. You can ask them to do things, or you can tell them to do things, and you're entitled (within reason) to expect them to do what you say.

But that's not the quality the employer's looking for – it's actually what you'll automatically have should you get the job (and it's not influence – it's authority). What they're looking for is the ability to influence people outside the bounds over which you have authority – to get people to work with you or for you in a common direction for the greater good, even (particularly) when they're not in your department.

You're in the ideal position

I chose an IT career in the 1980s because I found the technology interesting and I love to find out about new stuff. That I would become an engineer of some sort was inevitable given that it was my dad's profession, and IT was the field that fitted best. Thirty years on, though, the thing I enjoy most about being in IT is that I get to work with every part of the business, not just my own, every day of the working week.

I get to see what people are doing, they tell me what aspects of the systems my colleagues and I provide them with makes their life difficult, and I try to help some of them out. Over the years I've seen my share of instances where (say) two departments are paying third parties to do pretty much the same piece of software development, each oblivious of the fact that the other is doing it.

There are only three departments that really have the benefit of seeing across the entire company: IT, finance and HR; of the three, IT's the one best placed to help departments out either by innovation or by simply directing the right technology and people at the problem.

Three things you need

People with MBAs have written plenty of books about how to organise companies so they work best; by all means read them all, but you'll end up with a head full of conflicting ideas. In my experience there have been three main actions that have helped with breaking down the silo mentality in the organisations I've worked in and with.

1. Helping them understand the big picture I said a few paragraphs ago that I'd come back to an example of silos in the publishing world. Back in the late 1990s I worked on a technology weekly, and one of the advertisers was unhappy that we didn't give them much – if any – editorial coverage, despite a significant advertising spend. There was, of course, the firm separation between the advertising team and the editorial team, and it was essential that the editorial mob retained their independence and integrity rather than pandering to advertisers.

One of the vendors that advertised with us was upset that we never wrote about them, and were hinting that they would stop advertising if something didn't change. The advertising team was nervous about this, and although they didn't say it in so many words they were keen for the editorial team to be a bit more flexible about their independence.

So we invited the vendor in for a chat. Over coffee and biscuits we pointed out that our editorial independence would not change one iota, but what we did do was point out why we didn't write about them. (In short: they sent bazillions of press releases announcing trivial updates to individual minor components, and no one item was sufficiently important to justify a writeup).

Nothing actually changed operationally within our company, except that the advertising team gained some knowledge about how the editorial world worked and when vendors asked similar questions in future they'd come over and see if there was anything we could suggest. And because that particular vendor sent us better, more meaningful information more sparingly from that point on, they got a mention from time to time.

2. Identifying tasks that belong elsewhere I've already mentioned that in some cases it's necessary to have silos within a company. The main problem with silo operation is when a function is being carried out in a silo where it doesn't really belong.

So I've come across departments that have decided to use an Open Source office suite rather than the Microsoft one everyone else uses “because it's cheaper”. And a subsidiary company's finance department that stuck with a legacy accounting package because it felt that moving to the new system adopted across the group would be too involved.

In both these examples things soon changed. Not by table-banging, but by simple reasoning and communication.

In the Open Source example we spent some time with the team and demonstrated that they were spending about a person-day per week buggering about helping each other with “How do I ...” questions and translating documents between OpenOffice and Office formats so they could work with the other departments; we also pointed out that the software didn't come out of their budget anyway so they didn't need to worry about it.

They said “OK, we'll try Office then”, and never looked back. (Incidentally, I have no problem with Open Source – in fact I'm writing this with OpenOffice on my Mac; Office just happened to be the incumbent in this example).

In the finance system example we simply pointed to the project plan for the roll-out of the new system and showed them the facts of how long it had taken and what, if any, upheaval there had been at any stage. They were still concerned about how long their bit would take, so we shuffled around a few priorities and managed to trim about 20% off the schedule and put the things they wanted the most in the first couple of weeks.

In return for us doing that, they said they'd try the first couple of steps on the condition that we could roll back if they were unhappy. No surprise, they got so engrossed in using the first few bits to do stuff they'd never previously been able to do that we simply got on and finished the job – and the person who spent his entire day wrangling their legacy system to keep it limping along was able to go back to accounting.

3.Doing it well In my experience this is the most important of the three actions that help you break down silos. By all means work with departments to help them understand how their peers in other silos work, and by all means show people that in fact by having a common system across the company, or by working together, life can be made better.

But if you make a balls of it, you're screwed.




Biting the hand that feeds IT © 1998–2019