Our book, Cloud Native Transformation: Practical Patterns for Innovation, is a collection of case studies, a design method and a series of patterns. The patterns can be combined and recombined to solve an infinite number of problems, some of which don’t yet exist. Fully implemented, the ideas in the book won’t just let you build one awesome Cloud Native system. Rather, they will let you constantly innovate, producing digital product after digital product, whilst letting you surely (but not necessarily slowly) evolve your existing product features in exactly the way that Netflix, Starling Bank, and Skyscanner do.
Our original patterns book is broken up into sections that include infrastructure and cloud, development and process, organisation and culture, and strategy and risk reduction. Some people avoid the strategy sections, hoping they can get to them later (or, preferably, never). Others dive straight in, looking for anything that will help them to understand what strategy is. More importantly, they want to know how they can ‘do it’ at work, every day, without frying their brain.
This book expands upon the strategy section of Cloud Native Transformation. It is divided up into three chapters. The first chapter states clearly what strategy is and what it is not. Here we look at the eternal problem with strategy: it is hard, requiring great intellectual exertion, but our managers are pressed for time and out of practice. We square this circle with patterns. Patterns provide a framework for thinking—but they won’t do your thinking for you.
In Chapter 2, we have the patterns themselves. They include Dynamic Strategy, Research Through Action, and Gradually Raising the Stakes. These strategy patterns, when combined, allow us to plot a way forward, step-by-step. They help us to both understand and navigate the landscape we find ourselves in. These patterns have been used multiple times to launch products, capture markets and build defensible positions. As we write this, during the time of the COVID-19 pandemic, they are being deployed again, only this time to help companies navigate through the crisis.
Finally, in Chapter 3, we return to WealthGrid, the fictional company at the center of our book Cloud Native Transformation. Here, we find that our hero, Jenny, is at it again. After successfully transforming WealthGrid into a Cloud Native organisation, Jenny and her team find that innovation is easier for them. However, a perfect storm of changes in regulation and user behaviour puts WealthGrid’s core revenue stream at risk. Jenny immediately makes a series of no regret moves to try and understand her new reality. In doing so, she hopes to get WealthGrid back on track. The question is, will she succeed?
Jamie and Pini, in lockdown in London and Amsterdam, April, 2020.
Due to the way we do business, when it comes to strategy, most of us are junior. Many businesses operate within stable landscapes. They have no need to change, never moving beyond step-wise improvements. Therefore, they are not equipped with the tools or mental models they will need, should the landscape shift. This means, when radical change is thrust upon them, either by a competitor or something like the COVID-19 crisis, they are in no position to respond.
As a reaction to this situation, most strategy books are formulaic—which, in the case of radical change, makes them next to useless. At Container Solutions, we don’t believe books on strategy need to be formulaic. Managers and leaders are time-pressed but not stupid. Many are out of practice or simply inexperienced when it comes to strategy.
This is why the method in this book is not formulaic. There are no worksheets to fill in. Instead, we ask the reader (like we ask our customers) to follow a process that guides their thinking but won’t do it for them. That process is called ‘design’ and it relies on elements that are called ‘patterns’. Together, design and patterns bridge the gap between expert strategists and the ‘manager on the street’. When the winds of change start blowing, it is the manager on the street who must deal with the change that is thrust upon them.
So, what are patterns and where did they come from?
Originally, Christopher Alexander, an architect, developed pattern languages to bridge the gap between architects and ordinary people, so they could design their own homes. Software design patterns subsequently arose for constructing non-concrete objects: computer programs. In both cases, these patterns allow us to fill technical gaps between expert practitioners and those with less experience. When junior developers can read, understand, and apply patterns created by experienced engineers, this greatly accelerates the production of new software/systems.
The patterns in this book do exactly the same for strategy. They form a bridge between the expert strategists in a team and their less experienced colleagues. This will greatly accelerate the production of new strategies, reduce the number of arguments that occur in the ‘valley of death’ of uncertainty, and help groups to align on their next actions. By using patterns, more junior managers can benefit from knowledge they haven't had time to build on their own. At the same time, experienced strategists have a rubric that lets them teach strategy. This is handy because experts often can’t teach; they don’t know exactly how they do what they do. Their hard-won lessons are buried deep within their subconsciousness.
Patterns are not a hack. That is, they are not a quick and easy way to solve difficult problems without careful thought. Instead, patterns are a language for sharing context-specific working solutions. Context comes in when we select and fit patterns together to form a design. This brings us to the three core concepts at hand: patterns, pattern languages, and design.
These terms vary based on which patterns are being applied and how. In the context of Alexander’s building patterns we use ‘patterns’,’ ‘pattern languages’, and ‘designs’ to construct, from micro to macro scope, individual rooms, buildings, neighbourhoods, cities, regions, and so on. This is exactly the approach we take. We use the strategy patterns in this book to construct new plans, new objectives, products, services, and eventually even business models.
For example, the ‘Research Through Action’ pattern may allow us to prod and probe a particular set of users about a new feature. If it seems the users like the feature, we can ‘Gradually Raise the Stakes’, learning as we go. By doing this, we are stepping through an uncertain landscape without burning all of our resources. If we are building digital products, we may adopt Cloud Native and thus ‘Reduce the Cost of Experimentation’. Finally, the information we are gathering may feed into our ‘Dynamic Strategy’, which, with the odds stacked into our favour, let us take a ‘Big Bet’. Together, these patterns are used to help us to formulate our strategy.
Taken together, patterns, pattern languages, and design form the way to simply but fully describe a complex strategy. However, there is no one right—or, for that matter, wrong—way of creating and presenting patterns.
Fundamentally, however, all patterns convey the same areas of information:
A good pattern is precise and concise. It concerns itself with a specific and limited problem, isolates and identifies the forces that shape that problem, and tells us what to do about it. It ends by describing the new context that will be created once the problem is addressed. And it does all this in simple language accessible to almost any reader—you do not need deep expert knowledge to understand a pattern. The whole idea is to make deep understanding beside the point; we are trusting in the experience and knowledge of the pattern writers to create a guided and reliable path for us to follow.
The patterns in this book help you to design your own strategies. Your strategies may involve you taking advantage of a tool you created or an observation you have made. The patterns will let you and your team become strategists, working together to shape events. They will also allow you to become a better team, using the patterns to avoid time-consuming arguments. To understand this, let’s now define what we mean by strategy.
The strategy of a group is its ‘general direction’, which you can only know over time and therefore in hindsight. Strategy never comes into existence fully formed. Today, for example, we know that Ikea’s strategy is to produce low-cost furniture for growing families. We also know that, behind the scenes, Ikea innovates on its products and supply chain. All those years ago, the founder of Ikea did not sit at his kitchen table to create this strategy. What instead happened was that events shaped Ikea and, of course, Ikea shaped events. In other words, the company reacted and responded to what was happening. The strategy is the reaction, which indicates that it grows from a process and evolves over time.
The process for strategy formulation we use at Container Solutions is derived from the management expert Henry Mintzberg’s model for emerging strategy. It comes in five parts.
Taken together, these five elements form a company’s strategy. At Container Solutions, we clearly view strategy is a process. It is not a plan or an edict handed down from on high, but rather the cumulative results of many, many actions. There is space for strategic thinking but as you try to shape events, you have to accept that events shape you, too. Our reaction to these events will have a bearing on our strategy.
Within this process you can see both the power and limitations of strategy. The power comes from our ability to analyse, to change direction, and to let events unfold so we can take advantage of them. The limitations come from the events themselves. At the time of writing, for example, the COVID pandemic is laying waste to the strategies of airlines, retailers, and even our governments. This is not a reason to give up on strategy—winging it is not a better strategy —but you have to be cognizant of its limitations; as we shape events, events shape us.
Henry Mintzberg’s model for emergent strategy.
Our ability to judge situations, to read underlying patterns, and to align coalitions around our observations will be crucial to our success. Even though the notion of a singular strategic mind, like a James Bond villain, is a myth, it doesn’t mean the idea of the strategist is dead; why would anyone engage with strategy if they thought they couldn’t shape events or at least take advantage of them?
The strategist tends to have the following characteristics.
A good example of a powerful voice comes from Martin Luther King, Jr. He said, ‘I have a dream that one day this nation will rise up and live out the true meaning of its creed: We hold these truths to be self-evident, that all men are created equal’. In just one sentence, King is able to paint a vision for the future based on the United States' own history and value system. The ‘I have a dream’ speech was not delivered on behalf of one group, African-Americans, but for all Americans. King painted a vision that included everyone and used his voice to give life to it.
Some people focus only on voice. When politicians do this, for example, we accuse them of strategy by soundbite. Managers can be guilty of this, too, focusing on bombastic messages that, unlike Kennedy’s moonshot, are not rooted in reality. In Yorkshire, they call such people gobshites.
In the 20 years we’ve been working, and much more recently during our work with Cloud Native transformation, we have observed two common personas. We call them half-baked strategists. Neither of these personas are bad and indeed both have an excellent chance of becoming outstanding strategists. However, under no circumstances can a half-baked strategist be put in charge of guiding a group through uncertain times. These two personas are the angry engineer and the fantasist
The angry engineer often speaks for the group they represent. They do understand their part of reality, usually around technical challenges. However, they have one black hole in their understanding of reality: they don’t realise that people don’t like to be shouted at. Over time, the angry engineer alienates those who are in a position to help them most, namely managers. This means their popularity within engineering may grow, but when it comes to affecting real change, they are ineffective.
The fantasist is often a leader or a manager. They may be prone to whimsy. They may manage ‘by shiny thing’, which means they are susceptible to conference talks about Spotify and Netflix. After seeing such a talk, they return to their offices and declare to their teams, ‘we are going to do tribes’ or that ‘we are going to be the Netflix of the Netherlands’.
The fantasist, although often having a voice in their organisation, struggles to get their ideas off the ground. This is because they are not credible. They can’t build working coalitions because they don’t speak for their group. They speak only for themselves. Strategy has to be other focussed as all its power comes through coalitions. By neglecting this, the fantasist breaks an important rule of thumb.
Another rule of thumb when it comes to strategy is that it has to be rooted in the present. The fantastic breaks this by starting with the future, which is where it ends but it is not where it begins. Strategy begins in real life, with real people who have real problems.
The world we occupy is full of fantasists and angry engineers. We are not judging here; everyone at Container Solutions has been an angry engineer, a fantasist, or both. In the successful Cloud Native transformations we have seen, the following happens: the angry engineers and the fantasists join forces and they use the patterns in this book to start to figure everything out. This is not without arguments, nor is without tears.
We have seen in this chapter that strategy is a process that develops over time. We have also seen that most of us are juniors when it comes to strategy, mainly because we are out of practice. We have seen that there is no master strategist but the fantasist and the angry engineer, together, have all the characteristics of the strategist. We explored patterns, seeing how they can link the knowledge of experts to those who are less experienced. In doing so, we said patterns allow us to create better strategies whilst avoiding time consuming arguments. We can now discover these patterns and how they relate to each other.
¹We promised in the opening chapters we wouldn’t be formulaic. Please forgive us this transgression.