When you’re making the move to cloud, the very first thing to consider, above everything else, should be: what’s your goal? What is the thing that you’re going to deliver to showcase the value of adopting a new way of working in a different technology stack? After identifying that, everything comes down to building your team.
And it’s not as straightforward as it might seem; it’s not quite, ‘okay, we’ll get a cloud and then get a team.’ There’s also the services, the tools, processes and principles that you might decide to use around it. Which is, again, why the fundamental team is such an integral part.
Before we move into who should be your key players in this journey, I want to caveat with: You’re about to undertake a big shift in the way your organisation functions, so be prepared to adopt some patience. It might take some time to win some of these stakeholders over, it’s certainly not going to happen overnight, and that’s okay.
To start delivering real value back to the business after delivery, you need a team that is committed to seeing the process through from start to finish. Every one of these key players should be open to change, want to see real progress and, most importantly, see the value of cloud.
Because it can’t just be a team of ‘one’, you need an arsenal of ‘champion’ stakeholders to really push the initiative forward.
Your very first recruit should be someone who 1) understands cloud from a very technical perspective and 2) equally understands the operational considerations. This person should be able to act as a change agent as you move forward in this journey, helping the rest of the team and the organisation understand the changes that are happening.
The Change Champion has to be prepared to repeat themselves a lot, as they’re going to be the main go-to person for answering questions across the business, calming nerves and putting out fires.
After you’ve found your ‘Change Champion’, the next key team member to identify is an executive sponsor. Ideally this would be an executive-level stakeholder that will support transformation activities from a process perspective, but also from a budgetary perspective.
They should also serve as the ‘face’ of these changes to the rest of the business, communicating why things are happening as they’re happening. It’s critical that people across the business understand what’s going on from a business and practical perspective, rather than just with an overly-technical lens on. This will prevent a whole host of unnecessary mis-communications and misunderstandings, further supporting total organisational buy-in.
You want security on your side early, because they can either be one of your biggest champions or, conversely, shut down the use of new technology really quickly. Think of it this way: If your business is a car, the security team is in control of the brakes.
It’s wise to get them on board with the full vision: ‘these are the problems we’re seeing, this is what we’re intending to do about it, here’s how we’re going to move forward in a secure way.’ Then put them in a position where they’re helping to build and maintain that security posture.
You might initially overlook this one but, like security, it’s smart to loop in ITSM teams from the beginning for a few reasons. They’re a few layers removed from the technical trenches, so they tend to be really process driven to compensate for a lack of complete understanding about the technical sphere (i.e. the difference between collecting data in a private data centre versus retrieving data in a cloud environment).
Since they don’t naturally understand how they could or should adapt their processes to shift with the changes of cloud, they need to be brought in early to be able to get up to speed. So when the work does start to impact them, they understand how it impacts them, and how they should respond.
Developers are the ones who get value from the move to cloud. They want to get their vision out to the world, and they want cloud because it ultimately helps them connect their creations to business value, faster. Their biggest frustration is if they have to jump through hoops or face massive roadblocks in order to do that, so keeping them involved and prioritised helps them from being demoralised. It helps them realise their vision in a more direct way.
At the end of the day, they just want to see their vision of the world realised. They’re the vision provider, they’re the ones that have an idea of what comes next, so they have to be involved from the get-go.
This is the team that owns the traditional compute infrastructure and because of that they might feel threatened by cloud moving in, so getting them on board might prove tricky at first (like security).
They may not understand initially what’s being requested and might put the brakes on something that’s really beneficial. This isn’t because they want to stop progress, but it’s because they don’t understand it or feel equipped to deal with it. But they can then become the blockers to progress without knowing it.
The single biggest challenge with infrastructure teams is they’re bound to have immediate, deep-in-the-weeds questions: ‘Well, how do we do antivirus? How do we do system patching?’ They want validation of how they’re going to validate their day to day processes.
If the business is already trained with an existing team around a set prince of technology, it might seem like a scary shift, and there’s bound to be reservations and some element of fear. They might see the shift as scary or uncertain for their roles. And it’s important to manage those fears and expectations as they arise, which is again where the ‘change champion’ will step in, to engage those people in conversation and calm their fears. purpose this well-designed team of ‘champions’ will serve.
If you can manage to collect all or most of the above perspectives, you’ll be armed with a functional, prepared and complementary team to lead you through your first foray into Cloud.
