Silos: Integrate or dissolve?

When you make the design fit the work, not forcing work to fit the design, the results are profound, writes John Cooney.

Ask anyone to give you a picture of how their organisation works and chances are you’ll get an organisation chart. This will show different technical functions separated at executive level and the organisation grouped accordingly, cascading from that initial separation. 

Despite ensuring the scourge of silos, rather than question functional design, organisations are increasingly focusing energy and resource on integration, urging the silos to hold hands. 

Instead is there benefit in challenging functions, rethinking design to dissolve silos?

Firstly, let’s reflect on where functional design came from. Frederick Taylor, in the 19th Century, promoted division of labour to “white collar as well as blue collar work”. While many of Taylor’s ideas no longer have currency, functional management has remained unchallenged. We might have designed structures that are flatter, upside down, as a matrix or in divisions but they remain more-or-less functional.

As work apparently becomes increasingly complex, demand for technical specialism increases and these expensive people need to be made use of. Efficiency seems easier to achieve in functional teams where backup is available and expertise passed down the line as required.

Once organised in functions, then budgets, targets and accountabilities follow. These reinforce silos as people protect their patch to make their numbers. 

Now we have multiple parts of the operation acting more or less independently, responding to customers who most often need input from many, if not all, parts to gain what they need.

To control this potential chaos, operations specify what they are able to deliver. This drives the need to manage customer expectations and provide consistent, controllable services we can stand by.

So functional design drives standardisation of service, and this is seldom questioned. 

The impact becomes visible when customers call seeking a variation. If an agent attempts to provide it, fearing budget overruns management resistance builds and “if we do it for one we’ll have to do it for all” alarms ring.

Underpinning assumptions remain unchallenged despite evidence they are unhelpful. The evidence is the large volume of unnecessary demand from customers. The greater the standardisation in service environments the more the customers will push back. Unwelcome failure demand will be the consequence. “When will it arrive?” “I asked for a red one, you sent a blue one.” 

(Failure demand is a term coined by John Seddon of Vanguard Consulting (UK) to refer to demand that results from a failure to do something or do something right for the customer.) 

Failure demand is on average two thirds of all demand. It’s a vast and expensive call on a business’ resources, sucked into the vortex of dealing with dissatisfied and unhappy customers.

Here’s the point. This happens by design. The pain organisations and customers feel is the predictable consequence of standardised offerings and processes and functional design of work.

An alternative is to design against value. To do this, answer four questions.

1. What is value in our system?

2. How well do we currently deliver this value?

3. What stops us delivering value?

4. How can we design ourselves to only deliver value?

These questions will help move from the current functional design to a value-based one.

Firstly, value varies system to system. Using the example of the most common, demand-based systems, value is determined by the customer. 

It is the demand from customers that isn’t a consequence of our unhelpful actions or inaction. Let’s call that value demand and the work necessary to deliver that value demand, let’s call value work.

The second step is to make visible how well value work is delivered. A useful first measure is failure demand as a proportion of all demand. For an average workplace we know for every value demand we generate two failure demands. 

Other useful measures of value might include the performance in meeting what matters to customers, and waste in the flow. The first shows the cause of failure demand and the second shows the result of years of reacting to it, well-intended ideas with unintended consequences.

Next, building an understanding of what causes us to be distracted from delivering value will make clear what has to be given up for performance to improve.

These are the design features and assumptions that cause performance problems: targets pushing people to rush through customer conversations, standardised customer journeys aimed at controlling responses and cost, functional design of work groups and budgets that ensure workers priority is to make budget numbers.

Once the first three steps are in place, the case for change is clear. Work, roles and structure can be built empirically against value. 

The question to ask for every action being considered is “does it create value for customers?” If not, then don’t do it.

The role of leadership becomes: act on the system, cutting out things that hinder value creation and replacing them with things that support it. 

When you make the design fit the work, not forcing work to fit the design, the results are profound. 

Even spending twice the time on getting things right for the customer will reduce costs by a third if failure demand is average. Experience shows that after a period of transition this extra time isn’t required, liberating more savings. Meanwhile enhanced service drives up revenue. 

The case is compelling. However it will be at odds with most, if not all, familiar structures, strategies and priorities developed within organisations designed around separate units, each with their own budgets and performance indicators. 

Deming ruefully stated, “it is not necessary to change, survival isn’t mandatory”. Neither is redesign against value. However, working to integrate silos when functionally designed rather than dissolve them, guarantees plenty of avoidable pain for customers, workers and managers.    


John Cooney has history as a CEO, mostly learning what not to do for 20 years. He now helps leaders design and change whole systems to meet purpose. 

Visited 5 times, 1 visit(s) today
Close Search Window