Five monkeys and two pizzas
Has the structure of your organisation become more important than delivering results?
I was reviewing a data centre design recently with a colleague, and we were talking about how a particular way of approaching a problem can become sacrosanct within ICT. He mentioned a scientific experiment in learned behaviour that sounded too good to be true.
It involved five monkeys in a cage getting sprayed with ice cold water anytime one of them moved towards a ladder up to a bunch of tantalising bananas. Over time, the monkeys learn to restrain each other from going to the ladder, to avoid a collective dousing. Each monkey is replaced one by one over a period of time, and the boffins who constructed the cruel experiment watched as the veteran monkeys who could recall the discomfort restrained the ‘naïve’ new arrival.
It gets interesting when the final veteran who has actually experienced the ice water is replaced and the behaviour persists within the group. Turns out it was an actual experiment (Stephenson, G. R. (1967), ‘Cultural acquisition of a specific learned response among rhesus monkeys’).
My colleague interpreted the experiment as a fable of how large organisations operate, and he was quick to move from bananas to ICT budgets.
He reckoned that a conservative hierarchical organisation will tend to present project estimates which already include the innate risk aversion of the Subject Matter Expert, with each layer of management adding their own buffer of additional time, leading to multiples of the original estimate.
A number of rounds of this experience will lead to learned behaviour in the participants, as the successful navigation of the approval process becomes the objective, as opposed to the successful business result of the initiative concerned. Through the experience of the process, certain numerical norms will be established that will meet with consensus and approval and are suitably immune to detailed scrutiny. Whether these figures are realistic or challenging, encouraging efficiency and innovation is immaterial to the process.
Clearly a cynical assessment, and anecdotal at best, but exaggeration can focus the mind on fundamentals. It may also be a fair reflection of what the Business – rightly or wrongly – suspects is going on inside the ICT team. It’s worth questioning whether costs estimated for an endeavour are based on factual analysis, and to what extent they are shaped by the culture of the organisation. What does the right combination of people, technology and process look like these days?
New monkeys in a new cage
The cloud giants seem to be doing okay – and their scale and complexity is clearly substantial. They had the advantage – and all the perils too – of starting small: new monkeys in a new cage. How are they scaling up without taking on the rigidity of traditional hierarchies?
Amazon’s Jeff Bezos gives permission and authority to decentralised teams. Teams get established and stay in place, benefiting I expect from the mutual trust that is an accelerant for any endeavour: when the track record and relationships of all the various collaborators are known and proven, communication is swift and effective.
From this came his “two pizza team” idea – a team that can’t be fed with two pizzas is too large. So less than ten people, given autonomy to complete a task: ‘You build it, you run it’. Any more than ten people, and meetings and the other typical corporate activity would become a necessary evil that Amazon wanted to avoid.
For Bezos, ‘Getting there faster is more important than architectural coherence’ – a view which must have posed a challenge for Amazon CTO Werner Vogels. Here’s Vogels in a candid talk on the Lean Cloud, and how Amazon Web Services developed to address the ‘muck’ of managing their own retail infrastructure services, which was a consequence of the ‘You build it, you run it’ approach, moving choices away from engineers, letting them get on with delivering business innovation.
Some amazing ideas here: functioning as ‘a series of start-ups’, with for example 10 to 15 days to deliver new customer features because the infrastructure and organisational structures are in harmony and built for speed. I also like the reference to ‘WD40 and duct tape engineering’, which was represented in this great flowchart that should appeal to any engineer.
As my colleague Mark Cawley outlined in his recent blog, cloud isn’t just about an IT platform, it’s about the entire business. As well as looking at cloud as a dynamic on-demand enabler, organisations need to structure themselves to maximise the benefits. As Vogels makes clear, innovate around the things that don’t change for your customers – the things that will be important to them forever.
If hierarchy is in danger of becoming more important than efficiency at your organisation, it may be time to take stock of traditional business methods. How do you ensure consistent results for customers while remaining flexible and alert to new innovations? Please share your thoughts with me in the comments section below.