Why “central cloud teams” fail (and how to save yours)

Early in my cloud career, I joined a “central cloud team” for a big enterprise. We created the automation, infrastructure, and standards for dozens of product teams who were migrating to AWS. Anybody who wanted to get to the cloud had to come through us, the experts. (This was back before the release of AWS Organizations, when large, shared AWS accounts were the norm at many shops).

Here’s the thing: we were good. I thought we didn’t need formal cloud training because we could just look up documentation to figure out new tools and services. In fact, we felt a little superior when we heard about other teams asking for special training to use the cloud. We were high-flying 10x engineers! We didn’t need all that!

Fast forward several years, though, and nearly every engineer on that team has left the company, burned out and disillusioned by their job. Worse, many of the cloud-native efforts we championed fell by the wayside. And having now worked in-house and as a consultant for many enterprises, I have seen this pattern over and over again, as up to three-quarters of cloud migrations fail despite high initial expectations.

So what went wrong?

Central cloud teams, often established at the beginning of an organization’s cloud transformation, have three common characteristics:

• They’re small relative to the rest of the IT org -- often fewer than ten people. Cloud experts are hard to find!
• They’re high-performing, the kind of engineers who can build quickly and learn by themselves. After all, that’s why they gravitated toward roles where they are constantly exposed to cutting-edge services and features.
• They operate with a high degree of autonomy. They have leeway to try new services and set best practices for the cloud organization. They often have a visionary “executive sponsor” running interference for them as well.

These teams, like mine did, think they are adhering to the Cloud Center of Excellence mindset by setting themselves up as the “cloud gatekeepers” for their organization.

And in doing so, they may create a bottleneck for the entire company’s cloud adoption efforts -- the exact opposite of their goal. That’s because centralized cloud teams do not scale.

ACG for Enterprise Cloud now includes Cloud Playground: fast, fresh, throwaway cloud environments so your team can learn by doing.

I don’t care how good at the cloud you personally are -- nobody cannot survive long-term as the sole repository of cloud knowledge for their entire organization.

Oh, it’ll be okay at first. You get to work on lots of cool stuff. And it feels good to be the cloud experts that others come to for help.

But when more teams start trying to adopt the cloud and use your guidelines, you’ll get absolutely clobbered by every engineer’s worst nightmare: support tickets. On that first job I was telling you about, every engineer on my team was eventually spending one to two scheduled days a week just triaging cries for help in Jira. Hundreds of cloud newbies who didn’t know EC2 from S3, who couldn’t figure out how to use the AWS CLI, were consuming up to 50% of our brightest (and best-paid) engineers’ time.

And as the central cloud team’s time and energy to handle support requests decreases, it has a cascading effect on the broader team’s ability to succeed.

If you’re looking for a shorthand metric to gauge the success of your cloud transformation, try support ticket volume. That’s why your best engineers get burned out and leave. It’s why cloud migrations stall. It’s a leading indicator of how successful your central team (the experts) have been at transferring their knowledge to the organization as a whole.

To paraphrase the great cloud architect William Butler Yeats: things fall apart, the central cloud team cannot hold.

The only way I know of to save the central cloud team’s sanity and speed up cloud adoption is comprehensive fluency. 

That’s right: your goal should be for everybody who builds stuff headed for the cloud, central experts or otherwise, to be able to speak cloud like it’s their native language. And I’ve got years of failures in my past to attest: that doesn’t just happen.

If central cloud teams start off small, high-performing, and autonomous, the rest of your organization is large, slow-moving, and interdependent. Everyone has legacy technologies to worry about. Cloud fluency doesn’t happen unless you make it happen.

And that’s where the central cloud team can finally shine.

Like any other organism, your cloud center of excellence will die unless it can figure out how to reproduce. Fundamentally, the central cloud team has to change their mission from expertise (knowing the most about cloud) to enablement (creating more people who know about cloud). 

Embed experts with product teams

You wouldn’t put all your servers in one availability zone, so don’t put all your knowledge on the central cloud team.

Set up a rotation that assigns your central cloud experts directly to the product teams that need them most. Through daily standups, code reviews, and pair programming, they can help raise the maturity of your teams in real time.

The USA used the same tactic to win the air war in World War II: they sent their best pilots home to train others, while the Germans kept their aces on the front lines until they were shot down.

When one team reaches an acceptable baseline of fluency, you can reassign the expert, like a flight instructor moving on to a new crop of recruits. Channeling expertise into enablement keeps your entire team in fighting shape.

Create baselines of cloud fluency

The central cloud team’s expertise is still essential to define that fluency baseline, so lay out your security, automation, and tooling standards in a place where everyone can access them.

You should also identify the cloud services everyone is expected to understand. If you’re in AWS, a good shortlist would likely include foundational services like IAM, VPC, and CloudFormation.

Many teams I’ve worked with require product teams to demonstrate their grasp of these baselines before they get access to their own cloud environments. But you need more validation than just a “thumbs up, I read the docs”. That’s where certification comes in.

Provide clear training and certification paths

Many ACG customers assign a foundational course like the AWS Certified Solutions Architect Associate course as part of onboarding for all new engineering hires. Whether or not everyone goes on to sit the certification exam, working through the course material creates a “lingua franca” for the cloud -- a shared language everybody speaks.

But beyond the shared baseline, it’s also a good idea to match the right training to the right roles. Architects and developers need different expertise than data engineers or infosec. Look at something like ACG’s Learning Paths to lay out standardized plans that fit a variety of competencies.

Establish support and incentives

People learn best when they are motivated to succeed. So establish study groups and Slack channels to support your learners. Lean into goofy ceremonies to congratulate people who achieve the big cert. (A Cloud Guru has a “Wall of Fame” in our Austin office where we post Polaroids of every employee who achieves a certification.) Positive peer pressure works wonders!

The best incentive, though, is the cloud itself. You hired good people, they want to get work done in the cloud. Set the prerequisites for them to demonstrate competence, and they’ll rise to the challenge -- 93% of IT managers find that certified employees provide value above and beyond the cost of skilling up.

Download Why Cloud Certs, Why Now? to discover the many ways cloud certifications create value for your business. Get the goods!

The most surprising thing I’ve learned about cloud adoption in the last ten years? Your experts need training just as much as anyone else. Not so much for their own information, but for the teams they are guiding to the cloud. It’s the only way to protect their sanity and scale your cloud adoption.

To quote another cloud engineer, Robert Frost: some say the world will end in fire, some say in ice. But without comprehensive fluency, the central cloud team is sure to drown in support requests.

Take my word for it. I think I’m still assigned a Jira ticket from 2015 that just says “need help with AWS.”

Forrest Brazeal is an AWS Serverless Hero and enterprise architect who has led cloud adoption initiatives for companies ranging from startups to the Fortune 50.