Enterprises are moving to the cloud because it opens up a world of opportunity; better features and functions in your applications, an ability to link technology performance to business outcomes, more productive teams internally, faster deployment – the list goes on. It’s true, in the cloud you become more agile, more cohesive and more productive than ever before, allowing you to create new digital services that can push you ahead of competitors and serve customers an experience that hits new heights. Take, for example, a modern-day insurance company, a bank or airline. The expectations on these companies are high – no longer can they sit idle and create new offerings once or twice a year. Instead, the digital race has set new benchmarks that demand them to be agile, react quickly to market changes, and launch new offerings regularly – often in a matter of days or weeks.
[ Read also: How multi-cloud and digital transformation fit together. ]
Another great example of a company dictated to by its customers is Uber. Customer service and the company’s ability to meet competitive, changing user demands is the number one priority. Since Uber burst into our lives in 2009, it’s been remarkable to see it continually meet both a market need and above all else, supersede stakeholder expectations when it comes to service. Who would have thought just a few years ago that waiting longer than two minutes for a ride was going to be considered unacceptable?
Avoid cloud transformation for the wrong reasons
Uber is a classic example of a thriving company that achieves its business objectives through rapid software releases and cloud-native technologies. And, it didn’t just become a cloud native tech company because it wanted to adopt the latest trends in tech. This was a strategic decision by the Uber founders, who established a cloud native company because the technology supported their vision for building and running the best lift service in the world.
You see, there’s no such thing as shifting to (or building in) the cloud for “tech’s sake,” but we see it so often these days. Many companies undertake massive cloud transformation for the wrong reasons. They get caught up in the misnomer that a “lift and shift” of classic services is going to make them instantly modern and give them the cloud tools they need to magically make digital transformation a reality.
20 percent of the solution is cloud adoption: The rest comes down to you.
To be successful in the cloud you need so much more than an agreement to adopt cloud technologies. The bulk of your successful strategy will come down to your company culture and willingness to shift to a NoOps mentality. NoOps means there’s no operations team. Instead, the entire engineering team works together seamlessly with the business to deploy all the way through to production.
“Quicker, better, faster, and cheaper” doesn’t happen by default when you decide to move to the cloud.
Here are two critical drivers of change that will help you to truly innovate faster and achieve your transformation goals:
1. Company culture (and internal alignment) can make or break your success
After 30 years of experience developing software and working with some of the biggest brands in the world, what I’ve learned is this: Departmental silos and rigid culture are two of the biggest things that stifle organizations, stopping them from becoming agile. Let's put some figures around it: 80 percent of the pain that organizations experience when they move to the cloud is directly related to departments being misaligned and a lack of holistic backing from the company.
To be successful in the cloud, and to build a successful innovation culture, IT can’t lead the charge alone. An organization needs a top down approach (no surprises there!) and all business functions need to work together, with common goals, clear objectives and a healthy dose of support from their leaders.
But let’s look a little closer at why you need business input on what you’re developing and prioritizing in an agile, tech-driven environment:
When organizations move to the cloud and start rapid release cycles, business teams need to be a part of the product definition and evolvement process. There’s no point engineering or developing a feature/function outside of the business’ KPIs, or prioritizing something the technical teams deem important when the business has other goals front of mind.
Support teams, engineering folks, renewal teams, technical people … they all have to be clearly instructed (and energized) to work to cohesive goals and KPIs. Otherwise you get people heading in separate directions, energy takes a dive, and your digital transformation is waning before you’ve got it off the ground.
Lastly, it’s imperative to remember that constant feedback from the outcomes you are collectively driving is another important piece to driving cultural change. Real-time monitoring of user experience, technical issues of digital services, service adoption and consumption (and more) enables real-time visibility into what’s going on in production, the impact on digital services and the business. This level of visibility and shared responsibility helps everyone see the fruits of their efforts.
2. Shifting to NoOps and bringing your teams with you
As cultural and technical changes evolve within your company and your use of cloud technologies becomes more advanced, you can take advantage of things like automation and move to a NoOps model in which software engineers, architects, and the automated tooling take on the role of operations.
As noted earlier, in the NoOps model, there’s no operations team. Instead, the entire engineering team works together seamlessly with the business to deploy all the way through to production. However, in the early stages of NoOps adoption, it’s very common to see internal teams get nervous and wary of the change – technicians are hesitant to understand the business, while the business teams are often cautious of learning operations.
So, how do you get software engineers on board to the concept of NoOps?
The single biggest thing you can do to encourage change is to give your technical teams access to the feedback from production environments. Suddenly they’ll see directly stats and output around how their feature is being adopted, even though it was just released last week. Involvement and enhancing their sense of pride in the work they do is a very powerful aide to driving your NoOps adoption plans.
Secondly, I recommend giving software architects the responsibility of production instead of letting this responsibility fall on the shoulders of Ops or DevOps teams. By giving it to software architects, you are ensuring a higher quality delivery. This team won’t want to get up in the night if their architecture breaks! This is the best motivation I’ve seen to shift a mindset to thinking about the end user’s experience, reliability, performance, security, and adoption, and it carries over to driving business-oriented and agile outcomes.
Culture and NoOps drives the autonomous cloud
Transitioning to NoOps isn’t always easy; it often requires retraining and reskilling some of those traditional ops roles. Some will need to move over to engineering, some will take on more business tasks, and others will relish the opportunity to free up their time from mundane manual tasks so they can focus on the innovation that inspires them and consequently leaps the business forward.
It’s this transition toward the autonomous cloud that truly allows companies to focus more on the business outcome and less on nurturing computers … which is where we all want to be.
[ Read also: 7 hard truths about digital transformation. ]
At the end of the day, the droves will follow what they think holds the most buzz. Everybody wants to be a part of the most trending thing and that means people will make their decisions with that in mind.
Businesses today adapt to tech advances far too quickly as they feel the need to constantly be on-the-know. This isn't something completely wrong but the abrupt progress could have its own consequences like leaving out a certain target audience for instance.