This is part four in series of blogs about strategy. The third part is here. The starting point is here.
The history of all hitherto existing society is the history of… just kidding. There will be no second, or even first, enlightenment philosophy in this blog. There’ll be no Katy Perry references. There’ll be no nostalgic trip down to the 1970s or 80s. For that fix, you'll have to watch Strange Days. No, instead, I am going to stick to the facts, and bring to you, in under 1500 words, 100 of which I’ve wasted on this introduction, some of the key reasons why migrations to cloud and Cloud Native fail. Starting with executives who have lost the ability to function and ending with the widespread problem of mixing up cause and effect, we’ll do a quick safari through five common failures.
When an executive team invests in a strategic change, they follow a pretty standard, linear route from formulation to execution. They move from the globulous, fantastical and imaginary place on the left of image 1 all the way to the prioritisation and delegation of objectives on the right. Measures are set up and if the initiative comes off track they nudge it back on track. Executives double down on what’s going well and jettison what’s floundering. Easy peasy.
However, when it comes to Cloud Native, their rational minds suddenly become of little use to them. This is due mainly to the uncertainty that surrounds new technology. The reason for the uncertainty is because, when it comes to Cloud Native practices and processes, there is a lot of exploration to do. There is no one “silver bullet” solution -- this is new and evolving tech, and every cloud migration is unique to the needs and specifications of the organization undertaking the journey. Time and tinkering is required to identify the optimal transformation path. This is the complete opposite of a standard, linear route to reliable success, of course, and so creates an anxious void in the minds of executives. This void unfortunately tends to get filled with glorious tales of technological victory, ideas whispered by strategic advisors, and of course the hype generated by vendors...whose business models are based on exploiting their customers’ fears and (conveniently) restoring hope with their products.
Executives can become impatient. Anxiety is unpleasant, and plus they approved a big budget for this Cloud Native stuff! They want to see action! Quick evidence of progress! This mindset leads to our first common mistake: too quickly committing to a “big bang” solution, which ultimately was not the one needed. Resulting in a quick, and expensive, ramp up followed by a quick, and embarrassing, ramp down.[1]
Remember, the key to success with Cloud Native is to accept that it’s a process of exploration and should be treated as such. Assign a few people to experiment on a few simple ideas, thus working your way into greater organizational understanding. Once you know what you’re doing, when you’ve de-risked and up-skilled, you will be ready to ramp up, having massively stacked the odds in your favour.
There is, and there never will be, a technical fix to a problem that is not technical. There are no magic pills. Let’s think about the cycle schemes that are going so well in London and Paris. There is technology: the bikes, the pick up points, the online system for registering. There is also infrastructure, such as cycle tracks and new traffic lights. Did people really think that by setting up the technology and infrastructure that all us fat-arsed Londoners would spontaneously start biking to work? Of course not. The real challenge was not about the technology, as that’s relatively straightforward. Instead, winning hearts and minds -- doing the very, very hard work of trying to get people to change their habits -- was the real challenge. Bravo to London and Paris.
It’s the same for Cloud Native. The technologies are deceptively easy. Much to our customers’ amazement, nowadays we set up Kubernetes clusters and onboard their applications in just a few hours. That is by far the easiest part. Teaching them to rethink product/service design and delivery, containerise their applications, manage their work, and generally de-risk their migrations -- these lessons are all very, very hard. They require dedication, time, money, and a commitment to exploration, which is another way of saying that our customers have to begin to manage for complexity and not simplicity.
If you want to succeed with Cloud Native, you simply have to change your organisational habits. Changing habits is the realm of management. Learn from the bike schemes in London and Paris: infrastructure is the easy part. Getting everyone up and riding, that is the real challenge.
Falling into the trap of thinking that Cloud Native is a technical problem is bad enough. But there is a secondary trap: if you regard Cloud Native as simply being a technical shift, then you don’t take it seriously. A move to Cloud Native requires investments into training. It means altering the way you record costs, moving items from the balance sheet (capital expenditure) and putting them on the profit and loss statement (operational expenditure). It absolutely alters the way you manage work; because Cloud Native is new, it’s about exploration. Exploration requires prioritized time and budgets. And these are all table stakes. These are the non-negotiable things that have to be put in place if any Cloud Native initiative is to succeed. You don’t have to do them all at once, and in fact you shouldn’t try to. But you do have to do them.
Image 2 - It’s important to remember that the path to Cloud Native is emergent, requiring exploration. This path can be not planned for in the traditional sense. It can only be experimented into, which has the benefit of letting companies learn as they go.
Succeeding with Cloud Native is about thinking big while starting small. View each next action as an option you can take. At the same time, practice choosing the option that is most ‘pregnant with possibilities’.[2] I.e., pick the option that will lead you to ever more sensible next steps. An option to throw up your current Java applications onto Google’s cloud, for example, may be more sensible than using a distributed ledger to track guests visiting your office. By following this process, the table stakes are gradually taken care of. Even better, each next option -- though unknowable in advance -- is almost certainly the best use of your time and money.
Here’s an old social science joke:
Social worker: be kind to Johnny, he comes from a broken home.
Teacher: I am not surprised, Johnny could break any home.
Social scientists are trained to connect cause and effect but also to make sure they don’t get causation and correlation mixed up. In my last blog, I said that practices like TDD and continuous integration arose as the outputs of teams who were looking to optimise their processes. I.e. they were an effect caused by people looking to improve. They were not a cause in and of themselves.
It’s the same with Cloud Native. Many people have heard Adrian Cockroft speak about Netflix. However, the same people conveniently forget the bit where he says don’t copy what Netflix did (the effect). Instead, copy their way of thinking and experimenting (the cause) to reach your own best solution.
Simon Wardley calls the practice of mimicking what other companies do, rather than how they do it, Meme Copying. He says that’s how most strategy is formulated. He’s right. The reversal of cause and effect is also at the heart of many failures with Cloud Native. People should not copy other companies’ outcomes, but rather the thought processes that created them.
Don’t worry about what other people are producing but pay attention to how they are producing it. Look carefully into the heart of all successful moves to Cloud Native and you will almost certainly find an experimental process and of course the accompanying mindset. Don’t outsource your thinking, especially to a vendor.
Cloud Native, at its heart, really serves as a counter-balance to organisational change. For example, many of our customers succeed in unlocking new revenue streams with new products or services. They are then immediately confronted with leaving loads of money on the table because they can’t scale. Their success knocks them out of balance -- and getting their systems to scale so they can then realise their new revenue brings them back into balance.
Other customers have a negative experience that throws them out of balance. More and more these days we are speaking to customers who are suffering from an exodus of engineers. This is because:
Companies with such negative experiences see Cloud Native as helping them to get back in balance by staying relevant as an engineering brand whilst also allowing them to manage their systems better. The model for development and deployment is much more humane with Cloud Native, too. Many people over 45 may not give a shit about this but unfortunately, everyone younger than that does.
If there is no force to balance, Cloud Native initiatives tend not to work -- because there is no real organisational drive or motivation to make them work. Remember, the rewards are massive with Cloud Native -- but so too are the costs. It’s not an undertaking that should be entered into lightly. Make sure that you have a real organisational force that needs balancing or as Pini says, that you have a business case.
Cloud Native is new and constantly evolving. The combination of uncharted territory -- requiring experimentation and tolerating ambiguity in the process -- means organisations need to evolve themselves in concert with their newly adopted tech. Fortunately, enough people have been doing this for a while now for us to identify common pitfalls and failures along with strategies to prevent or avoid them. These strategies, from pacing yourself to identifying true cause and effect relationships to staying in balance, are logical and once pointed out, fairly obvious.
Unfortunately what is less obvious is that the success of all moves towards Cloud Native are directly related to how an executive team reacts emotionally to the task ahead. It is to the dark world of emotions to which we must turn next.
[1] 'Why So Many High-Profile Digital Transformations Fail', Westerman and Davenport.
[2] Good Strategy / Bad Strategy, Rumelt.
Want to know more about Cloud Native strategy? Check out our toolkit below.
