We don’t only do Kubernetes, even though we are one of the only firms in the world to be both certified service providers and trainers. What we actually do is build large scale distributed systems and the platforms on to which these systems are deployed.
This is relatively easy. Getting our customers to consume the platforms we help them build is difficult. Getting them to build systems that are made up of secure, distributed, microservices is very difficult. But changing their management and leadership habits and structures so that teams can act autonomously (so they can move fast) and synchronised (so they don’t break everything) is the toughest challenge of them all.
The Dilemma - The Growth of Knowledge and Ever Demanding Customers
The problems of building Cloud Native systems and adopting them both seem like child’s play next to the real dilemma that companies face: an ever-growing gap that is driven by technological change. On one side of the gap, the body of available knowledge that companies must deploy sensibly is not just growing but also mutating over time, with new ideas invalidating what was accepted only a year ago. On the other side, the expectations society places on businesses are also shifting rapidly.
The dilemma, therefore, is this: which tools and technologies should our businesses commit to, given that a. the tools and technologies are changing rapidly and b. so are customer / societal demands? The answer is, you shouldn’t commit to tools and technologies at all but rather to a system of management that lets you navigate the gap by continuously reformulating your plans.
We actually want our customers to succeed with Cloud Native technology (i.e. we don’t want to just pick up fees for setting up clusters). We want them to build awesome applications and deploy to outstanding platforms. However, they can only do this if they adopt a system of management that helps them to reformulate their strategies on the fly.
This is why we never speak about containers or Kubernetes without also speaking about management: you can’t succeed with one without also succeeding with the other. And because of the ‘dilemma’, when we speak about strategic formulation, we nearly always speak about continuous strategic formulation.
An Example of the Dilemma - Digital Banking
In the last ten years, tech unicorns like Amazon, Facebook, and Google trained consumers to expect a completely different user experience (polished, seamless, effortless). Because of this training, consumers wanted all their products to work reliably and quickly. They also began to expect that new features would not only be turned around quickly but also deployed without any loss of service. The customers of Amazon, Facebook and Google at one point turned to their banks and asked for the same level of service they were getting from their bookshop, social network and search engine.
Of course, most banks couldn’t hope to match the service levels of these digital-first firms and this opened up a market for digital only, ‘challenger’ banks, like Monzo and Starling. This was the first level of threat faced by high street banks. The second level came from the unicorns themselves - what if they decided to move into high street banking just as Amazon had moved into, and destroyed, the market for high street bookstores?
You can see that the change created by the unicorns altered both the body of knowledge on the one hand (as they pioneered new techniques) and consumer expectations on the other. They actively enhanced the dilemma.
For many banks, this was not a theoretical dilemma but an existential one - and few have been able to effectively confront the threat. In the Netherlands, however, ING continue to give it a good shot. In the last five years, ING have changed the way they operate their business, specifically how they manage their IT infrastructure and build their applications.
What set ING apart from their competitors? Rather than wait - the preferred strategy of nearly everyone in the finance industry - ING acted early on their insights. Importantly, they focussed on learning, with quarterly reflections, allowing new ideas to come into play today that, five years ago, were not even on the horizon.
Moving Towards Best Practices vs. Moving Best Practices
The decision of ING to move early meant that they could begin to adopt the best practices that had been pioneered by, for example, Spotify, Netflix, Google and Facebook. ING were not moving best practices but they were moving towards existing best practices. This is a good example of late mover advantage: others had already solved many of the problems that ING would face.
Adopting these best practices was particularly astute because it tapped into the three key insights of the day - insights which everyone had, but only a few were willing to act upon. They were:
- All companies are now software companies (or at least could use software to gain massive competitive advantage).
- Developers like to work on cool stuff.
- Many of the firms who were moving best practices forward open sourced both their code and their thinking. (The famous Spotify engineering culture video and the Netflix Culture deck are examples of how thinking was freely shared.)
Based on insight 1. above, in the last ten years, ING established themselves as a serious engineering brand. Because of 1. and 2., they established themselves as a place where top talent wants to work. Finally, because of 3, they were able to take advantage of positive externalities; i.e. they were able to piggyback on the work that others had already done and shared for free. Later, they would themselves move best practice forward by contributing to open source projects and speaking at conferences.
What the ING case teaches us is that you can’t know the future but you can know the present. ING knew about the competitive landscape. They knew what modern engineering was all about. But what set them apart was that they had the courage to change their insights into actions. These actions did not help them predict the future but they did help them prepare for it. This gives us a clue as to how continuous strategic formulation is used to deal with the dilemma.
Returning to the Dilemma
As I said at the beginning of this blog post, the body of available knowledge that we can sensibly deploy is changing all the time, invalidating what was ‘fact’ just 12 months earlier. At the same time, the expectations that businesses place on managers are shifting rapidly, too. In this dynamic context, any strategy that locks you into a stream of work will lead to a failed strategy.
Image 1 - the Rolling Stones pattern of failure: You get what you want, but not what you need.
A failed strategy - where you get what you want but not what you need - is what happens when there is no way to integrate new ideas into your workstreams. Continuous strategic formulation is a combination of structure and organizational habits. This combination lets new ideas join your workstreams whilst abandoning those that completely fail contact with reality.
Conclusion
You can begin to see that when companies say ‘We want to containerise our services for the cloud’ what they really mean is ‘We want to completely and utterly change the way we execute strategy in our business.’ They ask for Kubernetes because it’s a named commodity representing this shift -- but it is far from the complete package.
So, yes, at Container Solutions we absolutely “do” Kubernetes. But, because we want our customers to succeed with Cloud Native, we also teach our clients how to remain self aware in this context of ever-changing information and (more importantly) how to respond.
By continuously reformulating their plans, enterprises give themselves a chance to simultaneously face the challenge of changing customer demands and the challenge of changing technologies. In other words, they can learn to mind the gap that is driven by technological change.
Acknowledgement
The failed strategy model is from Henry Mintzberg and used with permission.
Want to learn more about how to move fast without breaking everything? Download our whitepaper below:
Previous article
