blog

In praise of the silo

Neil Ward-Dutton

Friday, June 28, 2013 by

Every organisational feature – including silos – is an outcome of some kind of optimisation. By talking about trying to destroy silos, we’re denying the sometimes very rational reasons behind their creation.

I’ve been travelling to conferences throughout North America and Europe a fair bit over the past quarter, and I’ve seen a lot of people present about business transformation, business architecture and BPM initiatives. One thing I’ve heard presenters talk about in a reasonable number of sessions (I estimate somewhere around 30%) is the need to ‘destroy silos’.

I have a background in architecture and integration, and for a long time I used to think the same. Silos are bad. Silos beget duplication; wheel-reinvention; contradiction; waste. Silos are really bad.

Except…

It turns out that ‘bad’ here really depends on your point of view. Silos aren’t actually ‘bad’, or ‘good’ for that matter. They’re optimisations – just as everything that every organisational, social or technical feature is an optimisation that serves one purpose or other. Silos are what happens when you optimise part of a business for expediency.

Is expediency bad? The default position of some system and enterprise architects appears to be that it is – but it’s not undesirable if, as a board member, you need to execute on a strategy that hinges on mergers and acquisitions; or if you want to enter a new market quickly, create a new product line quickly, or do something else quickly.

A certain kind of silo is also a natural emergent feature of any organisation or society. Birds of a feather flock together! People with similar skills, backgrounds and interests are easier for HR to appraise and develop if they interact with each other; and also if they’re compared to one another. Even in a business that’s moved a long way beyond the teachings of Adam Smith, silos are resilient things for many reasons.

Silos aren’t bad, and silos can’t be destroyed – or at best, trying to destroy  them in any kind of dynamic business environment will resemble some kind of organisational change version of whack-a-mole.

Don’t get me wrong: silos can and should be understood, justified, and where possible bridged. Creating a business that truly serve your customer demands that you do this. But bridging is about building, not destroying.

Am I off base here? Are silos in fact always things to be destroyed? I’d love to hear your thoughts!

Posted in General, Process

7 Responses to In praise of the silo

  1. Absolutely not, you’re spot on. I liken silos and vertical apps to database normalization. Yes, we can go to fifth normal form, but honestly how often do we need to do that? And, in fact, often times we’ll only go to third normal form for purposes of speed and performance. Silos are the same way and again, as always, the question is “What do you want or need to do?” and sometimes… a silo is perfectly adequate to the task at hand. Tools and widgets and all that.

    Good write-up Neil.

    Cheers, Pat

  2. I think you are spot on. We are about 1 year into our enterprise social networking endeavors and although we aim at increasing transparency it is quite obvious that we – in some ways – are creating a different kind of silos now.

    A very appropriate quote springs to mind (I can’t take credit for it, but I also don’t remember where I heard it):

    “One man’s silo is another man’s focused team”

    In many ways this captures the essence of silos. They are not all bad but if you bury your head in ‘the silo’ failing to communicate and otherwise be aware of the surroundings, then the silo goes from being an optimisation to a suboptimisation and that is a problem.

    • Neil Ward-Dutton says:

      Martin, I think you raise a really good point about the importance of awareness of context from within silos. Ultimately this awareness can come from the ‘top down’, if you have enlightened leadership – but often this doesn’t happen because those at the top don’t see the problem.

  3. Neil,

    Who is first exposed to the philosophy of BPM, or anyone that have experience in this field of knowledge, ultimately conclude that one of the main advantages is to end organizational silos since the real “end-to-end” processes travel across multiple organizational units and break the logic of existing hierarchy.

    However, there is another challenge that is how processes are designed to achieve such a rigidity that cannot be sparked from the middle of nowhere different processes from which are being executed.

    Imagine you are running a complain handling process and although the customer is dissatisfied with the quality of service delivered, during the conversation it can ask for information and a commercial proposal about a product / service. In this circumstance, it’s possible to combine the complaint with a business opportunity, and minimize the impact of the claim with a better offer. This means having the ability to initiate another process quickly without forwarding emails where there is a risk of being lost without passing calls and ensure that all related content is added in order to contextualize the person who will make the offer to be aware that this request is coming from a complaint. Otherwise you can experience a silo process effect. Some days latter if the customer is still linked with your enterprise is going to call back as ask for the offer no one took care and knows about it, or worse, the customer is already disconnected and is contributing to increase churn rate.

    Hence, after breaking the silo effect is necessary to break the process silo effect but still to break the silos much more culture orientation is needed that design.

    Best

    Alberto.

    • Neil Ward-Dutton says:

      I completely agree with you Alberto – it’s necessary to co-ordinate information sharing and work across groupings of people and systems where those groupings are primarily organised to ‘share internally’. Your example is a very clear one.
      My point is really that silos aren’t necessarily good or bad, they just ‘are’ – it makes no sense to try and engineer organisations that don’t have silos, or to destroy those that are there. You have to work with what you have.

  4. A key takeaway from this for me, is that regardless of what you picked, you can understand the inherent strengths and weaknesses and manage accordingly. Don’t pretend the issues aren’t there, just deal with them. (Not unlike picking a comp plan – whichever one you pick, can work, but each one will require different reinforcement from management and team)

Leave a comment: