A Tale of Two Enterprises: Cloud Native & Cloud Naïve

Published on July 2, 2021 | 5 Mins Read

Six months ago, I had interesting conversations with two IT leaders of enterprise companies. Both are public companies in the financial services sector and have a similar size IT organization.They are facing challenges in terms of capturing value out of cloud-native initiatives. In particular, frustrated by not being able to:
  • Accelerate software release cycles
  • Drive down infrastructure costs
  • Avoid vendor lock-in
All are benefits of going cloud-native. Usually, at least in my experience, you can capture value on such initiatives in 3 to18 months depending on many factors that I will save for another post. 
To protect the guilty, I am going to use fictitious names here for both the IT leaders and the companies. Let us name them Alex from AlphaCorp and Bob from BetaCorp. 
In this blog post, I want to share 3 principles that IT leaders should keep in mind while investing in cloud-native initiatives.
The most common sin when it comes to cloud-native or any tech initiative in the enterprise is not taking a step back to ponder.
  • Why are we doing this?
  • What are we going to do (and not do) to get there?
  • How are we going to do it?
Not doing so indicates that either you are following the trend or working in silos. The former is dangerous because not all emerging technologies are a good fit in your enterprise. The latter is disastrous because you are wasting time, effort, and money that your competitor is either saving or investing in better projects.
After months-long discussions with Alex, I kept hearing words that indicated trouble ahead. Here are some of the signs to look for: 
  • Project mindset: Hyperfocus on scope, budget, and deadline and not results or outcomes 
  • No success criteria: Containerize all the things is not a success criterion to measure
  • Hasty cloud migration: No clear cloud strategy
Despite my attempts to work with Alex to formulate a strategy, establish success criteria, and put together a plan, I kept seeing warning signs. At that point, I thanked Alex for the opportunity and decided not to take the project. 
When you hear such signs, clearly you are on the cloud naïve road and you are destined to go nowhere. 
 
 
On the other hands, after few meetings with Bob and his team, we were able to agree on the following:

1. Vision

By taking some time to answer the aforementioned questions (why, what, and how), we were able to understand why this initiative is important to the business and make sure it is aligned with the overall business strategy and goals. Always start with the end in mind.

2. Strategy

Strategy is an overloaded term that is used a lot in the world of chess-playing, business,...etc. In a nutshell, At the corporate level, it means where the company is going to compete in the marketplace. At the business unit level, it means how we are going to do it to be able to succeed, meet our goals, and ultimately win. 
I usually take a simple approach to formulate a strategy when working with teams combining Agile + OKRs. Agile helps to adopt a product mindset and iteratively make progress. OKRs will make sure you are on the right track while making an impact. This is not for every enterprise or team, However, it worked very well for some enterprises with little or no persuasion. 
The bottom line is, If your strategy cannot be put together in one page or a mindmap, it is hard to understand. Scrap it and start over. 

3. Playbook

If the vision gives us the bird’s eye view of the journey, and the OKRs give us the direction and a way to measure progress, then the playbook will give us the set of actions to take. After this exercise, you will know exactly who is going to do what and when it is supposed to be finished. Looking back at such an experience working with Bob and his team, three things put him and his organization on the cloud-native road.
 
 

1. Taking small steps

Rome was not built in a day. You always want to start small to minimize the risk in an enterprise environment, learn your lessons along the way, and adjust your plan accordingly.
The Walk-Crawl-Run approach to technology adoption is paramount. Before building multiple Kubernetes clusters in a multi-cloud environment, you start building your first maybe on-premises, and then migrate it to one cloud. The same principle applies to application modernization, as pointed out in an earlier blog post, you start with a handful of applications (usually neither mission-critical nor business-critical) that can demonstrate value and deliver a quick win to build on.
Also, working in small teams makes a huge difference. While the optimal team size is going to be different for each organization, or project. It has been scientifically proven that small teams (4-9 people) work better, are more productive, and collaborate more with the right leadership in place.

2. Culture of experimentation 

Unlike cloud computing which is driven by the top 3 cloud providers, cloud-native is community-driven. That means that even some enterprise solutions are based on open source upstream. There are going to be lots of moving parts you have to figure out as you adopt more cloud-native technologies.
One thing that enables organizations to cope with this is to build a culture of experimentation and learning. This is what is called the  Learn-it-All culture in which everyone is always learning, might not know all the answers, and feels OK to fail sometimes. The idea here is to establish a safe container for learning and improving.

3. Product Mindset

While it is so alarming, Today 70 percent of IT Implementations aren’t successful. Some projects that are delivered on time and within budget still fail. Simply because they are solving the wrong problem.
Adopting a product mindset can help zero in the right problem and deliver outcomes while constantly improving. It shifts focus from the project deliverables, budget,...etc. to the customer of the application or platform, we’re building. 
 

 
"Culture eats strategy for breakfast" is a famous quote from the business guru Peter Drucker. It’s the cornerstone of any meaningful change inside an organization. If I’ve to pinpoint one particular reason Alex’s efforts were taking him, his team, and his organization nowhere, it’s because of culture.
Culture is to organizations as personality to humans. It is the collection of values, ideals, and attitudes that make it unique. It takes leadership, communication, training, open feedback, and years to build a strong culture.
Containers will not fix your broken culture. Cloud computing, containers, Kubernetes, and DevOps are all tools to enable an organization to win. They thrive in the right culture and can cause chaos in the wrong one. 
Assuming you spent the time and effort to build a strong culture in the enterprise, before embarking on a new initiative, take a step back to identify the vision, strategy, and playbook. Only then you can objectively gauge what might be beneficial to you and your organization. 
Previous
Previous

5 Common Kubernetes Myths Revisited

Next
Next

Cloud-Based ≠ Cloud-Native ≠ Cloud-Agnostic