It’s (mostly) not the tech, it’s the people

A blog post by Mike Kavis, chief cloud architect, Deloitte Consulting LLP.

Tech is easy; people are hard. I’ve said that often enough that it’s become a mantra. The majority of blockers that slow down cloud adoption are not technology-related, but rather people- and process-related. Now, that’s not to say that building software in the cloud is easy; it’s not. However, I’ve seen so many companies really struggle more with what I think is the most difficult part of cloud adoption—getting the right combination of people and teams to run the thing and make sure it works as intended.

Teams with a T

I hear the term “full-stack engineer” thrown around liberally at most companies I work with. Full-stack refers to someone who’s fluent in all of the critical cloud skills, like distributed computing, stateless, microservices and containers, serverless, CI/CD, security, networking, and multi-or hybrid cloud. That’s a lot of skills to expect one human to master, and in my opinion, true full-stack engineers are about as common as unicorns.

Instead of waiting to spot a unicorn, companies should build teams with T-shaped workers—people who have deep knowledge of one or two tech domains (the vertical line in T) and broad knowledge of the other critical cloud skills (the horizonal line in T). For example, Shelly might have deep knowledge in containers and microservices, while Juan might be the security guru and Sam might be the networking master.

They all have a general understanding of the full stack and lean on each other’s domain knowledge to build a robust solution. What I’m getting at is that there should be full-stack teams, not engineers. Of course, this concept will require an intentional approach that requires breaking down the walls of traditional silos and rethinking rewards and incentives to drive new behaviors.

Products, not projects

And about those teams. They shouldn’t be working on projects. Huh? But the cloud is one big, long-term project, right? No, it’s actually not—or, rather, it shouldn’t be. Companies that are on a cloud journey must shift their mindset to think of their output as a product, with real customers—whether those customers are external or internal. In his book Project to Product,¹ Mik Kirsten talks about how companies must shift away from a project-based approach that views development as a cost center in that success is measured in terms of time and budget.

Instead, Kirsten suggests viewing development with a profit-center approach where success is measured in terms of business outcomes like increased sales, customer retention, new customers, etc. Such an approach can drive shorter, iterative development processes because product teams want to see real business value more quickly. In his book, Kirsten talks about seven key differences between a project and a product approach, but the bottom line is that product-based approaches speed time to market and value and create an alignment of goals across the members of the T-shaped team.

Cloud includes more than IT

The team approach and product mindset also extends beyond IT to the business. For cloud to be successful, IT can’t be the vacuum that contains it. Sure, IT will be responsible for the tech part of it, but cloud affects the entire organization—both in how it’s implemented and in how it affects other parts of the business.

For example, auditors can stop cloud adoption cold. Why? Because accounting often doesn’t account for cloud construction methods. I’ve seen auditors refuse to allow a company to use a public cloud because they couldn’t examine the physical data center, as if all the data was actually in one place instead of being distributed through many nodes across multiple data centers. To fix bottlenecks like these, it’s essential to educate other departments about cloud computing so that business processes can be redesigned to be more cloud-friendly.

I’ve also seen the opposite, where the cloud team didn’t include other, critical functions in their plans, and it nearly resulted in a disaster. For instance, I’ve seen cases where procurement processes severely delayed cloud adoption because the cloud team didn’t check what the procurement process was during the planning phases, and critical software acquisition was delayed because of an antiquated procurement process. The fix here is to communicate continuously during the cloud adoption process to ensure that key stakeholders are included in the process and know what’s coming toward them so they can address any issues that might create delays.

Talent

I’m going to circle back around to talent here, because I think people are just such a critical key to cloud success. If you’ve begun a cloud journey, you’ve probably already experienced the cloud talent shortage firsthand. It’s real, and not having the right talent—or losing the talent you manage to hire—can severely hobble any cloud project.

There are several strategies you can follow to recruit and retain top cloud talent. First, include human capital in your cloud planning process. Make sure they know the value proposition for cloud and that they have a good understanding of your cloud strategy.

For example, are you mostly lifting and shifting, or are you truly modernizing? That will determine the type of talent you hire. Also, make sure that you have really good continuing education resources for your talent. People who feel that they’re stagnating will leave. Savvy organizations build “tech colleges” to offer their talent the best in industry education to increase the chances they’ll stick around.

The bottom line

I’ll say it again: People are the most important part of your cloud journey. People perform better when they’re on teams where their contributions are critical and visibly valued. They stick around because they feel valued and they’re getting the skills they need to advance in their careers. The cloud talent market is hot, and you’ll need to make sure your organization has what it takes to get the best talent and keep it. You’ll also need to involve people from other departments in the company so that they can provide critical input into the cloud adoption process to make it a truly enterprisewide journey. If you take care of the people that run your cloud engine, I can tell you from experience that you’ll get pretty good performance out of it.

In an upcoming blog, I’ll discuss how process affects the cloud journey. And, if you like what you read in this blog, check out my latest book, Accelerating Cloud Adoption,² for more in-depth coverage of this and other topics on how to accelerate and optimize your cloud journey.

End notes

1. Mik Kirsten, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework (IT Revolution Press, 2018). ISBN-13: 978-1942788393.

2. Michael Kavis, Accelerating Cloud Adoption: Optimizing the Enterprise for Speed and Agility (O’Reilly Media, 2020). ISBN: 978-1492055952.