Transcript
Joel Parks 0:09
Hello and welcome to Cloud Unplugged, the show where we take a lighthearted and honest look at the who, what, when, where, why, how and OMGs of cloud computing. Welcome to Episode Two. In this episode, we’re going to take a look at some more news articles. We’ll also get into our topic of the day which is building the team once you know where to get started. How do you build the team?
I am Joel parks and with me of course is Jon Shanks.
Jon Shanks 0:35
Hello everybody. It’s Jon Shanks here.
Joel Parks 0:38
So how has your week been, Jon? How are you?
Jon Shanks 0:42
I am good. It’s been it’s been a good week because it’s been a holiday week. So it’s been bank holiday here. British style weather all the way through. So basically Monday wash out. But had a little bit of a hangover, so it’s kind of fine.
Joel Parks 1:01
Yeah, well, there you go. You got an extra cushion. My weekend was great. Actually, I got out now that restrictions are beginning to lift here in the US. I got out for the first soccer match of the of the year for me was Nashville FC versus Miami, which was a pretty good game.
Jon Shanks 1:20
And how was the environment there with the limited people? Did it have the same…
Joel Parks 1:26
It was good. Yeah, it was good. I was in the supporter section, so we’re fairly noisy and had a good time. However, everyone was socially distanced. Everyone was masked, I think everybody was for the most part on best behaviour. So that was a plus. The only downside of the entire deal is because I’ve been indoors effectively for a year and a half, I’m a little bit like a vampire. So the sun came out, and I immediately turned to dust, you know. So I have a horrible sunburn that I’m nursing, but apart from that, all good. It was a great game.
Jon Shanks 2:00
That’s really good. Just a stadium full of flames as everyone combusted.
Joel Parks 2:06
Yeah! And as Nashville weather it goes, it wasn’t even particularly hot. It’s just, you know, my incredibly fragile indoor-kid skin. At this point, it’s just not reacting well to ultraviolet light. Yeah. So from there, let’s jump straight into the news.
So this week, we’ve got three more articles, all touching on different aspects of the cloud. And all were sort of interesting to me on one level or another. The first one is the Cloud Native Computing Foundation, CNCF, has honoured Spotify as a I wonder what do they call here in recognition of its notable contributions to the cloud native ecosystem, which is not a huge surprise. I mean, Spotify has been a big supporter of a lot of the CNCF projects from the very beginning. They’ve been big champions of DevOps and cloud ways of thinking. So this, this was an award that was given to somebody that’s quite deserving, in my view. What do you think about that, Jon?
Jon Shanks 3:14
Yeah, definitely. I know they’re heavily big users and contributors to quite a lot of projects. Not just Kubernetes, but Argo, I think, but, I guess, probably quite a lot of companies are nowadays. But they’re very much early adopters on a lot of this stuff, so yeah, it’s pretty good.
Joel Parks 3:33
Yeah, there’s a list that Argo, FluentD, OPA, GRPC, Envoy, and Kubernetes are their top contributions back to the community. So you know, good for Spotify. That’s a well earned recognition. The second story is out of our friends at Microsoft. They are really doubling down on their hybrid cloud approach. They’re talking about ‘our approach has not fundamentally changed. We’re just not building a cloud or a product, we’re solving a customer’s real business problems.’ And they go on to mention specifically Azure Arc, which is what caught my eye. So what they’re talking about here is the ability to run Microsoft specific or Azure specific workloads on other cloud providers. So they go on to mention specifically if you want as Azure SQL, you can run it inside of AWS, you can run it inside of Google should you choose to. Now I have some thoughts about this, but I kind of want your first impressions, Jon. How does this strike you?
Jon Shanks 4:34
Well I just love paying twice. Do you?
Joel Parks 4:40
Okay, you caught the first thing that caught my attention!
Jon Shanks 4:45
Yeah, I mean, maybe a I’m like missing something, but it feels an odd situation. I mean, maybe I just don’t get it. I’m missing the hook but why you’d want to pay for the the kind of capacity and everything else going on one side, but then also pay for the service management somewhere else just feels slightly strange to me personally.
Joel Parks 5:08
Well, yeah, so that a couple of things hit me about this. First of all, so I kind of understand what they’re trying to do. They have customers who have a hard reliance on Microsoft SQL, I think they want to make SQL as easily consumable as possible across all the cloud environments. That objective I get. This sort of cross pollination of cloud technologies on top of other ones. And Azure Arc isn’t the only one, the only example of a technology like this. Anthos is definitely in that same ballpark. But it strikes me as, okay, so they’re doubling down on this. Why would that be? What are they seeing that’s making them take this approach? You know, is this a tacit acknowledgement from Microsoft’s point of view that they’re not going to directly catch AWS? In other words, is this a way for them to say, hey, Microsoft software, you can run it wherever you want to run software, make things very consumable? That would make sense given their history. Because that was sort of their mission statement ages ago. But it’s sort of a head scratcher to me in a both from the cost perspective? Are they trying to get into a feature by feature, you know, comparison or war with, you know, like, what’s actually fueling that?
Jon Shanks 6:30
Yeah, it feels like more like if your primary cloud is then first. And then you want to go and run a few things somewhere else for whatever, for whatever rationale that might be? I’m not sure. Maybe there’s like, a data centre that only Amazon might have in a certain region that kind of motivates a business. This is my logic. I mean, this is totally not necessarily true. But this is where I could go. This is where it might make more sense.
Joel Parks 6:58
We’re back to, you know, guys sitting in smoking jackets with their pipes, right?
Jon Shanks 7:03
Yeah, this is it.
Joel Parks 7:03
This is a total wild speculation on our part
Just absolutely speculation. I’m sure everybody else is just like, what are they on about? But yeah, basically, if you’ve already decided that your primary cloud is, I don’t know, maybe Google, and you’ve got maybe some on prem, but then you kind of want to branch off a little bit into do some new grammes. If for whatever reason, then you’ve got some consistencies. It feels like if your primary is that, but then you want to do a little bit over there, then maybe it kind of makes sense for that little bit of consistency. But yeah.
Or are they going the other way around of letting you cherry pick Microsoft technologies to layer on something else?
Jon Shanks 7:40
They’re not really their own technologies massively a lot of the time. They’re, like, just normal open source? I mean, let’s not really go there. But a lot of them are adapted technologies of the industries. So, it’s kind of like, are they there’s, you know, sometimes they are, but a lot of the time, they’re kind of just industry wrapped technologies, right?
Joel Parks 8:00
Yeah, so I at this one’s genuinely, like, I don’t quite understand what that what the tack is here. I understand what they’re saying, but the motivation behind it is a little bit of a mystery to me. So anyway, if you’re listening and you have insight into you know, you’re the, you’re the target customer for this functionality, I would love to hear what your use case is, and how this applies to you.
So moving on to our third story, after my dig last week at Amazon, and their two service names. This is not a joke, I’ll preface that right up front, Amazon has unveiled a new service, they announced the general availability of Amazon DevOps Guru, a fully managed operation service that uses machine learning to make it easier for developers to improve application availability by automatically detecting operational issues and recommending specific actions for remediation. So yeah, this one struck me as super interesting. Now if this was, and by the way, this article was effective as of yesterday, so as of this recording, that is May 4th. So we’ll see how this actually takes hold and how it gets some use, but on the face of it this seems like a pretty neat solution for you know, helping your your DevOps teams or your your interdisciplinary teams, giving them a little bit of a boost and helping them with some of their operational issues and possibly logging, alerting, etc.
Jon Shanks 9:34
Yeah, I mean, it sounds good. Kind of interesting that they went for DevOps Guru, and not SRE which it kind of feels like it’s more aligned to…
Joel Parks 9:42
Ooooh, careful. This is like Star Wars / Star Trek debate now.
Jon Shanks 9:48
I don’t know, it does sound very good. I mean, these are like the most common problems, aren’t they? People just having a bit of a nudge up into the right direction and making a little bit easier kind of makes a lot of sense for them. They’re already kind of tiptoeing into that space. So it feels like the next evolution but kind of intriguing that they’re, they’re representing a kind of persona as a service inside of their offering How then that’s one of a new one. Yeah,
Joel Parks 10:13
The way that I took, or what I took away from it was, they are definitely recognising the need of providing, you know, they up to now they’ve had very written document based best practices, right? That has begun to translate out into tooling that is an expression of that best practice. The first one I can think of is lighthouse. So now you get best practice expressed as a tool for how you do account structure. Now, they’re sort of foraying into more of some operational considerations around how applications run what to do when they start potentially going sideways. And I think that is great, you know, making that that best practice or that expertise directly consumable. And very actionable. I think that’s fantastic. We’ll obviously lot to be done. There’s a it’s a very young product still. So we’ll see how people adopted over time, but on the face of it, it looks great.
Jon Shanks 11:11
Yeah, if anyone’s using it, that’d be like, if there are some early adopters of it, it’d be great to know how it stacks up. If it meets the brand name in its feature, richness. So yeah, let us know how you’re getting on with that service, because I’m intrigued to know.
Joel Parks 11:31
Yeah, we’re looking for product reviewers here. And yeah, so if you’d like to raise your hand and volunteer, please do so.
Jon Shanks 11:38
That’s just because we’re too lazy to do it ourselves, basically.
Joel Parks 11:43
Crowdsourcing!
Crowdsourcing is what we’re gonna do. So that’s the end of the news. So we’ll move right on to our our main topic today, which is building the team.
So where we left off last week, we were talking about getting started. How do you scope the work to be contained in something that you can reasonably communicate amongst the various stakeholders? But also, what is the goal? What is the thing that you’re going to deliver as part of that first pass of showing how cloud can can work in your organisation and really showing the value of adopting a new way of working in a different technology stack. But everything really comes back to you need a team. This is not an individual effort. It’s just too big than that. So you know, when we talk about building the team, I think we’ve got a lot of stuff that we’ve sort of pencilled in to talk about today. But I think the first thing that I want to say is, if you’re in this situation, and you’re beginning the process of assembling, sort of Avengers Assemble, you know, getting your first team together to do this. The one thing I want to tell you right up front is: Be patient. And don’t be discouraged. Because you’re effectively making a huge shift in the way that the organisation functions, you know, you’re sort of rewiring aspects of the way the organisation works. And it’s going to take some time to win people over to seeing the value and wanting to participate. So with all the things that we’re talking about today, just know that it’s probably not going to happen overnight. And there are going to be times where you’re going to get frustrated, but that’s okay. That’s actually normal. So I don’t know if that resonates with your experience, Jon, but it definitely does with mine.
Jon Shanks 13:33
Yeah, definitely. And also, it’s not as straightforward as it seems, right? I mean, we say it as if it’s, you know, get a team and there is this cloud and kind of knock yourself out. I mean, it’s like this, there’s a lot to not just the services, but then the tools that you might decide to use around it. And then the processes that you kind of want to use around it, and then doing infrastructure as code and all these other kind of principles that sit around it that maybe you’ve done before in bits, or maybe you did so much. But you know, I guess the whole approach around it as much as just the delivery isn’t quite as black and white as it seems. It’s not that you can kind of click a few buttons and off you go and done.
Joel Parks 14:17
Yeah itcan it can feel, for those Southpark fans that are listening, it can feel a little bit at times, like the ‘underpants gnomes’ logic, which is step one: collect underpants, step two: question mark, step three: profit. Right? It’s that middle bit that’s really important. And the first step in that middle bit of connecting, you know, the business value to the activity is galvanising a team that’s really committed to seeing this through and not just through on an experimental basis, but seeing it through end to end like we talked about last time. You know, something that really shows a fully operationalized thing. Right. Whatever that thing is for you in a context where business value can actually be derived from it. Not a science project, not somebody’s pet project, but something that actually generates revenue or business value or returns time back to the company. Something that you can attach some dollars, cents, pounds to. Would you agree with that?
Jon Shanks 15:18
Yeah, definitely. I think, yeah, when we were speaking last time, it was about trying to find the right candidate. I tried to find some sort of team that’s kind of open to change isn’t going to kind of resist change who, you know, want to see progress. They want to see the value of cloud be recognised with their project. But then it’s then like, who specifically leads on this? You know what I mean, where’s the expertise coming from? Is it promotion or within the business? Are you going to stick people on some courses? Are you going to try and trade within? Do you get some external body in? You know, these are all the kind of considerations. Do you outsource it completely? So yeah, it’s quite complicated on the different approaches. I’m not sure what what you would advise Joel, on somebody to take, that you’d recommend as an approach, because obviously there’s various things you could do?
Joel Parks 16:12
Yeah, so my personal, and I already teased this a little bit, my personal preference is to start with the what, and what specifically is, what is the team going to deliver? You don’t necessarily have to know all the names and the people yet. But at the end of the day, when the team is successful, what does success look like, defining that success criteria, because then you’re not in a boiling the ocean mode, where everything is up for grabs. You have a very defined target, it’s like playing darts, you know where the bull’s eye is. So establish that and use it to frame the conversations. Now, this feeds very cleanly from our discussion last week around scoping that effort. And we touched on a few things about, you know, not boiling the ocean, make it something that’s contained, you know, possibly seeking a specific line of business or some group within the organisation that has a very defined target or deliverable that you can, that the team can come along and support them in that. Or possibly, you know, taking something that was originally devised or created in a Shadow IT mod, in a sort of a skunk work mode, and maturing that and bringing it to fruition into something that’s not just a skunk works type thing, but can actually be operationalized and fully used by the business. So,
I mean, that’s sort of where we left off. But in connecting that back to the team, having that first definition of what success looks like, is pretty critical. I know, from my perspective, some things that I would advise to be wary of right up front. The first one is, you know, let’s just face it: mainframes, are still in use in a lot of organisations, and they serve very business critical functions. If the functionality in question touches the mainframe, think long and hard, because there’s going to be a lot of entanglements that you’ll have to deal with, and almost everything is going to have a very stringent or very strict downtime consideration. And maybe that’s not the place to go. I mean, what would you advise there in the sense of setting that definition of success?
Jon Shanks 18:40
Yeah, I think the less dependencies to your kind of current infrastructure, the better, you know. I think there’s a tendency to design based on what you know, so when people think, they don’t think in terms of like, service, and then how do we address, you know, like, I’ve got a dependency on service x, is this this app? Instead, it’s like, oh, this app has a dependency on this network. So we need to get this network in, right. So it’s like, well, it kind of doesn’t, it has a dependency on a service of which maybe you need to kind of expose it somehow or do something differently, that doesn’t kind of couple you back in. So you kind of try to treat the cloud as an extension of your data centre already. Like the approaches already slightly off. So I think, you know, trying to make sure that you’re thinking outside the box on the approach and not letting your history repeat itself a little bit on how you’re thinking about the design. And I think sometimes that’s a bit too much too soon for some people. So sometimes it’s choosing something we’ve already built dependencies, just a bit of a safer bet, because it’s a bit more decoupled.
Joel Parks 19:47
Yeah, net new development, something that’s very cleanly. We’re going to add a new word to the dictionary: ring-fence-able
Jon Shanks 19:53
Ring-fencable. That’s a good one.
Joel Parks 19:57
Yeah, something you can draw very clean line around that doesnt’ have too many of those dependencies that you were mentioning. That’s a good move. Another one is, you know, if you’re going to refactor something that already exists, make sure that it’s something that’s well understood. One problem that I’ve seen over and over again, is there’s a strong desire to refactor legacy applications into a cloud context. That’s a good impulse. When you’re first starting out, you need something that’s well understood so that you can really get better at how you do this. This is a little bit of a practice makes perfect manoeuvre. If it’s something that was developed an awfully long time ago that’s very complex and maybe a lot of the developers that were originally involved are no longer with the company or knowledge has kind of left the teams grasp, you know that may be another contra indicator of like, Alright, this isn’t the right thing to zero in on. Pick something that’s relatively new, something that’s well understood.
Jon Shanks 21:00
Yeah. And I think if it’s a process, because it is, this is the thing is that what you’re saying is like, what are you trying to prove? If you’re trying to prove based on an outcome, which is like, ‘Hey, we want to get to cloud with this new app.’ That’s one thing but then if all the processes around it are changing, too, and the technologies to deliver it are also changing. And then the makeup of the team is also changing? Sometimes it’s like so much change that you start to kind of lose focus a little bit. It’s like, actually, maybe just climatizing to how do you automate in cloud first, right? So like, what’s just a normal standard best practice of automating because that automation is going to speed up the delivery overall as an outcome. So let’s just focus on that first. And let’s not worry about anything else. It’s just try and nail some automation with the right tools with something really simple and build on that, and extend that towards the outcome rather than maybe trying to change absolutely everything all at once. But it’s kind of just maybe just too much for a lot of people.
Joel Parks 21:59
Yeah, absolutely. I mean, there’s, in really at this stage of the game, if you’re just starting out, I would encourage you more than anything. And we were providing some pointers or things to look for. But ultimately, this all distills to reduce complexity, as much as possible. Get this down to something that is contained that is bite-sized, that can actually be worked by the team in a fairly autonomous way. Right? If you’ve got a lot of dependencies, and there’s, there’s other applications involved, especially if they’re very old or very established applications, you’re going to find the ability to inject change, you know, to try something new, that you’re going to continue to trip over legacy process, because that process is there to protect the system that’s generating a lot of business revenue. So if you start trying to pick that apart, first, you’re going to hit a lot of roadblocks that probably aren’t productive, in the sense of teaching the team how to do things in a different way. So pick something that you that you can really contain that you can reduce the complexity on and where there’s a clear definition of success. Right? If it’s at all fuzzy, or you can’t assign, some dollars and cents to it, it’s going to be difficult. And if you have the option, pick something that is that is very, that has a high user impact, that’s very user or application focused, rather than something that’s sort of inwardly focused. That’s maybe more infrastructure defined, you know, find something that has a broad impact at the application level, rather than, moving some internal tool that is specific to us a single domain within the organisation.
Jon Shanks 23:54
Yeah, exactly. And I think if you’ve got, if you’ve got somebody you’ve identified, that you know, is going to like you’re saying is going to prove the value. I think having someone that knows what good looks like, already, in relation to cloud is kind of essential. Because I guess, I guess you could kind of go in it on your own, and figure it out through a process of elimination, courses that teach you how to use the cloud. But when it gets to the tools and the technology, you’re not really, nobody’s in the GUI. I mean, maybe you are and, you know, and apologies if you are. That’s a whole other problem if that’s what’s going on, but you know, no one’s clicking around in the GUI all day, you know, provisioning infrastructure. There needs to be some, you know, immutability to it and some repetition and automation etc.
And so those principles, obviously, somebody that’s experienced in understanding the principles, not just as a theoretical thing, but like, why they exist, you know, like, why they’re important and tools that help with that, in the right way that do a good job on solving those problems is kind of key. Because that’s gonna save you so much time. I mean, everyone’s got a little bit of an opinion anyway, it’ll all be slightly subjective. But it will speed up the process anyway. And it’ll train others, and they can kind of educate on the why because cloud, from their view, you’re just there to consume us and here’s the documentation how to do it. But it won’t tell you why, you know, why are these industry standards in place? Because they kind of leave that down to the industry or that discipline. So you might not cover all of the why, but you’ll know the what, do you know what I mean?
Joel Parks 25:38
Yeah, and I think you’re, you’re hitting on exactly the next thing. Is once you have that definition of success in hand, and you know what success looks like, that constrains the problem and the discussion to a specific application, a specific deliverable that you’re now going to be focused on. And what Jon was describing is really the first member of that team, the first critical recruit to our new team and that’s the Change Champion, someone who understands cloud, understands the technical side of it, but also understands the operational considerations and can act as a change agent moving forward and help explain these changes and contextualise them for the other stakeholders that are going to be involved.
Because it won’t just be a team of one as we said before, it will be a group effort in order to make this happen. So you need the Change Champion. That is recruit number one. Immediately behind that there’s a number of other people we’re going to need to recruit to our side to make real flag-waving sort of champions of what we’re trying to do. I would submit that, you know, apart from the change champion, the next person that you really have to have involved is a business stakeholder that is willing to get behind and, from hopefully an executive level, support the activities that are being undertaken, both from a process perspective, but also from a budgetary perspective.
Jon Shanks 27:12
Yeah, definitely. And a comms person, I think, I think people forget that. Because if you’re trying to take the industry, your entire business. through the process, you do need decent comms to explain, you know, why things are happening, the way they’re happening, you know, what’s going on. And I think everybody kind of misses that piece. And I think the communication and making sure everybody kind of understands in the right way is kind of critical. Otherwise it can, it could be very technical, you know, in its approach, it could be very technically driven, with then a bit of a business outcome. But then it all gets a bit murky, unless somebody is kind of really embodying what the change really means as a communication back to the business.
Joel Parks 27:55
Right. Yeah, exactly. So having the Change Champion, and a business or an executive sponsor that can come together that can agree on that definition of success and say, ‘Yes, we are going to, as a team, allocate resources that are dedicated to moving this through the process.’ And moving towards that definition of success is super critical.
Now, that’s not the only perspectives we’ll need to capture. So what I’ve got, I’ve got a list of things here, I came armed with a list. So what I what I thought we could do is just throw out some of these other perspectives and have a chat about the each of their considerations what they might be thinking coming into a team like this, as well as why it’s critical to capture that that perspective. So the first one we’ve already talked about is the Change Champion. The second one is the business or the executive sponsor that can handle the comms issues and help, you know, drive the project forward to success. I would say right behind that one is security. Jon?
Jon Shanks 29:01
No.
Joel Parks 29:01
No?
Jon Shanks 29:02
I’m joking, no, I agree. I think I think security definitely needs to be involved straight away. I think also service. So yeah, security, security definitely.
Joel Parks 29:14
They’re on the list, too.
Jon Shanks 29:16
Yeah, I guess it depends with service if it’s something already in service versus something already new. And maybe the same a little bit with security, if it’s something that you’re moving versus something kind of new. Obviously, when it’s new, it’s sometimes you don’t know what the end state even looks like properly for yourself, maybe as a product if it’s new. Anyway, you’re kind of in discovery and alpha and iterating through. So that might be less contentious then from a security perspective versus suddenly with a lot of assets that’s highly secure, already, you know.
Joel Parks 29:48
So the reason I would put security as that next critical recruit, or next critical hire, is for this reason alone: Regardless of the size of the organisation, security is in a unique position to either very strongly champion lines of work and lines of thinking and different ways of using technology or, in the worst case, they’re in a position to absolutely stop something cold in its tracks. Right?
They have, if you want to think of it this way, you know, if the organisation is a car, they have the brakes. And they have almost unlimited control of the brakes. So if we don’t, from a purely political level, if we don’t recruit security early, and win them over to not only the the what we intend to do, but the why that sits behind it, you know, this is, this is why we want to try and things in a different way, these are the problems that we see that this we believe that to solve, here’s how we intend to move forward in a secure way, we want you to help us maintain that security posture, all through the process, you know, making them a really first class owner of what’s going on. Unless they get that level of involvement, the risk is that they will feel that they’ve been bypassed, and stomp on the brakes.
Jon Shanks 31:14
Yeah, I think there’s a difficult bit in this, though, this is maybe a little bit controversial but I’m not sure of it. But there are different schools of thought when it comes to security. I think if security has a bunch of requirements that need to be met, that’s one thing, which is like this, these are the surrounding requirements for security around this data that we need to kind of see, here’s some principles and SM standards, these are the things we need in place to know that you can operate in a secure way as much as just do security. That’s one thing. But then sometimes you do have security, individuals that maybe come with solutions, and not really requirements. And sometimes that can be misinformed slightly when they don’t understand the technology well enough. And that can then create the friction because they’re coming with a solution in mind that maybe is I don’t know, maybe it’s a, an internet gateway or something they’ve used historically, or an API gateway is like something that they’ve some piece of technology that they’ve historically used, that ticks a compliance box that they want to see now in cloud. And so they’re steering already with a solution in mind to the problem that makes them feel comfortable because they understand that. So that can then cause the problems because obviously there is already security in the cloud that can be achieved in maybe the right way, rather than just kind of getting a cloud appliance that you’re now going to buy inside of the cloud. Right. So.
Joel Parks 32:48
Right? Yeah. So that’s when I when I mentioned right up front, don’t get discouraged, right. This is this is normal. These are the types of conversations that could lead to somebody that’s the Change Chamption in the organisation getting really demoralised is, you know, we involve security, and they come with a ready made solution that doesn’t really fit what we’re trying to do. The good news there is if they’re engaging in the conversation with you, it means that they are invested in what you’re trying to accomplish, right? And what stands between you and the the solution that you hope to affect may simply just be one of education. Yeah, and that’s probably not going to happen overnight. But that’s where the patience aspect really creeps back in to say, okay, they’re not saying no, they’re saying, well, what about this? That gives you the opportunity to come back and say, Yes, I see what you’re saying .. ut what about this? And propose an alternative, right?
Or inverting it in the fact that that that solution, you know, I guess inverting the conversation to be like, what outcome does this solution give you? Like, what set of requirements does this solution kind of protect? It’s not whether it’s right or wrong? It’s just like, what does this thing do really well, like? What are the requirements that it drives?
Yeah, why do we own this technology to begin with? What what drove us to purchase it the first time?
Jon Shanks 34:12
Exactly, right. Because that that informs the outcome, you’re striving for really underneath rather than just talking about solutions, and it’s just healthy to kind of revisit, like, why did we buy this? You know, it’s not, because you’re in the danger of this solution versus that solution type of argument. I think, you know, we’ve all seen it before too many times, to be honest. But, you know, it’s sometimes it’s better to wind back and be like, well, can we meet these requirements, again, in a maybe more cost effective way for the business. And it’s not about who’s right and wrong. It’s just about getting the right outcome for the business.
Joel Parks 34:46
Right. And that touches perfectly on the thing that I was I was hoping we were going to get to which is sometimes specifically with security teams, you need to you need to provide them with some alternatives and help them understand that, you know, we can either talk about requirements and problems or mitigations. Or we can talk about implementations. It’s better to stay in the realm of here’s the requirements, here’s what the tool, regardless of what it is, needs to be able to do. Right? And then have the implementation conversation rather than starting with, well, our firewall vendor of choice has a virtual edition. So I guess we’ll use that. Okay, that’s, like I get that. We’re all comfortable with the technology we know best, right? And that’s usually what we lead with. But it gives you an opportunity to say yes, if we were doing it in an on prem context, or in something else, maybe that does make sense. But hey, let’s, for the sake of completeness, have a conversation about the ways that cloud providers go about solving the same problem? What is it that they do to solve the same problem? Because it’s not like they don’t have it? They do? Right? They just solve it in a different way. Yeah. So if you can sort of steer the conversation that way, I’ve found that to be fairly productive. But I do acknowledge that, you know, sometimes that is an exercise in repeating yourself. And if there’s any word of encouragement I could give to any cloud architects or change champions out there. It’s just be ready to repeat yourself a lot.
Jon Shanks 36:26
Yeah. Record yourself. Yeah, just record yourself and just keep rewinding.
Joel Parks 36:33
Have a podcast! You know, at the end of the day, that is sort of the game is winning hearts and minds, and winning hearts and minds requires you to sort of make the same case over and over. And it can be exhausting, but if you’re committed to moving things that direction, then I think you’ll find if you make the case in a in an aboveboard way, and you involve people early and offer them a stakeholder role in what you’re doing. A lot of the objections will melt with education.
Jon Shanks 37:05
Now I do have yet another controversy piece number two.
Joel Parks 37:09
Red alert!
Jon Shanks 37:10
I know exactly, I’m like constantly derailing you here Joel. But this maybe applies to not just security, but just generally across the board. If the business is trained already, and as a team that exists, that is based around a set piece of technology, and that team can see the usage of that technology shrinking in exchange for something else of which maybe skill isn’t in that area. Right? There’s gonna be a natural kind of caution of like, oh, like, what is like, what does this mean to me? So we’re not going to be using all the things that we normally use, which is what we’re trained on, we do have a team already. What does this now mean to the team? You know, and so there is this kind of like alert that probably goes off in people of like, whoa, okay, so things are moving. What’s your take on, like, how do you how do you address those freakout moments maybe wherepeople might not even say it out loud, either, you know, they want to embrace the change, but there’s bound to be an element of fear.
Joel Parks 38:14
Yeah, I mean, there’s, I would put it with just a blanket statement. And this is held true. In every organisation I’ve been in, right there is this great fear in the minds of a lot of people that if their technology changes, or if the organisation goes to cloud, then suddenly everyone’s going to be out of a job. Because there is a lot of talk in the industry about, oh, well, it reduces headcount and does all that stuff.
I’ve never found that to be true. I think there it does cause some people to fall out of the organisation, not because their job has been eliminated, but because they refuse to learn the new way of thinking, or the new way of doing things. Right? So if you plant your feet in concrete and say, I’m not going to adapt, I sort of on a baseline question whether technology is the right business for you to be in anyway, to be honest. But you know, that’s that’s just not going to work out. Well, what I’ve found is it doesn’t result in an outright reduction in headcount. What it typically does is it rewrites a bunch of people’s job descriptions. So it’s not that your job is going to go away. But your job description and the things that you are responsible for on a day to day basis are likely to change. So I would sort of diffuse that argument by saying I’ve never seen it play out that way. I’ve seen it happen a bunch in a lot of different contexts and a lot of different industries. And it’s just not. It’s just not generally what happens.
Jon Shanks 39:51
No, I guess, yeah, you’re right. I guess people might drop out because they haven’t re- skilled at either A) because they didn’t really want to, you know, maybe they just want to reskill. And if they don’t, then then people do drop out obviously for that reason, but the second is the fact that I suppose there’s something new in exchange for the old. So it’s not that the old is just.
Joel Parks 40:16
Oh, certainly, yes.
Jon Shanks 40:18
Like, oh, the old is just gone. The end.
Joel Parks 40:20
Well, it also, I think, a lot of people, especially if it’s in the context of, you know, a new effort to move to cloud, right? I think people underestimate, or no, not underestimate overestimate how fast that transition actually takes, right? It’s this is a journey, it’s not going to happen overnight, in almost every case. And if you already have invested in technologies that make sense in the private data centre, where, let’s be honest, all your money at that point really is being generated and processed, then those technologies aren’t going away overnight, right. You’ve got a long tail of work, that’s going to be required to fully transition away from some of those legacy technologies.
So you know, there’s there’s going to be a continued need for people that are skilled with those technologies and keep the the private data centre running effectively while the transition happens. But again, you know, from a training point of view, that’s why it’s really critical to have a an executive or a business level sponsor involved, because they will be very keen and tuned into those sort of like rescaling or retention issues. And having them involved early in the conversations to sort of catch that and formulate a plan for a skill set transition, or how we’re going to evolve the teams over time is going to read out to everyone’s benefit in terms of, you know, actually hitting the target.
Jon Shanks 41:51
Yeah, that does make sense. That’s a really good advice. And I think, I think the other thing is, when you find, as people do upskill, then they don’t really want to go near the legacy system anymore, do you know what I mean? They suddenly realise that, oh, the grass was kind of greener in the end, and then it’s like, they look back, and then suddenly, what you will find is the minute that does happen, you can guarantee the exit of that data centre suddenly radically speeds up, because actually, now I actually genuinely want to get rid of this too. And so everybody just kind of gets more on board, as they, you know, they recognise the value massively, and then it just kind of want to get rid of this, because it’s just painful, having to still operate something that you know, could be a lot better somewhere else.
Joel Parks 42:35
Right. I mean, I don’t know, a single person that I ever worked with, that said, you know, what I really want to do I want to manage a ticket queue and just manage and just, you know, take instructions and go manually type commands into things.
Jon Shanks 42:49
I mean, if you are out there, do let us know as well. Because you can prove Joel wrong. Be like, hey, that’s me!
Joel Parks 42:58
Send your notes to Joel. But you know, when when push comes to shove, when there is a better way to do that, you know, most people will gravitate towards it, as long as you can sort of de risk it, and and take the scare out of it, you know, just a year away, then most people are very willing to learn a new way to do it. It’s just again, that fear component, getting that out of the conversation and making things transparent. You know, again, in a in a very above-board working group way of these are the problems that we’re going to collectively solve, right? It’s not it’s not one person’s job to solve all these problems. It’s all of ours. And we’re going to work together to solve it. So security is key. You mentioned IT Service Management. And I think they’re another one that that often, frankly, gets overlooked.
Jon Shanks 43:55
Yeah, I agree. So service management. I mean, there’s no real right or wrong in all of this, I suppose. And it’s, you can kind of argue, depending on where you’re having the conversations in the business, who’s getting who’s not really getting represented, will change, depending on where the conversation is happening. If you’re talking to engineering, it’s going to be probably from a very, you know, security probably will be represented in that conversation. Because a lot of DevOps people, you know, cloud specialists do understand security too. So it usually just get represented, but then when you then talk at a business level, which is maybe the ITSM area as well, when you’re thinking about the operationalization of stuff, you know, change the impact that these things are going to have, then sometimes it’s the depth and then not the engineering that get represented and it’s a totally different kind of conversation type that goes on.
So I guess who gets misrepresented in different, or underrepresented I guess, depends on where the conversations are happening. To have the conversation happening in one place well I think is kind of the key thing, because otherwise, what I’ve seen a lot is, there’ll be a lot of mature conversations happening in one space. But that’s because they’re elke mind. Right? So they all write the same, right? It’s much easier, frictionless, right? It’s frictionless to talk about this. And we feel like we’re moving faster. So they want to cook is a temptation to just cook people out that just don’t get it, because it’s going to be quicker. And I think, you know, that is very tempting. But then you then create this silo mentality where, you know, then when you haven’t involved ITSM, they’re kind of looking back and be like, well, this feels like a big risk here and what’s going on? And suddenly, a bit like with security, it’s gonna get halted, right? Or it can’t go into live, you know, whatever. We kind of see because it’s right, as a checklist for live that’s not been updated to represent cloud.
Joel Parks 45:51
Right? Yeah, exactly. So yeah, that’s another reason why having that executive sponsor involved early is really critical. Because some of those conversations, you can sort of use that person to go neutralise a bit of those conversations, at least move or at least move them down the road, right? Where we say, Yes, we are listening to you, we want you to be involved. But we’re not going to address that in this version, that’s going to become a roadmap item. With ITSM teams, what I have learned over time, is they generally are there to maintain a process. But because they are, in a lot of cases, kind of they’re a couple layers removed from the technical reality, they’re not on the front line, they’re not architects, they’re not super technical, in a lot of cases, you know, that process can become very rigid, because they don’t understand the difference between, you know, collecting data, in a private data centre to populate assets, changes, releases, those types of things. And the data that can be retrieved or, or gotten in, in a cloud environment and how they’re sort of fundamentally two different modes of operating. And it’s just because it’s not through any fault of their own. It’s just that’s not their day to day function. They’re collecting data to support the the organisation through an audit cycle, usually, right?
Jon Shanks 47:22
Yeah, definitely.
Joel Parks 47:22
And if they don’t understand that, okay, yeah, the same data is available. But it’s, it’s done in a different way, it’s collected in a different way. And we’re gonna adapt our process as we move to the cloud to take advantage of those data sources that typically, you would have to build a mechanism to go scrub the environment, do reconciliation, against assets, and all this stuff, that just is not a concern. In cloud environments, you can have it, you can hit the API and get back a list of everything.
Jon Shanks 47:53
Yeah, one minute it’s there, the next minute is not.
Joel Parks 47:55
Right. So there’s, there’s a bunch of change in their thinking. But if you don’t engage them early, you’re not giving them the time to get up to speed so that when it does begin to impact them, they understand how it impacts them.
Jon Shanks 48:12
Yeah.
Joel Parks 48:12
Where if you push the conversation out and don’t involve them until a late stage, now suddenly, they’re overwhelmed, they don’t have the context, they don’t understand how these changes, you know, are going to impact them. And they’re likely to just stomp on the brakes again. Right. So that’s, that’s sort of the trick of dealing with ITSM teams is helping them say, okay, there’s going to be a change in this, but we can help, you know, make sure that you continue to have the information that you need to build the picture to support the organisation through audit, typically, that’ll drop the resistance pretty fast. Would you agree with that?
Jon Shanks 48:49
Yeah, yeah, definitely. And I was just thinking as you were kind of as you were talking, because this isn’t something I’ve ever seen pan out. So and if anyone else has done this, I’ll be kind of really intrigued to know how well it worked. But because you were talking about change agents, I think having a change agent per discipline, in the business that represents that disciplines, that means a change agent for ITSM, a change agent for security, a change agent for networking, you know, and having a change in for each discipline that then forms a new team that essentially is that team that’s going to now work on this new project together with then somebody that’s obviously educated it I’ve never seen that actually happen. So I don’t know if this even now it’s just an idea, but has anyone ever approached it like that before? I don’t know, maybe people have just like, well, yeah, that’s what we always already do, Jon, what are you talking about?! Like we all do that.
Joel Parks 49:46
I think sometimes it’s hard. I mean, you you may find certain pockets of just you know, you go looking for sort of the change champion within ITSM or Whitsun with insecurity or maybe infrastructure and storage or whatever, however your organization’s broken up. I think sometimes you you find people that are very hungry and are very motivated to do things in a different way. Other times it, I’m not saying it’s bad, it’s just you take who’s been volunteered.
Jon Shanks 50:20
Yeah, that’s definitely not bad. I don’t think that. When I’m saying it has to be somebody that wants change to begin with, when we say a change agent, it’s not like the change agent has to want change. It’s not like, oh, you’re, you’re now a change agent, like, you know, because also, if they didn’t themselves forward, there wasn’t somebody that wants change anyway, do you know if it’s not a good indicator to be nominated as somebody that’s like, representing change, because it was they didn’t have a choice, which would kind of indicate, you know….
Joel Parks 50:52
Yeah, now, one thing I will say is something that I’ve observed over time is and this is just a warning signal for all you change agents out there. There is going to be a period where you’re going to go through and you’re going to be recruiting you know, people from different disciplines to this this effort, one snaky not so nice thing that can happen is someone from a particular discipline, let’s say you go to a manager, and I’ll just pick on infrastructure, right now, right infrastructure, compute storage, something and they you say, I, here’s, here’s the goal, here’s what we’re shooting for. Here’s the people we’ve enlisted. So far, this is a strategic initiative, here’s the executive sponsor, we would like you to be a participant in this cloud working group, or cloud Centre of Excellence, or whatever name you attached to it right? There occasionally, if you have a manager who is not on board with it, does not like to change wants to protect his team or has some other agenda, what you’ll get is what I call a pocket veto, where on paper, they will say, yeah, I’ll give you I’ll give you a resource, he’ll be dedicated, you’ll be fine. And he gives you the greenest of the green from his team. Just so that on paper, nobody can say that he isn’t cooperating he or she isn’t cooperating, but they’re also giving you the B team basically, just they’re not hurting, but they’re not helping either.
So be aware of, you know, that particular ploy. And if it comes up in your, in your manifestation or your, your team that you’re trying to build, just know that that is an appropriate time to enlist your executive sponsor, to go, you know, let’s let’s have a different conversation, maybe at a different level of the organisation to change the priority. Because if they’re not feeling that it’s a priority, or they may be your sort of soft pedalling the change, you know, find somebody with more juice than you do to go apply some pressure.
Jon Shanks 52:50
Yeah, definitely. I mean, I, we all notice resistance in different pockets, but that definitely does occur. So I think I think there has to be the escalation point. I think, also, though, if you are going to, I was just kind of thinking if you are going to instantiate somebody from the discipline to represent that discipline, or aligning their personal outcome goals in relation to the outcome for the business….
Joel Parks 53:18
Oh yeah!
Jon Shanks 53:19
…I mean, it’s probably gonna be crucial, because I think if you do that, then you’re then motivating the person personally, to now mature into something different, you know.
Joel Parks 53:29
If that is an option available to you, do it.
Yeah, for sure. Yeah. Because that’s a powerful mechanism. Like, you know, people have asked me over the years, how do you motivate people to do things? And my joke answer is candy, you know, but the real answer is: incentives. Get them a tangible incentive to do what you want them to do. It works for small children. And, you know, DevOps engineers.
Jon Shanks 53:54
We’re children inside really, so.
Joel Parks 53:56
Exactly. So now moving on to the next next group on the list, it really is that infrastructure compute storage team, however that is aligned for you, but it’s it’s really the, the team that owns the traditional compute infrastructure. Getting them on board sometimes can be a bit tricky because they can feel directly threatened by cloud coming into the into the organisation. I have seen this dynamic change a little bit over the years. Rewind 10 years, there was a lot of, you know, clouds. No good cloud will never happen here. Right. Yeah. It’s feeling more of an inevitability with with teams like this, and I think that that definitely is helping john, what is your experience been?
Jon Shanks 54:46
Yeah, I mean, I suppose it’s not, I think it’s been some time, I suppose, since I’ve met any infrastructure engineering teams that haven’t already kind of dabbled into Cloud. A little bit. So it’s kind of rare that there’s that vacuum of knowledge, you know, from the team completely. Like normally, people see the writing on the wall, and you know, even in their own network, their own social network or people in their kind of career paths. Historically, you know, who we’re talking about stuff they’re doing, they’re influencing one another, from their own disciplines too, within their own kind of community. So sometimes it’s less contentious, but I think it’s more contentious, potentially, for certain individuals more than others. So I suppose as you’re looking at from a team perspective, and as a departmental perspective, they probably will be people that are probably wanting to get into Cloud anyway a little bit, and then there’ll be those that just don’t? I don’t know, if you agree with that? I don’t know, you’ve probably had different experiences, maybe on this one than me.
Joel Parks 55:55
No, I do. I think the single biggest challenge with with those teams is you’re going to land in deep weeds pretty quickly, because a lot of the immediate conversation, at least likely is going to centre around: Well, how do we do antivirus? How do we do system patching? How do we do…like there’s going to be a laundry list of things that are really like sort of their weekly punch list items, that they’re going to go down? And they’re going to try and validate. Alright, what is this tangibly mean to me? Right? And how do we and at least in most cases, they’re going to be looking for how do I replicate what I already do over here, right?
I do it here, now, I want to do it over here, now. You know, can I can I translate this one to one? And this is another area where you’re gonna have to invest some time. Because especially when you get into and again, this may not work for everything. But this is the team that’s going to require some education, if they don’t already have it around. What is ephemeral infrastructure really mean? Or if not ephemeral? What is item potent infrastructure really mean? Right? You know, how does that change my approach to system patching? Right there used to patching in place? Maybe we don’t do that anymore. Yeah, you know, educating them on the different mechanisms that are available within a cloud environment to accomplish the same task going back to the security question, you know, requirements versus implementation. Yeah, you know, what is your requirement that you’re trying to satisfy? Then let’s talk about the implementations bolt that you know, and the ones that maybe you don’t know.
Jon Shanks 57:38
And what’s your, sorry, just to kind of, like, ask the question on that, what’s your take on the infrastructure team, also now becoming the cloud team? Because that happens quite a lot. So you can they, they just, you know, a cloud kind of is like infrastructure, too, right? So it’s like, let’s just, let’s just make that team, also the cloud team. And now it’s like, you know, the infrastructure or head of head of infrastructure’s problem, to now go and work out like what cloud is, and there you go. What’s your take on that?
Joel Parks 58:12
Well, the short answer is, I think, in any large enterprise environment, where there’s established processes, you’re going from, let’s say, on prem to cloud, you’re transitioning from A to B. That correlation of taking the existing infrastructure team, and now suddenly, they’re the cloud team. It’s almost inevitable, like, I don’t know that you’ll be able to get away from it. Now, the re skilling, the change in skill sets, you know, we talked about cloud adoption as change in process change in skill sets, change in technology, you know, that change in skill set for that team is going to be relatively large, sort of, depending on where they’re coming from. And I think I want to save I don’t, I don’t want to be too much of a tease. But I think I want to save a bunch of that conversation when we get to retraining and skill set a little down the road. Because ultimately, that’s what in my view, it really comes down to if you can influence the change in process, if you can influence a change in technology, then the only thing that stands between you and success is the transition skill set.
Jon Shanks 59:15
Hmm, I do have a little bit of an opinion on this. This wasn’t why I asked. It wasn’t just to kinda fish for that and get my own opinion in there. It wasn’t. But as you were kind of talking, the one thing that I do think is very fundamentally different from an infrastructure engineer, is the way of thinking. Developers think more so in a product way, and product minded and agile, iterative phases. And engineers, you know, thinking in terms of infrastructure, they don’t have to historically think like that. And so they think about just providing the nuts and the bolts, and then that’s it really, it’s kind of handoff mode type approach. That’s such a different way to think. And I think that’s the biggest challenge, you know, thinking in terms of outcomes, working backwards, having like that product way of thinking, agile way of thinking. Sometimes, I mean, this isn’t obviously it’s a big generalisation. I’m just totally generalising an entire thing.
But a lot of the time because they haven’t worked in that team that has to work like that, obviously, to begin with, it can be quite a mind shift. I think the skill is one thing, but changing your approach and changing your way of thinking, I think is probably the hardest thing for a lot of people to do. And that’s what I see, being the biggest shock. Anyone could learn a tool and a piece of technology, it’s very hard to change your way of thinking, habitual ways of thinking around the technology to to understand the outcome, you’re striving for first, a bit, like you were saying, at the very beginning, you start with the outcome, you kind of work backwards. That’s the that’s the North Star. And everything else is is iteratively working towards that. I mean, I don’t know what your take is, would you agree with that or not?
Joel Parks 1:01:12
Oh, I do. Practically speaking, that change in mindset, that way of thinking it has a bit to do with the change in process. So how do teams and different skill sets interact with each other. Some of that way of thinking is accounted for in the process. And if the process changes, then it gives people a structure to know how to do things in a different way. Right? Then there’s the skill set that comes alongside that, that’s the ability to execute the process. And if you can do both, then you not only have a framework, but you have a skill set, that’s that’s ready to plug into it. But again, these are all things that are going to evolve over time. And it’s not one step, right? There’s no big bang for this. It’s a series of discrete steps that are going to get you there. And it’s going to be started in the discrete steps start very small. And then they increase gradually over time in both scope and complexity.
Jon Shanks 1:02:15
What’s your take, sorry, I just keep asking you loads. Having somebody in, and I’m not saying necessarily a delivery manager or an agile coach or anything like that, necessarily. But having somebody with this inherently got product, product ways of thinking to begin with, in relation to targeting cloud, which is a change. But I kind of feel that skill set of framing exactly the outcome and framing and working backwards from that, if you don’t have somebody in there already in the business that thinks like that, that is going to facilitate a lot of the meetings, it’s going to facilitate a lot of the conversations to get the right outcomes from people, then it’s not being steered with an objective, right from the beginning. And if there isn’t that facilitator in that meeting, or in those meetings, trying to work it out, you know, on the approach properly, then the approach could be varied, do you know what I mean? It could come from anyone, it could be in any way they want to do it. And, you know, then there’s a risk, I suppose if someone’s not leading on it, with that approach to begin with, then there’s a risk that it just takes whatever weird approach it’s gonna take, and it’s just gonna go off, you know, on a tangent somewhere. And so, yeah.
Joel Parks 1:03:33
So, again, getting back to the, you know, process skill set and technology conception of this, this transition, I see that as, as the role, at least in large part of the change champion, right, they should come prepared, and they should be experienced in working in those ways. And if the, to your point, if the goal is, ‘alright, we’re going to use Cloud, but we’re going to shoehorn it into our legacy processes, and we’re going to call it a day,’ that’s not really cloud transformation. That isn’t also going to get you the the benefit of what cloud can really do. Right, it’s going to operate in this weird in between space of somewhere between what cloud can really do and what you could do in your private data centre. So maybe incrementally better in some very specific ways, but it won’t be holistically the change that you were expecting.
Yeah, so you know, there there does need to be someone in there that understands the new way of thinking that can promote you know, whether you call it DevOps or agile or lean or some combination of the two epic your name, right.
Jon Shanks 1:04:42
Yeah, exactly.
Joel Parks 1:04:43
But it’s it’s the same sort of delivery or outcome or product focused approach because at the end of the day, what are we maintaining in enterprise IT organisations? We have a portfolio of applications. That portfolio of applications has a business relevence. Itgenerates revenue, it does something for us otherwise, we would have never built it. Right. So that that is your product. You know, that is, that is who you are. And if you don’t adopt those very product centric ways of working, which cloud definitely expects on a lot of levels.
Jon Shanks 1:05:18
It’s designed for it really in some ways with all the abstractions there. And, you know, consumer is it’s there to be consumed. And it’s, they are products within themselves, right? And, the cloud has product ways of working that have been designed by product teams, you know, and therefore there’s an expectation in the design, really, that’s underpinning it, you know, that you’d be approaching it probably in a similar way, because that’s how it was designed from conception to begin with.
Joel Parks 1:05:44
Right. Exactly. So that that change in perspective, as you were talking about, you know, the the change goes from, ‘I keep this pool of resources up and running, so that it can run applications’ to ‘alright, nobody gets a gold star for keeping infrastructure up and running anymore. It’s there, go request it.’ Right? That change in thinking is equal parts skill set and process in my mind, you know. The process defines how we’re going to request it. And the skill set is knowing what to do once you have it.
So in answer to your question, that’s how I would conceive of it. But we’ve talked about the general membership of the team, you know, starting with your Change Champion, then right behind that the business or the executive sponsor, and then security ITSM, obviously, app dev, because we’ve been looking at them as, you know, sort of our first partner coming on board and providing us that target, down to network storage compute, the infrastructure that we currently use to run the application. If you can capture those perspectives, you have a very functional prepared cloud team for your first foray into Cloud. I would think, Jon, do you agree?
Jon Shanks 1:07:02
Absolutely agree with that, yeah. I think you’ve pretty much summed it up. I do have one other leading question. Do you or do you not get the vendor of the cloud pro-serve involved in any of this? You know, do you start engaging with that vendor who, obviously is going to be bias to their own services? But that doesn’t necessarily mean it can’t be of value? Do you get them involved to help you with what you’re doing?
Joel Parks 1:07:35
I’d have to say, it depends, which is a maddening answer. But I think it’s the truth. It depends on what you’re trying to accomplish. You know, if you if you find that, you know, the the team needs extra support? Yeah, they need the extra helping hand to contextualise what’s going on in the cloud and help sift through some of not only the technical, but also the process change decisions of how to make best use of the functionality? Then I’d say yes, absolutely enlist them. But I wouldn’t start there. Because again, this isn’t really just it lining up another consultant to come deliver some work, and then you know, we’re done now, right? It we’re all cloud-ified, it’s not quite like that. The organisation is going to have to transition, which means, there can be support that comes from outside, there can be also external sort of stimulus driving you towards what it is you’re trying to do.
But at the end of the day, the transition is about the internal resources, the internal team processes, skill sets technologies, reorienting themselves, to be more able to consume these technologies. So in that sense, there is no there’s no magic bean, there is no like, quick magic spell that you can cast to just sort of instantly get yourself there. Consultants aren’t going to do it for you. They can teach, they can guide, they can be your sort of Sherpas on the way to the cloud. But ultimately, the work is on you, because it’s ultimately your business.
Jon Shanks 1:09:14
Yeah, and you need to own that essentially. And you need to own that within the business and have the right skills and capability to underpin and support it long term, not just, you know, do the short term with the supplier. I think it’s quite useful to run by designs or l have somebody there, whether it’s a term that they can provide you just to kind of reassure you that you know, hey, we’ve white boarded this thing we kind of, you know, we’re thinking about this kind of design, or we’re thinking about this is the right way to approach some of your services. And, you know, just to kind of soundboard and sound, check your approach. But I think, you know, there will be a temptation, especially if you’re a large organisation, where they’re going to be motivated to get you into their cloud, you know, that you’ve gotta recognize that
Joel Parks 1:09:57
Absolutely.
Jon Shanks 1:09:58
It’s, you know, they might not be get aligned to your business goal. But there will definitely be aligned to the consumer goal.
Joel Parks 1:10:04
They can be very helpful resources. But recognise at the end of the day, this isn’t totally altruistic on their, on their part, right? They want your they want your business, they want your money they want your cloud spend.
Jon Shanks 1:10:16
Yeah.
Joel Parks 1:10:16
So they’re obviously going to direct you accordingly. But that said, early in the journey, having those external resources, those trusted advisors that you can take your current thinking, your current plan, the activities that you’ve scheduled and say, Hey, does this make sense? Are we about to make a big mistake, and have that objective third party read on what you’re doing is huge. That’s hugely valuable. And if for no other reason, then if they come in and say, ‘Yeah, that looks great’, what a confidence boost, right? They’ve just validated that you are taking away the correct learnings from the process. And said, yes, go forward. You know, that’s, I mean, that’s a huge confidence boost. And in my experience, you know, the, with the, the original team you know, what I call the the seed or the CCOE, or, you know, the the beginnings of the cloud transformation.
Confidence is key. So, when I said early on, don’t get discouraged, know that this is going to be a journey, you’re going to have to repeat yourself, not all of it’s going to be fun conversations, like you’re going to have to overcome a lot of objections and people with crossed arms saying, I don’t think so. But sticking with it, is going to build a tonne of confidence within the organisation that Yeah, actually turns out, we do know how to do this. And we’ve learned together. And and that really, I think, apart from the deliverable is the key learning that organisations have to take away and what the teams have to be prepared for in that first round of cloud adoption.
Jon Shanks 1:11:51
It’s some really useful information. And I think there’s things we didn’t say, I mean, we could talk about this all day. Because there’s so much to this subject, right? You know, and this is why we’re going to kind of cover off all these different episodes, but, you know, balancing out the technology consumption choices when you’re kind of iterates. It’s not just the security will be led, not just holistically across the cloud, but also about the tech you’re about to consume. And the tech choices kind of go hand in hand with the security. Right. So you also then have to work out well, what tech am I using? Are we going to be agnostic? Are we buying into that vendor? I mean, there’s all these types of…
Joel Parks 1:12:29
Are we gonna use Azure Arc?
Exactly. Are we going to use Azure Arc? Exactly. So, you know, are we adopting more of a generic cloud native approach? You know, what is our strategy around technology as a whole, plus, then cloud? I mean, there’s a lot, there’s a lot to all of this. And I feel that not to kind of boil the ocean myself in this kind of topic. You can kind of see why it’s complex, you know, because there are many choices to be made.
Well, listeners, now you know why Jon gets paid gets paid the big bucks to do segways around here, because that transitions us right to where we needed to be for next week’s episode. So next week, we are going to talk about exactly that. Getting started with the cloud vendor of choice, you know, whether it’s, you know, pick whichever one. But how do you start to scaffold up an account structure, begin to consume resources and do it in a way that is going to satisfy the different perspectives that exist within the team? So answering questions like what’s the right structure? How are your teams going to plug into this new technology and work with it? What considerations are they going to have? And you know, most importantly, how to not blow through your budget in a single day in the cloud? Because, believe it or not, it is very, very easy to do. So, Jon, I think that’s basically it for us today.
Jon Shanks 1:13:54
Yeah, I feel like we’ve covered a lot. There was a lot there. I hope people find it useful, you know. And, you know, do get in touch with us if we’ve said something more controversial than we realised.
Joel Parks 1:14:11
Yeah, so good, bad or indifferent. If you’ve got questions, comments or other feedback on the show, we do want to hear from you. We want this to be as interactive as possible. You can email us at cloudunpluggedpodcast@gmail.clom – .com! cloud unpluggedpodcast@gmail.com or cloud_underscoreunplugged on Twitter. We will be back with another episode next week. Wednesdays are our release days and we’re going to talk about cloud accounts and how you get started once you’ve gotten your team.
Jon Shanks 1:14:45
Brilliant.
Joel Parks 1:14:46
Have a good week.
Jon Shanks 1:14:47
You too. Bye.
Transcribed by https://otter.ai
