Are Skills the Biggest Barrier to Cloud Adoption? A Guest Editorial by Daniel Vaughan, Cloud Native Software Architect, Mastercard

On November 30, 2022, I attended the Google Cloud Adoption Summit at Google's offices in London. C2C Global, The Google Cloud Customer Community, organized the event. Although different aspects of cloud adoption were covered, the part that stood out for me from the sessions I attended and hallway conversations was training and enablement. Enablement has never been the core of my role - - there have always been delivery, strategy or pre-sales aspects that take priority - - but it has always been a favorite.

My career's most memorable and rewarding highlights have been related to enablement. One of these was when I visited a company and met an engineer with a copy of a book I had written, full of post-its and handwritten notes in pencil. Another was the people that thanked me for the value they got from the internal Technical Seminars Program I organized at EMBL-EBI, who all went on to get great jobs in tech when their contracts ended. This direct impact on the lives of individuals is what attracts me to the work I do.

Although Google is the number three public cloud, I believe Google recognizes that a lack of skills in the market is the main factor holding back Google Cloud adoption, and is addressing this from three directions:

• The excellent top-down work Google is doing by creating great content with Developer Advocates like Stephanie Wong ( @stephr_wong ) on YouTube. The new Google Cloud Skills Boost program with Qwiklabs provides masses of quality material for an affordable yearly subscription in a way similar to how ACloudGuru did for AWS. 
• The enabling of partners for training delivery and customer enablement to meet customers at their level. This includes C2C itself. These partners complement impressively knowledgable Google customer engineers such as the ones I met at at the recent Google Cloud Next Developers Day.
• The support of the developer community to build capabilities bottom-up by encouraging them to freely experiment and learn more about Google technologies. Initiatives include Google Developer Groups (GDG) in the tech community, Google Developer Student Clubs (GDSC) in universities, Women Techmakers (WTM), and supporting Google Developer Experts (GDE).

No matter how good the technology is, without experienced people who are using it and, most importantly, can show others how to use it well, its adoption will be limited. Google recognizes and is addressing this well.

"How will there be time made for enablement, and who will do the enabling?"

At the C2C event, Deloitte talked about several alternative approaches to building skills, from building Tech Hubs (centers of excellence) in organizations with specialists that support existing teams to Cloud Academies where new entrants to the industry, often from non-traditional backgrounds, are put through extensive training. While there is great value to that later, as it brings diverse experiences into the industry, this approach must be combined with other initiatives. I cannot help but remember the "paper MCSEs" of the later 90s, where people with no industry experience paid for six-week courses that got them through Microsoft Certified System Engineer certification. This then led to many self-described "IT refugees" who left the industry as the market turned in the early 2000s and outsourcing took hold.

Sam Caley, Cloud Program Lead at Deutsche Bank, made a good point in one session: for Deutsche Bank, it's important to have a deep knowledge of the existing applications combined with cloud knowledge. This means upskilling the existing people who may have been working with these applications for the last ten years rather than bringing in new people with cloud experience alone.

I agree with Sam; with core financial systems, stability and security are non-negotiables, and a team working on a cloud migration needs to know what they are doing. There needs to be both a deep understanding of the application and experience with cloud-native principles. A lift-and-shift or even a move-and-improve is not going to cut it.

This leaves me with two questions: how will there be time made for enablement, and who will do the enabling?

In terms of time, when I led an engineering team on our first cloud-native project with Kubernetes on AWS, it took six months for the team to become comfortable with the new architecture and development style. I believe, from my experience at HCL Cloud Native Labs with Alan Flower, that ideally, I would want up to six weeks with a team working hands-on on practical projects or "Game Days", as AWS calls them as well as formal training to build capabilities.

This is a similar time investment to the people in Cloud Academies learning from scratch. Pivotal Platform Accelerate Lab for PCF, for example, which offered this type of combination of training and hands-on practice, ran for three weeks, and it was expensive. Who does the "day jobs" of the people that need to be upskilled during this time? There seems to be no slack in the system, with many organizations struggling to hire or retain enough people to keep the lights on already, so who will cover for those who are training?

Then, who will do the enabling? With the demand for skilled people, there are plenty of positions for people happy to do "just engineering" with high salaries and good conditions. Why would experienced practitioners want to add the complication of training to their capabilities? Talking to Carl Tanner ( @Grassycarl ), Google Global Head of Learning Partnerships, I learned that people who are both active, experienced practitioners and skilled trainers are few and far between, with Google, worldwide, only employing 20 of these people themselves. Google is addressing this problem through partnerships.

"No matter how good the technology is, without experienced people who are using it and, most importantly, can show others how to use it well, its adoption will be limited."

I also spoke to Mike Conner ( @Mike Conner ) of Appsbroker, one of Google's main partners in the UK, and a training provider. AppsBroker's approach is to enable the organization rather than just train individuals, which seems sensible. Establishing communities of practice to leave a legacy after training with ongoing support is a good idea. This worked well at EMBL-EBI, where after seminars and workshops, we were keen to get the people who were interested in going further into communities of practice to keep the momentum going. The issue I see, however, is Google Certified Trainers need to be affiliated with a training provider to be able to be trained themselves. As Carl told me, this means these people tend to be contractors wanting "portfolio careers" as both trainers and practitioners. This seems to be a limited pool.

Enablement is not a zero-sum game. For training providers, there is no shortage of people to train, but having trained people benefits the ecosystem as a whole. I would love to see more collaboration between partners and community groups, for example. My view for recruitment of rare, valuable skills is to nurture a community and recruit from it. Google Cloud is looking to train 40 million people in cloud skills. This is a massive number. If this is going to happen, these barriers need to continue to be removed with the people who are in a position to enable supported, utilized, and rewarded, and with resources shared as freely as possible.

In all, this was a very interesting day. I did not expect to leave with so many insights on training and enablement, but I am glad I did. This is a significant opportunity for Google Cloud, and it must apply to other cloud providers and extend to platform vendors such as IBM, Red Hat, and VMWare Tanzu, as it is more about the techniques and experience of cloud-native architecture and development than any particular implementation. As always, IT comes down to being a people issue.