Three things you need to break down those company silos

Why soft skills matter in the drive to shared services


You wanna let us do that for you?

There's one over-riding reason that people in silos start doing stuff that doesn't really belong with them: they see it as the only way to do it effectively.

If you start seeing servers appearing under people's desks it usually means they don't trust the IT department to look after their data, or perhaps that the IT department has said: “We don't have the capacity or the budget, so it'll have to wait until the next financial year”.

If you see departments going out and getting their own mobile phones and contracts rather than using the corporate arrangement it's usually because whoever handles it centrally hasn't delivered on their request.

So if you want to break down the silo mentality and get a service back where it should be, the best way is to go to them with hand on heart and head held high and truthfully tell them: “Why not let us do that for you – we can do it better/cheaper/faster”.

Let's face it, salespeople don't want to have to manage servers, and finance people don't want to support finance software: they'd prefer it to be done by someone else so they can get on with their day jobs.

But if you get a reputation for saying: “That belongs with me, let me take it away” and two months later it's a technological train wreck, you're doomed for evermore. If, on the other hand, you take something on and make it better, faster and more stable, you'll have the other silos queueing at your door offering you their services to manage too.

Taking the concept a step further, it's sometimes not actually you that has to do the job well. I alluded earlier to the idea of two departments paying third parties to do largely the same software development task.

As the person who sees this duplicated effort going on you're in an ideal position to do something about it, but that doesn't mean you have to take it on; the best solution might be for one of the departments to carry on and for the other to plug into their project. But to do so, the latter department needs to be confident that it will be done right, otherwise they'll shy away from the risk of failing.

Support from the top

I once asked a corporate leadership specialist how to deal with instances where I need to get people in other departments to do things despite having no real authority over them. I took his answer (exploit your personal relationships – if you've scratched enough people's backs over time, they'll feel obliged to scratch yours once in a while) to heart, and he wasn't wrong.

There does come a time, though, when you do need good old-fashioned edicts from upper management. Engendering and exploiting personal relationships is hugely rewarding in the long run, but it takes time. Sometimes you just don't have that time, and quite frankly you need a certain level of imposed structure if you're to get anywhere.

A policy that governs what technology may be used, and how it may be connected, and the ways in which it may be used, is worth its weight in gold. It saves person-months per year in the average organisation because running corporate-wide standards makes it easy to run vast hunks of technology with minimal effort.

You're running a company, not a democracy, and there's no more reason for the sales team to have a different brand of computer from the marketing team than there is for each team to work in a different currency. The only way to make it work, though, is to have complete buy-in from senior management: if you don't, exceptions will start to be made (usually for the sales team whining on with some bollocks that if they have to conform to the standard it'll affect the company's profits).

Just one thing, though: you've got to be able to support the policy. A policy that's impossible to actually deliver against will actively damage the company.

In short

Although this feature is ostensibly about breaking down silos, in fact this isn't always either possible or desirable. What you do need to do, though, is ensure that:

  • Where silos exist they're doing the stuff that necessarily belongs in them.
  • There's sufficient communication between the silos (either directly or via departments like finance and IT which frequently interact with all of them).
  • Where silos are stepping outside their sensible scope you make that stop by ensuring that the proper department does the stuff they shouldn't be doing – but justifies this desire by making a bloody good job of it.

Use your influence and personal relationships to get over to people the reasons why you think changing the approach will work better – after all you have no authority over them so influence is the best tool you have to hand.

And govern the overall rules and processes of the company with policies that have the full support of, and are enforced where necessary by, senior management. And that the departments whose job it is to do work that would otherwise sit wrongly in the silos do a good job.

Which brings me to a final thought for you to take away.

If you've engineered the corporate policy and the structure to do it right, and you've moved everything to the right place, but then you provide a service that doesn't make the company work any better, the next thing you need to do is hand in your notice. And if you don't, your boss needs to fire you.

Because moving stuff out of silos into shared services introduces single points of failure. If three silos are doing the same thing and one of them cocks it up, they've only got themselves to blame and they've only broken part of the world. If you go on a crusade to eradicate inefficiency and then you balls it up, you've probably broken big chunks of the company.

So before you go changing anything, make sure you're not changing it for the worse. ®

Dave Cartwright is the IT Operations Manager at JT Group Limited.


Other stories you might like

Biting the hand that feeds IT © 1998–2022