Pick One, and then Own It.

  • July 3, 2013
  • Scott

I don’t know if Neil read Horace Dediu’s post on the Praetorian Guard before writing his own post defending silos, but the two pieces of work go nicely together.  Silos – good or bad?

First, Horace lays out a great case against silos – and *for* organizing in a functional manner rather than a divisional manner.  What does this mean?  It means in some companies, all hardware engineering is in one group, all consulting in another, all software engineering in a third, all design in a fourth, all sales in a fifth, etc.  Each function typically reports up to the COO or CEO.  In a divisional manner, each division has a bit of each, whatever is needed to fulfill their P&L and market mission.

Horace points out that functional organizations can disrupt and innovate:

My hypothesis is that in the absence of product/divisional level power bases, the threat is not felt and the political power to respond is not available. In a functional organization there is no “business leadership”, where the P/L “belongs” to one person. Only the CEO has life-and-death power over products and their decision is “purchased” through discussion with functional heads who stand to benefit as much as to lose from disruptive change.

I like his thought process.  He goes on to say that this is almost universal in small companies, and quite atypical in large companies (Apple being a notable exception).  And the challenge is that functional organizations are harder to scale (at least in theory).  He points out that military organizations are one type that seems to organize and preserve functionally.  However, they’re hardly known for their innovation, so perhaps the thesis needs some work.

The chief danger to the functional org, he points out, is the creation of an elite division:

And so it must be for the functional organization. The emergence of an elite which, by its skill and achievement, gains more responsibility and hence more power is the good intention which paves the road to hell. Leading an innovative organization means having a process of denying power to those who are elites. It means preempting the Praetorian Guards.

Interestingly the US military seems to have avoided these pitfalls.  The Secret Service does not, by and large, compete for dollars with the military, nor is it part of the military.  The Navy Seals do not protect political figures, for example, and (so far) haven’t upset the balance of power in the military.

But I think Horace’s point is that if you want to grow your organization at scale with functionally aligned units, it will take a maniacal focus to both prevent offshoot divisions to target new product areas, and to prevent elite “Praetorian” forces from being put together that compete for resources with the main group.

Meanwhile, Neil was writing a post that seems a bit related – praising the silo.  He’s been hearing a lot of people talking about “destroying silos” in conferences around North America and probably can’t help but wonder if the cacophony of “destroy” is so loud, if some of the people saying it might be missing something.

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.

I think Neil is basically correct – the silo isn’t necessarily good or bad objectively, it depends on what your goals and context are.  If you’re aim is to disrupt industry, or to foster innovation, then in many cases silo divisions will interfere with that goal (though not always).  If you’re goal is to quickly scale a new business with minimum oversight, divisions (silos) that focus on that new business make sense.

BPM practitioners tend to focus on “removing” or destroying barriers to collaboration – often these look like silos.  But BPM itself is the enabler of cross-divisional, cross-department collaboration in service of a customer.  Even functional organizations can have these barriers.  A functional org responding to a support request may need to dispatch a consulting team to help – though support reports into Engineering, for example.  BPM often boils down to a method for identifying and codifying some of this cross-silo interaction to improve overall customer service.  We typically don’t have to destroy anything – but we have to persuade and enable the organization to collaborate – and then institutionalize that collaboration.

My take: pick your poison.  When you’ve picked the organization style, then you know what behaviors it will naturally reinforce, and what behaviors it will naturally impede – and it is up to you to create the culture and environment to compensate for weaknesses and leverage strengths.  Neither form of organization works well in a vacuum of leadership.


Related Posts
  • February 14, 2018
  • Ariana

Migration from BP3 on Vimeo. Director of BPLabs, Rico DiMarzio, details BP3's history with migrations and...

  • February 7, 2018
  • Ariana

Process Transformation and Artificial Intelligence from BP3 on Vimeo. Where does artificial intelligence ...

  • January 4, 2018
  • Scott

If you were wondering whether microservices architecture was coming for BPM engines, this post makes it pretty...

  • Craig J Willis

    Hi Scott, thanks for bringing hese two posts together. I’d agree with your position, I would typically highlight the challenges of a silo’ed organization but do not seek, as you say, to destroy them. Process can be used to optimize many of those challenges by breaking down many of the barriers that naturally start to occur in a silo’ed system.

    Recently I have started to move away from generic BPM and begun to specialize in agile development processes. Here I have seen that while agile teams, being cross-functional, are indeed agile there appears to be a development ceiling that certain individuals in the teams hit. I’ll take designer as an example, in some agile teams a single designer is required, that designer works well with the rest of the development team but does not get to spend much time working with other designers. For a less experienced designer this can be detrimental to their own development as they don’t get regular interaction with more experienced peers. Whereas in a design team/department they interact with peers daily.

    Of course this is very general but it’s indicative of the fact the situation is not black and white.

    • there’s definitely benefit to cross-functional organizations (and studies, and collaboration). But, as you say, a designer (especially a young designer) who doesn’t work with other designers will not learn and develop as fast.

      Also, in cross-functional organizations led by salespeople, sales activities and skills tend to be disproportionately recognized – and so you see technical people pick up sales skills or de-emphasize their own technical professional development. More broadly, the team tends to reflect the leader – and the leader’s values. And as a result, specialization can suffer.

      Good perspective, thanks for sharing, Craig!

  • Noe Banda

    “But BPM itself is the enabler of cross-divisional, cross-department collaboration in service of a customer.” – well put!