It’s About the People
“The story of digital transformation is a human one—one that involves as much cultural transformation as technological transformation.” — Urs Hölzle, SVP Technical Infrastructure
On the snowy Colorado day that I was sitting down to write this piece, Google’s site reliability engineering team released A Practical Guide to Cloud Migration. And right up front in the introduction, that piece of wisdom was dropped by Urs Hölzle. Achieving success in any digital transformation is as much about the people as the technology. Because after all, technology is an enabler of the ideas and motivations of the people doing the work.
I want to talk about how to increase your chances of success in cloud migration, and technology transformation in general, in three themes that are all about the people:
- Having a safe environment.
- Building the right skills.
- Hiring the right people.
The Fundamental Rules are Changing
But first, what makes technology transformation—and by extension, your cloud journey—depend so much on the right people, skills and environment?
There are a surprisingly high number of “failures” in digital transformation and cloud journeys. Why is it so hard to just get it right the first time? Are people just collectively bad at this technology thing?! That’s a weird thing to write in a post about practical steps toward a team goal, isn’t it? Former CTO at Etsy and engineering leadership thinker Kellan Elliott-McCrea has a theory that gives me hope:
“The fundamental laws of what are and are not possible change two to three times a decade right now. … If you can imagine architects who had to deal with new laws of physics two to three times a decade, they would not be as good at building buildings.”
— Kellan Elliott-McCrea: https://youtu.be/a772VLZ4ot8
Imagine trying to climb a mountain one year and everything went as expected. Imagine climbing that same mountain the next year, but gravity was one-tenth of what it was the first time you tried it. It all looks the same, but one fundamental change in the rules would really throw you off (literally … off the mountain!). Luckily, Elliott-McCrea proposes a solution: “You need a culture that supports learning. Subvert failure.” If you are always learning, you can get better at avoiding failure-like solutions that don’t address the problem.
If change is a constant, the learning must be constant. The first part of having a learning culture is hardly surprising then: It’s an environment where it is safe to take risks and to learn from experience.
A Safe Environment
Woolpert is an architecture, engineering and geospatial (AEG) company. So “a safe environment” may have you thinking hard hats and orange vests. But I’m talking about an individual’s ability to feel safe taking risks in the context of work.
This idea of reasonable risk-taking without dire consequences—called psychological safety—is a foundational dynamic of an effective team. But it can feel a little theoretical until you see it in action.
Getting Practical
Take blameless postmortems as an example of psychological safety in action. While confronting failure is rarely comfortable, having a team culture where it’s OK to dissect failure in the search of answers and improvement is very powerful. That is precisely the idea behind blameless postmortems: talk about what went wrong, not who did something wrong. Get a list of corrective actions and actually address them! The failure is now an opportunity to learn, adapt, share and improve.
That’s really hard to do in an organization where individuals don’t feel safe to say something that might sound ill-informed or disruptive. So, building that psychological safety is fundamental when the very task at hand is transformation. There are some great practical guides for this at https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/.
Building the Right Skills
The opening post of the Practical Cloud Journey series drew analogies between a journey to the cloud and climbing a 14,000-foot mountain. Developing skills and proficiency matter in both cases. You don’t “just know" how to climb a tall peak. I mean, you can try to just do it, but that is not a recipe for success. No. Instead, you take time to learn by doing or by taking structured learning ahead of time, e.g., practicing hikes and climbs in a variety of conditions and taking a first-aid class.
In the technology world, you can be similarly tactical by upskilling in specific areas as each need arises. You can be more strategic too, like offering certifications. Or you can be truly transformational with a peer-to-peer culture of sharing knowledge and even redefining jobs and roles (more on that below).
Getting Even More Practical
On Woolpert’s Cloud Solutions team, we take a practical approach. Each person has explicit learning and knowledge-sharing goals. For example, each member of our cloud team must attain or retain one relevant professional certification each year. This is good for the individual because that certification travels with them. It’s also good for clients because our folks are more skilled at their jobs. And finally, it’s great for our partnerships because we have proof of our expertise, not just an opinion that we’re good.
We also invest in a tailored skills plan that’s more personalized yet serves a strategic goal. For example, a customer engineer joined our team recently, and she has a plan around JavaScript, Google Cloud Platform training and contributing to our GeoAwareness open-source project. You don’t just “know” how to climb. You take time to learn either on the job or in a structured fashion ahead of time. We like to do both and, either way, it’s an investment.
Hiring the Right People
One of the things I mentioned in passing that can be transformational is to start defining roles differently for your cloud journey, or for digital transformation in general. Training your existing staff is a great investment. But it’s likely that you will also need to hire or contract staff who come with experience. It’s like getting an experienced mountain guide on the team rather than slowly building up that guide over time. This gives you a head start.
In his blog post, David Hollema made a case for the cloud architect role being a key initial hire, given the strong tendency for an architect to tie specific business goals to appropriate technology solutions.
In my view, another key role is a site reliability engineer (SRE), because he or she has a wonderful focus on not just how to get something shipped or shifted to the cloud, but also on thinking through needs critically. The SRE focuses on Day 2 operations, i.e., whether what you just shipped can actually be supported and meet those business goals.
Key Ingredients
It can be easy to have a buzzword-compliant list of requirements for these roles. My favorite example is when someone lists “15 years of Kubernetes experience,” when Kubernetes has not existed for that long! I’ve written elsewhere about the baseline technical skills needed for those jobs and the importance of core (or “soft") skills. For me, experience definitely counts, but the key ingredients in each person you hire for technology transformation are:
- Effective learner
- Solution oriented
- DevOps mindset
Ultimately you want to get a core team of critical thinkers who each have an open mind, a preference for “boring” solutions over the new hotness and sound technical chops.
Tying it All Together
I want to share a brief example of how all this came together for Woolpert’s Cloud Solutions team. I think it demonstrates the nexus of three fundamental pillars of success: a culture of learning in a safe environment, a well-trained staff, and the long-term result of hiring people with the right skills and mindset for this type of work.
We had been working on a project with Google, and one of the deliverables was to have the final software delivered via the Google Marketplace as a Google Kubernetes Engine-based solution. We know GKE really well, but Google Marketplace and the specialized tooling around it were new to the team.
So, how did we approach this?
First, we knew early in the project that shipping via Google Marketplace was probably our biggest risk, because it was an unknown. So, first we invested some time in an early project phase to see how it might work. This was disposable work to “gain knowledge,” and one of our technical solutions consultants, Lynda Nwankwo, covered a lot of ground, so we understood the gaps. This was a result of a learning culture: try things, share ideas, accept the false starts and gain knowledge.
Second, we realized that the core project team was missing some skills to tackle the problem that we now understood. We asked our lead SRE, Nate Wilhelm, to apply his considerable knowledge of GKE plus infrastructure-as-code (IaC) to figure out the details. It got really technical, really fast! But the prior investment in hiring the right solution-oriented problem-solvers really paid off.
What was really great to see, though, was how that knowledge was transferred in code, documentation and sharing sessions so that the technical solutions consultants delivering the project could take over with confidence.
We have delivered this project now and we learned a lot. Not everything went as expected, but that’s OK because the team’s collective experience grew. There was no blame; just knowledge gathered to avoid future pitfalls.
Embarking on or continuing a cloud journey can seem really daunting. But with the right culture, mindset and training, you can reduce the risk and maybe even enjoy that journey. In my view, it remains primarily about well-defined goals that deliver client value, and an empowered, well-trained team.