Pick One, and then Own It.
- July 3, 2013
- 4 Comments
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.