As an AWS Enterprise Strategist, I have the privilege of meeting executives from around the globe who are faced with a wide range of business and technology challenges. Each customer is unique. Many of the challenges, however, like history, tend to rhyme.
One of those rhymes is the skills challenge in the market, and the belief that not having the right people on staff stops you from moving faster, saving money, and expanding your business on the cloud. It’s certainly true that the number of job postings with the words “AWS” and “cloud” have materially increased as people realise the power of letting AWS do the undifferentiated heavy lifting in the infrastructure space. But I don’t think that this escalating demand, or the perception that you don’t have the talent that you need, should get in the way of your enterprise cloud success.
Stephen Orban, Head of Enterprise Strategy at AWS, has written convincingly about this in a recent post, “You Already Have the People You Need to Succeed With the Cloud.” And, to reinforce this point, I’d like to share the story of when I faced a major skills challenge. That was back in 2014, at the start of my cloud journey.
I was Capital One’s CTO in the UK then, and I found myself thinking deeply about the perceived skills gap in my engineers. These engineers were really talented, but they were predominantly skilled in legacy on-premise technology; as a result, they offered largely siloed infrastructure skill sets.
Seeking change, I then proceeded to make the oft-repeated mistake of creating a unicorn job specification and placing it joyfully in the external job market. I was surprised and disappointed when my job posting was met by a profound echo of silence in my inbox.
I was clearly missing a crucial fact.
The highly skilled, proactive, and dedicated team I had was the team I needed. The team members just needed a path, an incentive, and someone with empathy to listen and address their totally human fears of the technology unknown.
This realization about talent transformation and the enterprise cloud journey led to a significant amount of best practice and human learning for me. I have to be honest, though; mistakes were made and time was lost along the way. But we established a path that eventually worked and ultimately contributed to Capital One’s UK success. This contributed to helping Capital One scale its technical talent to a profoundly high level globally. In fact, a full 2 percent of all AWS-certified developers now work at Capital One.
With the benefit of hindsight here are the 12 steps that worked for us —
Step 1 — Acceptance
Mental health specialists say that acceptance is the first step toward recovery; and that’s totally applicable here, too. Your engineers must accept the fact that they have the ability to learn AWS cloud skills and become experts. It’s also incredibly important for technology leaders within your organisation to accept this. As Stephen Orban’s post explains, and as my tenure at Capital One shows, the talent you already have is the talent you need. These are the people who have many years of critical experience developing and running your existing systems.
Step 2 — Training
After this acceptance, you should then swiftly start with the AWS Technical Essentials course. This classroom course is an eye-opener, and a delightful peek into the art of the possible. It’s also excellently facilitated by AWS’ own training team, or one of our Approved Training Partners.
Step 3 — Hands-On Time
There is no compression algorithm for experience. So, hands-on time is now required. Even if it’s a little clunky, engineers need to play away and configure stuff in a safe space. Also, at this point, it feels like there are a million ways to the possible, and it’s all a bit overwhelming. Your engineers can get either very excited or slightly disillusioned. Recognition of the normal change curves everyone goes through (some are short, some are long — it’s personal) is absolutely critical. Continual encouragement is key, too.
Step 4 — Create Your Two-Pizza Team
The first engineering team you put together should consist of a thorough mix of core skills — Network, Database, Linux Server, Application, Automation, Storage, and Security. The team will make some progress. It will probably look at tools like Terraform and others. It will also write some CloudFormation code. The team will make mistakes. All of this is perfectly natural.
Step 5 — Bring in Some Experts
There is no compression algorithm for experience (continued). So, now you should bring in some real experts. Indeed, adding some expert-level engineers who have the right attitude when it comes to sharing their learnings and best practices is essential at this point. At Capital One in the UK, I worked closely with CloudReach to bring in a number of its professionally certified-level, field-proven AWS engineers to do just this. And I integrated these expert engineers into different teams to propagate specialties where they were needed. This had a transformative effect. Humans learn from other humans by watching, asking questions, and repeating. Even better, engineers like to learn from fellow engineers. And, working in small teams, they get the chance to ask questions and try things they won’t do in a classroom setting. We even got the process down to one day. During that short time frame, a new engineer joined the team, buddied up with an expert, and was then shown through the CloudFormation and associated Continual Integration/Continual Development (CI/CD) best practice that had emerged.
Step 6 — Make It Real
At this juncture, the goal of the Agile Two-Pizza Team should be to build something real and in production. This can be your foundational Amazon Machine Image (AMI) to host a small app, and associated network setup. The objective is to find something important but not critical to start with. Set the goal of getting it done in weeks, not months. Track progress. Show an interest. Set a demo deadline. And be there to see progress as well as the end results. A word of advice — don’t let the team boil the ocean here. Only work with the AWS building blocks you need. (You don’t need to master all 90+ building blocks from the get-go.) There will be plenty of time later to expand into the others as you need them for your solutions. The advantage of experimentation is key and the ability to discard and start again as many times as required to learn becomes as natural as walking with AWS.
Step 7 — Scale the Learning with Cellular Mitosis
As this first team achieves a level of AWS proficiency and delivers a product. You now need to oversee a Cellular Mitosis of this first team. And you need to gently but consciously split this first team who have gained the experience and best practise, into two new 4 person teams and then introduce 4 more engineers into each team. This will be difficult and should be handled with care. Being honest with the team members and positively acknowledging their collective achievement will be crucial. As well as asking for their help to pass on the learnings and best practise to their new teammates. Keep splitting and reform teams in this Mitosis driven approach until all engineers rotate into a team.
Step 8 — Certification
Working with either AWS Technical Training or one of our excellent partners, you can now start down the path to certification. Encouraging the use of services like A Cloud Guru can also provide engineers with a process that enables them to pass the certification in their own time and at their own pace. I advocate starting with the Associate-level certification and building up to the Professional-level certification. I am going to pause here, to stress this point. I really cannot over-emphasize the importance of this often overlooked step. At Capital One, we saw a direct correlation between engineer certification, the movement of apps and the building of new systems on AWS. Capital One even patented a process for measuring transformation. The process of certification of engineers shows demonstrable expert progression and allows the common AWS language to propagate and become the defacto method that underpins solutions.
Step 9 — Scaling the Certification and Associated Leadership
Experience at Capital One and with many of our customers — plus scientific study — has shown that you need to reach a critical mass of 10% of engineers advocating a platform before the network effect takes hold. So scaling this learning and certification to 10% of your engineers is a major milestone in your journey. From here onwards you get a compelling Halo Effect which starts to influence how your company is seen externally and not just internally. Those engineers externally to your organisation who only want to work with Cloud Native companies, will start seriously considering working for you. And so thus in turn, the pace increases exponentially of your transformation as you attract or convert more talent to be Cloud literate.
Step 10 — Recognise and Reward Expertise (In a Very Loud and Proud Way!)
You goal as an IT executive is to shout from the roof-tops the names of every engineer that passes every certification exam. Reward and recognise technical progress in any way that you can. That means — meals, vouchers, drinks, special team chair, novelty awards, you name it. At Capital One, we had a global roster of every person and every AWS certification he or she obtained. Certification was viewed as a tangible and visceral achievement. Nearly every engineer I’ve ever met craves peer respect, and certification, combined with what you build, contributes to community kudos.
Step 11 — Take the Challenge Yourself
When I was standing at a town hall meeting recognising and rewarding the engineers who had progressed, thanks to certification, one of the sharper sparks in the audience spoke up loudly. “If you believe so passionately in certification, when will you take the exam?” That stopped me pretty squarely. I hadn’t taken an industry exam for a long while. But, as somebody who likes to practice what I preach, I stepped up to the plate. And I passed my AWS Associate Architect certification exam. Now, I could proudly stand on that stage, too! Taking the exam acted as an excellent forcing mechanism, ensuring that I gained a broad, yet sufficiently detailed, overview of the key AWS building blocks.
Step 12 — Create a Unifying Job Family Portfolio
Finally, and at the right time, you will need to offer a concrete job family track for your technical employees. At Capital One UK, these are some of the job family tracks we created in IT —
Technical Program Manager (TPM) — Typically responsible for the Agile execution, release train congruence and team interdependencies.
AWS Infrastructure Engineer (IE) — Previously data center systems engineers, who were typically Linux/Wintel/Network, etc. Now creating CloudFormation code for different AWS building blocks as required for the product teams. AWS experts.
Software Development Engineer (SDE) — Writing logic and working with data constructs in a variety of software languages.
Software Quality Engineer (SQE) — Using test-driven design principles. Ensuring that testing is considered and executed throughout the lifecycle.
Security Engineer — Ensuring that security is holistic.
Engineering Manager — The manager responsible for both intent and supervising a group of engineers comprised from the above skill groups.
As you follow this path, it’s important that some glass ceilings get broken. In particular, it’s essential that engineers who don’t manage people now have the ability to get to very senior levels — including that of Director and above — and still not be managing people. These promotions should respect technical depth and associated competency development, as well as technical leadership maturity as it broadens. As a leader seeing your employees scale new heights and attain hard earned promotions is always the most rewarding part of the role. Many members of my team who took the great opportunities available proudly achieved promotion. We also broke the glass ceiling ourselves, and as I was leaving Capital One UK, one of my proudest moments was promoting a founding member of our Cloud Center of Excellence to the Infrastructure Engineering Director level. This person remains an individual contributor, hands-on AWS expert, and a good friend.
Following these 12 steps as a path to talent transformation, can unleash your teams so they achieve greatness things for your customers.
Remember — “All of your assumed constraints are debatable.”
Update 15th January 2018 — Reinvent Breakout Video of this Blog is available here https://www.youtube.com/watch?v=sO0eqTCQC8U