Welcome to the age of digital Darwinism! Technology is evolving with dizzying speed. Existing markets evolve just as quickly, while new ones emerge seemingly overnight. The same is true of competitors.
And yet, in an environment where disruption is everywhere, many enterprise leaders lack the experience and creativity to react with corresponding strategic shifts.
Going Cloud Native is the best way to meet this paradigm shift head on and compete successfully in this new reality. Unfortunately, many companies struggle to succeed in their transformations because they fail to understand that their organisational culture and processes must adapt and evolve in pace with their newly adopted CN tech. Top management must lead the way, by implementing strategic changes in organisational structure to ensure their newly Cloud Native enterprise remains fast and flexible.
It’s a real challenge to keep a company on track delivering core business value, yet ready for any challenges an unstable marketplace throws their way—how can leaders best walk this strategic tightrope? We asked Jamie Dobson, co-author of the new O’Reilly book Cloud Native Transformation: Practical Patterns for Innovation (download a free excerpt here), for his take.
If you are a high-level leader and your company is poised to undertake a Cloud Native transformation, how exactly does your job change?
I think a better question would be, how doesn’t your job change? Because a lot has to. But maybe we should start with what will be constant.
There are a handful of leadership behaviors that work in all contexts. Since Cloud Native requires working with lots of teams, the ability to build effective teams and offer credit to the whole group is essential. Cloud Native is also a context that drives and demands high performance, and therefore demands managerial courage. It is important that leaders take swift corrective action where they have to, and offer constructive feedback in all other cases. Finally, visioning is important, no matter what your leadership level, as this is what the group or even the entire organisation will be driving towards, only now a lot faster.
Now, to the things that will really change. The biggest is the overall shift your mindset and adopting processes to support your new world view—leading the way to creating Cloud Native organisational culture. There are two key ways this manifests.
Firstly, in Cloud Native, we actively encourage failure whilst actively pushing decisions as close to the action as possible. This leads to great learning and great flexibility, since decisions are not escalated but dealt with in real time by the right people. Control structures from the old world don’t work. Instead, we see the use of town halls as a system of control, management by walking around, and we cultivate great agency in our people and great safety in the environment. We actively distribute power.
(What is greatly empowering for engineers, however, can feel disempowering to their higher ups: if their job is no longer to make decisions, then what is it? There can be pushback, even subtle sabotage, due to anxiety or resentment related to these changes, so keep aware and ready to handle this when it arises).
Secondly, leaders have to learn to tolerate chaos whilst drawing order from it. Cloud Native is at its heart a way to evolve digital products in conjunction with changing customer demands. There are periods of calm followed by periods of intense energy and chaos. But the trajectory is always forward. This is not something that needs to be controlled, but embraced.
Good leaders deal with ambiguity, but great leaders change it into opportunity.
Changing ambiguity into opportunity sounds like strategy. So how else does Cloud Native strategy compare to the traditional way of setting vision and direction for a company?
Cloud Native cannot itself be the strategy. That is, moving to Cloud Native isn’t going to solve all your problems, you’re done, now live happily ever after. We see companies make this faulty, though undeniably alluring, assumption all too often.
The truth is Cloud Native is a core capability that gives competitive advantage because the way it works allows us to quickly create actions from our insights. Cloud Native transformation is of course strategic for these reasons.
In a way, those with Cloud Native are like those old car factories that automated vs. those that didn’t. Those that didn’t quickly got left behind and nobody now knows who they are. If you build digital products and don’t embrace Cloud Native, you won’t be around in the next five years, and that includes the businesses who have been around for the last 100.
Once a strategy has been established, what is the mechanism for applying it?
What you need is a mechanism for learning whilst simultaneously reducing risk. So, the mechanism has to include multiple feedback loops, an open and curious mindset and, paradoxically, patience. Ideas give way to hypotheses and hypotheses give way to the emerging path. So we go slowly before we go quickly. The mechanism for bringing strategy to life is dynamic, iterative, and most definitely not linear. (We came up with a strategic execution methodology to put some practical boundaries around the process, and we are happy to share it).
So that’s the strategy. What does leadership itself look like, in a Cloud Native enterprise?
It looks like it would be in an old-fashioned innovation lab. Ideas are king, safety (in this case, psychological safety) is queen.
More specifically, risk-taking is praised rather than discouraged. Messengers are trained and listened to. Learning is key, so failures are encouraged. Failure leads to insights and those insights lead to adaptive changes. Usually, in an existing company, knowledge is exploited. In a Cloud Native context, knowledge is generated and exploited simultaneously. Leadership needs to be geared up to create that context.
Some say that CN is just a forward iteration of Agile. Thoughts?
It depends on what you mean by Agile. Agile in the original sense was nothing more than favouring people over process, working code over documents, and working next to your customer. Based on these principles, methods were formed. One of them was Extreme Programming (XP).
I see Cloud Native as a continuation of XP. This is what they have in common: high levels of build automation and responding to change. But that’s actually about it. XP was for small teams creating simple products; Cloud Native is about building large-scale distributed systems with multiple teams.
The only real commonality —and it’s an important one—is that both ideas are human-centric and both rely on good teams that can continually improve. For example, those who pioneered the Agile software methods did so because they realised that solutions emerged from an iterative dance where problems and their solutions co-evolved. This iterative dance is inherent in Cloud Native, only this time it is extended to include real end users. The XPers had the urge to constantly improve. So do Cloud Native teams.
What are the key cultural differences that a successful Cloud Native organisation has in place, versus a traditional one?
There is only one cultural difference between a Cloud Native organisation and a more traditional company. One is generative and the other is bureaucratic. The former generates knowledge, the latter exploits it. The former loves failure, as it leads to innovation; the latter hates it, as it indicates a problem. The former loves high levels of cooperation the latter tolerates a low level of cooperation. These types of organisations are neither good or evil; we are all the beneficiaries of bureaucracies. They are just different.
The problem for bureaucracies is that many of them, like banks, have woken up and realised they need to compete with new, digital-first competitors. But this requires them to stop being bureaucracies and start being generative. Yet that’s not how the problem is framed. It’s framed as, ‘We have to go Cloud Native’, which sounds easy. When actually, it should be framed as, ‘We have to become generative’. This is like a cat waking up and deciding to become a dog.
You recently co-wrote a book about Cloud Native patterns. Can you name three patterns that you think are especially crucial for aspiring Cloud Native leaders to adopt?
Three! I will answer this but first a warning. Cloud Native is like a jigsaw, and most pieces are needed. The danger here is treating the patterns as hacks to be quickly implemented. They are not. The act of design relies on skillfully putting the pieces together and there will be more than three!
But if you’re a leader, try this:
Dynamic strategy: Whatever you think you know about strategy formulation and reformulation probably doesn’t hold in Cloud Native. Think about the cadence of how you’d like to move forward and think in terms of experimenting to learn. Negative thoughts will come. Do not panic.
Objective setting comes after thinking carefully about what we want to do. Objective setting and strategy reformulation go together, so exercising these muscles are important.
Finally, deploy the objectives to those closest to the action. You have to learn to let go, so this is the perfect place to start as you mean to go on!
These three patterns will stand you in good stead. Many successes will grow from just putting these into regular use.
– Authored by Jamie Dobson
Jamie Dobson has more than 20 years experience as a developer and a leader, focusing most recently on strategy formulation and execution. He is co-founder and CEO of Container Solutions, a professional services company focused on Cloud Native transformation.