This is part two in series of blogs about strategy. The first part is here.
In the last few years, many companies encountered existential threats to their business. These threats came from systems that were running at capacity, from “born in the cloud” challengers, or from competitors who had made the jump to Cloud Native earlier. This left those companies playing catch up; not just in the realm of technology but also in the war for talent.
However, some companies successfully countered this threat by doing something that was previously thought of as high risk: they released quickly, empowered developers and automatically provisioned infrastructure. Companies started to see that in an ever-changing Cloud environment high risk was the new low risk. A new way of working and managing was required.
At Container Solutions, we began to notice that this new way of working included continuous strategic re-formulation. In response to this, to share that best practice and help our customers, we developed a strategic execution toolkit we call Hermes. Hermes helps teams to reframe how they view risk by framing goals as hypotheses that may (or may not) survive contact with reality. Hermes helps teams manage risk, maintain momentum and deal with strategic overcommitment. Hermes allows its users to balance focus and learning, and in doing so, lets companies experiment their way into their Cloud Native transformation. How does it do this? Through a structured execution model that leaves space to think. Let’s take a look.
In Hermes, the default execution model breaks the year into one period of strategy formulation, three terms of execution and three reflective breaks. For example, at Container Solutions, strategy formulation begins in October and runs until December, when it is finalised. This period of formulation outlines the strategy for the following year along with detailed plans for the first term, which runs from January to March. The second term begins in May and runs until the end of July. Finally, the last term, what we call the long term, begins in September and runs until December. The long term is both literally the longest term and the term in which we do the most long term thinking. At the end of each term is a reflective break at which point the strategy for the following term is updated based on what has been learned.
The Container Solutions execution model.
However, the execution model in Hermes is not set. It must be tailored (and constantly retailored). For example, Container Solutions are currently executing a large scale programme of work where the terms are only one month long. This condensed execution model leans heavily towards learning - the more you iterate the more you learn - but does so at the cost of focus. The reason for this short term is because the project has just started and the risk is high. As the situation becomes better understood and risk gets sucked out of that programme of work, the terms will get longer and the teams will slowly start to scale up - so each term becomes a larger investment. As the term stretches out again to what we think is the optimal three or four months, the balance between focussed productivity and learning will return.
A classic mistake for large companies is to start with a term of three months or longer, throw millions of pounds / euros / dollars at a poor programme manager who has to manage the work like it was a normal project with no risk in it, and then watch as chaos reigns before the fast ramp up disintegrates into an embarrassing (and costly) ramp down.
Why do companies do this? It’s mainly because they are not used to dealing with risky projects. In a high risk environment, large programmes of work will only succeed in a very narrow range of futures. I.e. large projects that are not de-risked are probably going to fail.
In low risk projects where the future can be known, a 12 month term with classic management is a good choice. The problem is that companies misdiagnose a move to Cloud Native as technical and simple when it is neither. This leads to the decision to run the programme as you would a classic, highly known project. That is a mistake.
The reflective breaks in Hermes are key moments where we change the insights of the previous term into actions for the following term. (And actually the whole point of strategic execution is to change insights into actions, which is easy to say but hard to do.) Together, the breaks and terms allow us to follow the guardrails set by the annual strategy whilst leaving the door open for new ideas as they emerge. This is how we balance focus and learning, which allows the strategy to coherently evolve over the following year.
During a migration to Cloud Native, it is during the breaks that our customers will ask, “is this tool working for us? Has the landscape shifted and if it has, should we shift, too?” Much more importantly, the breaks allow our customers to ask how things are working in their context. I.e. they allow them to stop and ask, “should we improve our strategy with stepwise changes or do we need to make a radical change in direction?” In other words, the breaks allow us to deal with strategic overcommitment.
Often strategy is seen as a binary choice between the application of a set of analytical tools on the one hand and following your gut on the other. In times of uncertainty, most analytical tools don’t work, or at least they don’t predict far enough into the future for them to justify their use. So, a round of analysis may produce a strategy that by the time you execute it may not make any sense. This is strategic overcommitment.
An example here might help. A year ago we we met a department who were about to move wholesale to AWS. They had analysed their workloads, understood the landscape, and made their choice. What they didn’t think was important was containerisation or orchestration with Kubernetes. Once this programme was up and running, a higher level decision was made to work with Azure. The applications and build systems were now baked into the AWS stack and a migration to Azure would be more expensive than starting from scratch. This department had overcommitted to AWS and not committed to an experimental, iterative strategic reformulation method that reflected the realities of their environment. In other words, by the time the AWS strategy was being executed, it no longer made any sense at all.
When this happens, a classic anti-pattern, or dangerous move, is to throw your hands in the air and declare, ‘strategy doesn’t work for us’, and then throw away all your rigorous processes and revert to your gut. The problem here is that working on instinct feels nice, like when you are in flow, and people like to act from their gut for this reason. But this is not effective. There’s hardly anything nice about strategic execution and if it feels nice it’s very likely that your strategy is pants.
The solution to strategic overcommitment is to use an approach that lets you throw out the dichotomy of rigour vs. gut. For us, Hermes is that approach and the breaks are the things that enable our emergent strategy.
Emergent strategy is about three elements: the intended strategy, the deliberate strategy and the realised strategy. The period of strategy formulation produces the intended strategy. In the case of CS, this usually happens in Q4, during the long term. For one of our larger customers, it is happening right now, but only because now is the time that the programme is kicking off. If they had started in February, then that’s when they would have started to produce their intended strategy.
The intended strategy forms the guardrails for the following year, providing focus for both the leadership teams and the organisation as a whole. As the year unfolds the parts of the intended strategy that survive contact with reality, i.e. that actually go on to be implemented, become the deliberate strategy. The parts of the intended strategies that don’t survive contact with reality become non-realised strategies. They end up in the fuck it bucket.
Henry Mintzberg’s Model for Emergent Strategy
Within Hermes, we have replaced ‘non-realised strategies’ on Mintzberg’s model with the ‘fuck it bucket’. In a technology company like ours, non-realised strategies include bits of source code, visual models we abandoned, industry segments that were not quite ready. Over time, and often very quickly, we find ourselves back in the bucket, rummaging around, and bringing back to life what was previously dead. We came to see ‘non-realised strategies’ as ‘non-realised, yet’. And of course, the quicker we iterate, the fuller the bucket gets.
Before a large company officially moves over to Cloud Native, there are often multiple experiments into, for example, container orchestrators, build systems and registries. Many of these experiments end up in the bucket. But to view this as waste or failure is to miss the point. Experiments are how organisations learn. For example, when we meet companies there are often many simultaneous experiments running. One team might be using vanilla Kubernetes whilst others are using the free versions of OpenShift or Rancher. One team might be playing with APIs. This wide ranging experimentation is often seen as bad, as chaotic, as expensive. This leads to a call for the harmonisation of tools and processes. This is the wrong call.
It’s wiser to harmonise on a method for learning (since learning is the thing you have to accelerate in the beginning of a transformation) than it is to harmonise on a toolset or approach. In other words, the already existing experimentation needs structuring. The bucket is part of the structure, it enables emerging strategies by habitualising and systemising courage. (And, as ING taught us in the last blog, courage is a competitive advantage.) At Container Solutions, when things go wrong, we literally tell each other, ‘chuck it in the fuck it bucket’. This gives everyone great confidence to learn, safe in the knowledge that failure doesn’t lead to punishment but rather to new ideas and forward momentum.
Each term allows us to bring a part of our strategy to life. At the same time, as the term unfolds, we gather new insights into how our strategy is fairing against reality. The breaks, which in Hermes includes structured workshops, allow us to critically and coldy assess if any assumptions we had were shown to be true, false or unproven. Together, the terms and breaks produce rich information about what just happened and this information points us towards what has to happen next.
In other words, the terms and breaks allows us to jettison parts of the intended strategy that were wrong. At the same time, they allow us to integrate emerging strategies into the main work streams. Together, emerging strategies join with the deliberate strategy to create the realised strategy. The realised strategy, which is only fully known in hindsight, is a key input for the next strategy cycle.
When viewed like this, we can see that strategy develops over time and it is therefore a process. It’s a process that is informed by intelligence; built upon situational awareness; often has goals but, crucially, is iterative in nature; and is biased towards action. The stratagems that make up the whole strategy are really nothing more than hypotheses that must be tested against reality. Some stratagems survive such contact. Others do not. Some stratagems evolve into something completely different. Some were spot on the first time. It is our strategic execution system that lets us (and our customers) test assumptions, re-examine and adapt, and then make the call if we should proceed with incremental improvements or whether we need to radically change direction. When faced with the dilemma of ever changing technologies and ever shifting customer demands, we have come to see continuous strategic formulation as the only method for succeeding with Cloud Native.
Companies who want to succeed in the world of Cloud Native have to have a structured way to change direction. They also need to throw away the false choice between acting on instinct and total analytical rigour. In doing so, they will realise that strategy is a process, and with an execution model that balances focus and learning, they can feel their way through a migration to Cloud Native. Hermes is based on one such model. It balances focus and learning by structuring the annual cycle in order to allow strategies to emerge.
However, as the wide scale adoption of the agile software methods teach us, structure is not enough. In fact, the expected benefits of systems of strategic execution are unrealised when they are used in a bureaucratic manner. If this happens, your strategic execution toolkit will devolve into an accounting tool and in pathological organisations it will devolve into a tool of coercion. To understand this, we need to look at the difference between bureaucratic and generative organisations, which will be the subject of my next blog.
Want to learn more about how to move fast without breaking everything? Download our whitepaper below:
