How to play transformation twister

This article explores the forces of centralisation and decentralisation acting on a transforming organisation.

In Maverick, Ricardo Semler described his unorthodox transformation philosophy when turning round the family's marine manufacturing business, Semco. Out went conventional wisdom around centralised functional specialisms like procurement and HR and in came cell structure design, decentralised factory committees, self-organisation and holding bosses to account with regular 180 degree feedback. It could be seen as the Teal organization of its time and probably laid the foundation for companies like China's Haier with their management model of Rendanheyi (人单合一in Chinese, translated as ‘Maker-Customer Integration’).

"The key to management is to get rid of the managers"--Ricardo Semler.

Post transformation, the independent cells of Ricardo's Brazilian industrial conglomerate proved the superiority of the decentralised model, enhancing productivity while reducing costs (against the assumptions of orthodoxy) and importantly driving up employee satisfaction and innovation.

Now as well as being a visionary, Ricardo was the boss, probably co-owner of the company his father founded and utterly ruthless: he sacked the majority of his father's management team in a bloodbath on one fateful day, telling them to clear their desks immediately and never return. This mass butchering is rarer in a corporate environment where even a fully empowered CEO must balance forces of transformation and conservation (the new does not displace the old instantly or in every circumstance), build alliances and work with what they have alongside what they might imagine for the future.

Many companies going through digital and Agile transformation--and even the transformation to Cloud, DevOps, Artificial Intelligence-driven automation--are hitting the same problem: fundamental incompatibilities between centralised and decentralised models of doing work. It is interesting to see the chaotic way these transformations play out.

Often organisations tie themselves in knots like the proverbial game of twister, only without the retro 1970's knitwear and certainly without the smiles. Why is this so? In many cases it comes down to differences in foundational and often unstated assumptions related to the nature of work itself and crucially related to how we approach scale, specialisation, measurement and reward. And perhaps the hidden but more important challenges around behaviour, belief, identity, culture and trust.

Centralised model

In the centralised model, work is divided into specialisms with each constituting a team. Getting something done is a matter of dividing an objective into the respective specialisms needed to achieve it and coordinating between them. This births resource management (to look after the specialists), project management (to coordinate their work to achieve an outcome) as well as architecture and design.

Pathologies of the centralised model that inhibit transformation include the following:

• Optimisation distortions--often centralised teams are optimising part of an outcome e.g. headcount, or OPEX and task-based costing. This can mean hitting targets that cause the organisation itself and its wider aims (cf. maker-customer integration) tend to lose out in a way that is hard to prove. This is also related to the hill climbing problem. The cause is often related to unstated assumptions about the preservation of the centralised team. A mark your own homework scenario
• Fighting to preserve dying value chains--I remember in the 2000's dealing with storage teams, network teams, server teams, database teams. All these former specialisms are much simpler to perform in the virtual reality world of the Public Cloud; software engineering generalists are all you need. Take changing a firewall. It used to be a specialist skill and now can be done with a few lines of code. Here's an example of JSON code provisioning a Security Group (firewall equivalent) in AWS:

"InstanceSecurityGroup" : {
   "Type" : "AWS::EC2::SecurityGroup",
   "Properties" : {
      "GroupDescription" : "Allow http to client host",
      "VpcId" : {"Ref" : "myVPC"},
      "SecurityGroupIngress" : [{
         "IpProtocol" : "tcp",
         "FromPort" : 80,
         "ToPort" : 80,
         "CidrIp" : "0.0.0.0/0"
      }],
      "SecurityGroupEgress" : [{
         "IpProtocol" : "tcp",
         "FromPort" : 80,
         "ToPort" : 80,
         "CidrIp" : "0.0.0.0/0"
      }]
   }
}

It just got a whole lot easier, and importantly is now in the larger skillset and talent pool of software engineering. One of the challenges here for central teams is it can be difficult to move from specialist to generalist, or from one specialism to another unless a continual learning and development ethos is embraced. Q: how many farriers went on to form successful tyre companies after New York moved from horse and cart to the motor car? Not many I would wager:

New York c. 1900 and 1913

So why do we keep dying value chains around? It has a lot to do with identity. Think coal miners and climate change. Whole cultures and communities grew up around the hard underground dirty, dangerous toil (the how)--it's romantic, heroic even. Faffing about with wind turbines just doesn't cut it in comparison. Can you imagine a wind turbine service engineer marching band? I thought not.

Miners protesting the closure of the UK's last remaining coal pit in 2015

It is also about job security. And fair enough since automation's universal acid eats through former professions at a disturbing rate. This reminds me of the following quote:

"The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment."

Warren Bennis

I have found it useful to encourage proactivity in the face of the inevitable. Retraining programmes being an important step.

• Friction, resistance, inertia, context switching--to use another IT example we are typically taking something outside the code arena of the product team and into manual interaction and even stakeholder management when we use centralised specialists. Lack of continual improvement can be a factor, driven by a lack of competition--why should I improve my widgets if for widgets I am the only game in town? Communication and coordination challenges also abound--think Fred Brooks' Mythical Man Month.

Decentralised model

The decentralised model takes a different tack: specialisms, if they exist, are held within a small team responsible for an outcome whose team members typically overlap in their skillsets. And I choose the term responsible advisedly since the decentralised team is more directly responsible for the outcome whereas centralised teams trend towards being responsible for a facet of a customer outcome only. This decentralised approach births product management (to assure a customer outcome), multi-disciplinary teams (to carry out the work across the specialisms to achieve it) and flatter management structures and self-organisation (since hierarchies get in the way when team size is this small).

Pathologies of the decentralised model that inhibit customer and organisational outcomes include the following:

• Being over-stretched--doing it all yourself, even with the simplified self-service joys of Cloud Computing, means product teams hit limits. Yes we can open our own firewalls but are we as attuned to the risks as someone who has been duelling with the networking badness of the crypto-jacking, DDOSing, advanced persistent threat world of the Internet for the last ten years? Sometimes the answer is yes we are but often it is "no we are not". So how do decentralised teams own outcomes, cover the skills while making up for their necessary deficiencies? This can be the role of Site Reliability Engineering (SRE) and technical platform teams who can mop up the undifferentiated heavy lifting and provide decentralised product teams with known good building blocks to work with
• Hubris--I am freedom and I own the customer outcome. Liberating, yes, but all this concentration of power can sometimes lead to that very human negative feedback mechanism: hubris. And pride comes before a fall; we get cocky, we decide we don't need any help and we trip up as a result. It can occur with centralised teams too, but in my own experience less often. Perhaps the reason is the decentralised teams are typically doing something new and edgy and are closer to the customer, the senior stakeholders, the money and the attention-- stoking the fires of the ego along the way ??
• Balkanisation--we don't need any help and therefore we don't need any relationship with the rest of the organisation. Information is shared on a need to know basis and we live in the People's Independent Republic of Product. There is an argument that this risk is a necessary evil on the way to an adaptive scalable organisation. It has been said that Amazon follow this model. But they have a level of sophistication and competency in their working practices that goes beyond the capabilities of the average corporate. When the latter Balkanise the result can be: duplicated effort and technology, hard to integrate (and regulate) business functions run as fiefdoms. One of the hardest things in any decentralisation play is getting independent teams to maintain transparency and collaboration when this is deemed optional

The twist

Imagine the extremes of centralisation and decentralisation as polar opposite forces working on the organisation and indeed the wider market. Like some cosmic twist, the Tao Te Ching is catching the organisational straw dog in a bellows between centralised Heaven and decentralised Earth:

CENT<<<<??>>>>DECENT

In the earlier part of my career in IT, centralised teams dealt with the various specialisms of getting things done. Then things like Agile and Cloud came along, putting the emphasis on doing and direct feedback while replacing proprietary technologies with easy to use portals and APIs. A big boost to decentralisation: suddenly small business teams with a few engineers and (in the early days) a credit card could build scalable performant business applications at a fraction of the cost and timescales of more traditional means.

This triggers an existential crisis amongst many centralised teams of specialists. Their expertise currency is debased by Cloud, their secrets exposed and debunked and now any fool can do it. New business units doing their own IT in the Cloud spring up everywhere with demands to pass over data or provide connectivity sanctioned by the highest levels of management.

False dichotomy

We can also view the battle between centralisation and decentralisation as a false dichotomy. In the examples given, both are alive and well--it's just that what is being centralised or decentralised has changed. Cloud means former IT specialisms no longer need to be centralised but what about best practice, governance? There is still room for centralisation here only reimagined. In the modern era best practice might be codified in known good templates, shared by communities of practice. And governance, through the use of guard rails, can increasingly be automated.

The political challenge here is that these more abstract centralisations can bear little resemblance to the functional specialisation centralisations of the past, excluding some of the former (and still powerful) centralisation players from the game. An example would be setting up say Azure Policy (Microsoft's Cloud compliance guard rail suite) to help with Payment Card Industry Data Security Standards (PCI DSS) compliance--mostly Cloud skills are required with just a smattering of Cyber Security--Microsoft having done the heavy lifting for you. A lesson here for those that want to stay relevant: think of the coal miners and always be in the why game rather than attach yourself too much to the what and the how--since the why is more enduring (cf. Simon Sinek).

What good looks like

Consider your organisation as a code base undergoing continued refactoring in the face of a "pull" effect emanating from your customers and the wider market (and if you are good enough emanating from your own internal innovation).

As a result of these forces, what makes sense to be centralised and decentralised can undergo seismic shifts. And when something moves from one state to another it creates new opportunities for making the transition work e.g. when a specialism is decentralised due to technology advancement what new centralised services are required to make this work well? 3D printers further decentralise the fabrication of parts, creating opportunities for more centralised selling of CAD instructions to fabricate a common part, or even portal to exchange these as an open source community. Thingiverse amongst others does precisely this:

Getting this right requires insight into the evolving nature of value chains. A good grounding in Wardley Mapping can help.

Conclusions

Centralisation and decentralisation are both important tools in an optimal organisational set up. However the what of centralisation and decentralisation makes tectonic shifts when value chain thresholds are breached by innovation, requiring a whole host of transformational changes. And the old order are likely to struggle as their previous specialisms are not just moved closer to the customer but are reimagined with new technologies that threaten to exclude their involvement. To avoid tying themselves in knots, organisations must keep their focus on the why, challenge the old orders to join the cause and invest in a new generation of centralised solutions predicated on making the decentralised organisation shine.