Is C-level support required to have a successful digital transformation? In the sixth episode of DevOps Unbound streaming broadcast on TechStrong TV and DevOps.com’s sister site Digital Anarchist, Mitchell Ashley of ASG and Alan Shimel are joined by Eveline Oehrlich of the DevOps Institute, Louise McCarthy of Bain & Company and Mark Settle, author of “Truth from the Valley, A Practical Primer on IT Management for the Next Decade,” to discuss DevOps and digital transformation at the C level.

Transcript

Alan Shimel: Hi, everyone. Welcome to another edition of DevOps Unbound. DevOps Unbound is brought to us by our friends at Tricentis. So, thanks for their sponsorship. But, you know, they sponsor but we pick the topics. We pick the guests. And we have a lot of fun here talking about relevant topics around DevOps. Today’s topic centers around DevOps and digital transformation at the C level. And let me introduce you to our panel. First of all, we have Louise McCarthy. And, Louise, I’m gonna ask you to kinda introduce yourself with a little background for our audience.

Louise McCarthy: Yes. Thank you, Alan, and hi, everybody. I’m Louise McCarthy. My background more recently is doing large, complex digital transformations mainly for the financial services. And mainly through the eyes of the business rather than the technology, although I have held roles as CFO and I’ve held roles COO and CIO as well.

Shimel: Excellent. Next, we have Mark Settle. Mark, welcome.

Mark Settle: Thank you. So I am a seven-time CIO and I most recently left Okta about a year ago and have been advising startup companies since then. I’m based here in Silicon Valley. And probably my encounters with DevOps are focused on supporting DevOps communities in terms of infrastructure requirements if they have, and also introducing the concept in actually business application support within a conventional kind of an IT group.

Shimel: Thank you and welcome. And then Eveline Oehrlich, Eveline, please.

Eveline Oehrlich: Yes, hello there. Eveline Oehrlich. I’m the chief research director at the DevOps Institute. Before that I spent 13 years as vice president at Forrester Research studying a variety of topics, and DevOps of course was one of them, working with many enterprises and C levels and others to explore the challenges and the fun of DevOps.

Shimel: Very good. I’ve never heard anyone talk about the fun of DevOps but I’m looking forward to discussing that. And then, last but not least, of course is my cohost here on DevOps Unbound, Mitch Ashley of Accelerated Strategies Group. Mitchell?

Mitch Ashley: Good to be here. I’m Mitch Ashley, CEO of Accelerated Strategies. We focus on digital transformation, DevOps, cloud native, and cybersecurity. I’m also a former CIO. Not nearly as experienced as Mark is, but have led transformations and also implementation of DevOps as well as been a CTO, CEO of product companies. So I’ve lived on both sides of DevOps.

Shimel: Great. What a great panel we have today. I’m really looking forward to it. So we’re talking about DevOps at the C level. As I mentioned to you all before we started today’s show, our friend Gary Gruver wrote a book, “Leading the Transformation.” He wrote several books. One of ’em was “Leading the Transformation.” And Gary is a big proponent of what he calls the top-down approach to DevOps and digital transformation. And in Gary’s view – and I’m not saying right or wrong. In Gary’s view, you cannot have a successful digital transformation or DevOps transformation without sponsorship, support, air cover, if you will, from the C level, including the CIO or CTO, depending on the organization. CEO, et cetera.

Let’s start there. Is C-level support absolutely positively required to have a successful transformation? Anybody?

[Crosstalk]

McCarthy: Do you mind if I go first, Alan?

Shimel: Sure.

McCarthy: I would actually say, my recent – I’ve done about five or six transformations and tried all sorts of ways to actually get them going. There’s always blockers on the way and it’s usually the blockers that slows the whole problem down. And the blockers either come from the ground up, from the employees or the people that run the processes today, or you get the blocker in terms of the C-level-suite people who tend to wanna own things, and it’s a big of ego that actually blocks things going that way.

And the most recent transformation was successfully owned by the C-suite. So they drove it. They owned it. They were the stakeholders. But most of the engagement actually came from the employees, from the process owners. So we ran the whole transformation from the process owners actually owning and identifying where the transformation needs to take place. And that really made it hugely successful because you didn’t have people fearing for their own jobs. ‘Cause with digital transformation it always means or often means that there’s gonna be heads that unfortunately are lost in various areas of the – in the transformation. But mainly doing transactional-type work. But if it’s the transactional people that are running the processes, they highlight their pain points and then we work with them to actually change those pain points into something positive.

So, I would arguably say both from top-down, but also if you don’t do it with engagement of the people running the processes today, it won’t work.

Settle: I’ll chime in. I think I have the same answer but I’m gonna state it in a slightly different way. I think the way the question gets asked, it sounds as if the CTO or the CIO’s gonna come down from the mountain with the DevOps tablets and then ____ employees and team members _____. “I’ve been converted and now it’s your turn. We’re all gonna go do this together.” [Laughs]. Most of the time that doesn’t work. For one person to come in – well, take an example where a startup company here that’s been reasonably successful. Maybe they get up to a product team of, I don’t know, a generic team of 500 people or something like that. They hire a new chief product officer or a chief technology officer who says, “We’re gonna do this completely different. I have a vision.” Et cetera. Well, they’re gonna do it but that’s gonna be a slog to kinda get there.

What I’ve seen be more successful is almost like – what’s the right term in a battle when you send the beach guy out? The beach master that’s moving people around. So you really want almost like a fifth column movement down at the grassroots level of people who are genuinely interested in exploring these ____ ways of doing business. And then I think what the C-level person adds are the methodological resources to drive scale. And so many DevOps initiatives fail because they sound interesting; they sound contemporary; people think, “Other people do it so it must be beneficial.”

But then after like 18 months, everybody scratches their head; “Where are the benefits? We thought this was gonna be transformational.” It’s not. The technical people are having fun. They’ve developed this new terminology, et cetera. And if you scratch below the surface, well, guess what? You’re doing DevOps in like five different ways because the little C-groups have all picked the tool they wanted and decided that they’re gonna have a daily scrum twice a week or whatever. They’ve got their own little process set up. And then people say, “Where’s the benefit? This was supposed to be transformational.” So at some point in the early stage of the journey, it’s needed to drive scale and ____ of endorsement. But I think it can almost backfire if it’s launched from the brain of Mark Settle that, “Yea, and verily, I’m gonna lead you to the promised land.”

Shimel: Sort of a Charlton Heston beard I’m picturing on you there, Mark. Eveline, how about you?

Oehrlich: Yeah. I actually would say it should be outcome-driven DevOps. It doesn’t really matter if it is from the C level, from the individual, from the inside-out, from the outside-in, from the top to the bottom, the bottom to the top, from the middle to the whatever. It needs to be outcome-driven. What I mean by that is: Only metrics will make us change. Just like I drive through my town here – this is a little analogy. I drive through my town. They installed one of those things where they measure the speed and if you go over 50 kmh you get a ticket. Well, my husband, even though that thing has been there for two years, my husband manages to get a ticket every three months. But what he does is he intercepts the mail and then he doesn’t tell me that he has gotten that ticket.

So now what I have done to stop those 15-euro tickets every two months – because if you add it up you can go for a nice dinner – I am going to go through the mail before he gets home so I see how many tickets he gets. And he gets little lines. And that metric is on the refrigerator – I should’ve brought a picture of it – and that has actually reduced how he is driving through town.

And so if you go back to the DevOps teams and the digital transformation and you ask the individuals at C level or VP level or practitioner level, “How successful have you been or what’s the challenges around?” It’s easy to point to somebody. But data, if you have data which shows where you are and it maps to where you want to go and you share that amongst all these different individuals, there is no argument. It’s not the guy with the long beard, as Mark would come in, or it is not somebody at the lowest level who could argue with that. We could huddle around it and figure out: What do we need to do?

So I think it’s not really about who – of course we do need some individuals who pays for it. We need some kind of a fund and budget and all of that. But I really think it’s outcome-driven rather than organizational-level-driven.

Settle: Can I just chime in on that one, too? So I would agree 100%. And outside of maybe the CTO or CPO or IT organization, bringing evidence of improved sophistication, operational metrics around the process to almost any other C-level executive – they don’t really care. The CFO – if you show that, I don’t know, the year throughput, the story whatever – in one of my books, it’s like reading a Bible to the cat. The cat will look at you and feign interest. But it has absolutely no idea what you’re talking about. And that’s sorta what you get outside the technical functions, everybody – “But that’s your job. You figure out what needs to get done.”

And, again to your point, it’s more of a business outcome. Like, are we actually getting customer request enhancements through in greater quantity or are we able to respond to a competitor’s new feature set faster than we did at their last result cycle? Or whatever those things are. That’s what people wanna talk about.

McCarthy: Yeah. And – [Crosstalk]

At the end of the day, the outcomes is aligned to the strategy of the organization. So you’ve gotta be doing a transformation for a reason. And there’s usually three or four reasons why you’re doing a transformation. It’s around the customer journey so the customer needs to improve the satisfaction. You’ve gotta costs. You’re trying to grow your revenue. And then the one that’s usually an outliner that’s become ____ at the moment is carbon emissions. So for every one of these paint points that I mentioned earlier, there should be a business case that shows measurement of success against each of those four measures. And that’s what you – bottom-up, you report at top level to the C suite to say, “This is why we’re doing it. This is the measure of success of what we’re doing it.” And even breaking some of the pain points and the business cases down to quick wins. So ones that you can be getting on with relatively quickly that free up cash that then can pay for the more strategy-type things.

Shimel: Yeah. So I think this brings up – all three of you have touched on it. And it brings up what I think is really sort of an entry question, which is – it’s the genesis of digital transformation. Why and how does any organization decide to go through the potential pain, heartache, and change of digitally transforming, of adopting DevOps or agile? Louise, I’m pretty sure we spoke about this – was it at an Emmet Keeffe Insight IGNITE in Iceland that you were at?

McCarthy: Yes.

Shimel: I was there with you and I remember talking to you about this. You know, Eveline, in your day, someone like Mark might go to a Forrester conference and come back and say, “Wow, Eveline Oehrlich from Forrester just presented this presentation study on the benefits of digital transformation and DevOps adoption. And, god darn it, she described us to the T. We really need to do that here.” And maybe that worked then, right, seven years ago, ten years ago? I don’t know if that’s the genesis of digital transformation today. I think a lotta times digital transformation today does start with technical champions lower down whispering in Mark’s ear that, “If we were doing DevOps or agile or whatever, we could really make better customer experiences. We can give customers what they want. We could do it better, cheaper, faster.”

[Crosstalk]

Ashley: I think we have a chasm that we have to cross, and that is: DevOps can be sort of a vanity project for the IT or the development organization, right? It can be a purely self-interest: “We’re doing what we do better.” Which is always a good thing, but at the end of the day does it move the needle for the business? You have to be able to translate that into what Eveline said was the why. Louise also said the why. But what is the real benefit we’re trying to get out of it? And when you have a purpose for doing it, now you have metrics you can put around that. Is it revenue? Is it competitiveness? Is it responsiveness to the market? Is it changing customer expectations and behaviors? What is it? That’s truly – then the development or the IT organization knows that they’re making a difference.

Otherwise how do you know whether you should be working on more releases per hour, per day, or you should be working on just fixing the backlog? How do you know? You don’t other than just sort of your own internal metrics. And I guess it kinda reminds me of that phrase of the – what was it? Belly-button gazing, right? You’re sorta looking at yourself and what you think’s important. But I think that connection – you have to cross that chasm, whether the business is coming to you or you have an idea of what we can do better and how it might help, and then let’s then make that connection.

Shimel: That’s my point. Someone like Mark – Mark, what does it take to push you over the edge and say, “God darn it, we gotta do this; we’re committed”?

Settle: Yeah. Let me _____. One thing’s funny about this whole line of conversation is of course, in the world that I live in out here, there’s no question about doing it. It’s like: Who is the most sophisticated – [Crosstalk] or more sophisticated? So, in the war for talent, that same 500-person organization I referenced – they might look at each other and say, “Who do we know at Google or Facebook, in their engineering group? We know we should be doing this better. We’ve kind of played around with the concept. We’ve hired some lower-level people who’ve said, “You guys are just behind the times here. So we need some real leadership inserted.” So that’s the other side of the coin. In parts of the country where maybe it’s like an accepted practice, there’s almost a competition to be the most sophisticated or get the most benefit.

But the spark plug, the question you’ve asked – I’m thinking about some second-tier markets – and I really hate to call out specific locales, but what the hell? As a consultant, you can talk like that. So if you’re in a place like St. Louis and you’re in an organization that just has done business the same way forever, all the IT management, all the technical management has come up through the ranks kinda doing things the old-fashioned way, quarterly releases, and they don’t keep the same kinda metrics that you would in a DevOps environment, to blow a place like that up – there’d have to be some kind of competitive imperative.

Or, you know, the white knight does show up from time to time, right? So if you think about it, sometimes when the new CPO or the CTO comes in – and I’ve experienced this in my own career – there’ll be a cause or a initiative that I promoted during my entire tenure – the new guy or gal comes in and they get it done like in a year. And I think, “What the heck happened here?”

There was one company where I was trying to get them off of Microsoft Dynamics, get ’em onto Salesforce. There was another company, I was trying to get production systems up into the cloud. And we did every kinda seed activity you can imagine. The cloud one, we sent people up to Redmond for some AWS instruction. We did some prototyping, et cetera. New CIO comes in and says, “We’re going to the cloud,” 12 months later like half the production systems are in the cloud. Like, “How did that happen?”

So sometimes change at the top – which gets us back to where this kinda started – maybe that is the seminal spark plug. And especially if that person’s been brought in because there’s a broader C-level recognition that, “We’re not keeping up with the times; we need to make some kinda change.” So you have that broader support. When people start to whine, they know that the whining’s not gonna get them out of the change that’s about to come.

But for just self-generated change for people that’ve – then I go back to, you know, Mitch, where you said: then you can always have a vanity project which you can point to as evolutionary. Like: “We’ve got a small group. They’re putting their toe in the water. They’re doing some interesting things. So we are keeping up with the times.” But then you just don’t get the scale benefits at the end of the day.

Oehrlich: I think there was – just to add to something to what Mark said, as the ecosystem of our organizations has expanded, we have to think of – well, the travel industry doesn’t exist at this point in time, but think of maybe manufacturing, right? In the area where I am in, I’m in Stuttgart, we have large car manufacturers, and they’re connected to Bosch and others, and the ecosystem is rather broad. And these folks at all levels are collaborating, connecting. Not as much now with where we are, but they have exchanged thoughts and ideas, they go to events, and they learn from each other. At all the different levels. And so I think there is that – as Mark said, to some extent there is this – not really a competition, but the exchange of ideas, which has brought additional adoption of DevOps at all levels, right?

So if I am the C level of Bosch and I go to a genomic car-driving event and I meet the CF C level of the CF industry down in Friedrichshafen and they are telling me about, “Wow, we really improved our reliability scores and we have really punched up our cadence around the product X, Y, and Z,” I go back and I say to my team, “Hey, I just met this team over there. They’re doing something fantastic. Can we start?” It’s that spark, which to some extent happens to cross over in this ecosystem as we start to be much more connected and dependent. I think that’s one point.

The other one is: if you look at the individuals who are today in IT, they don’t look like this anymore. I’m a Cobol, Pascal, HP 3000, JCL person. That’s when I grew up. That’s my heritage in operations. The guys and the girls today in these teams – they are completely different. They want Python. They wanna do sexy things. They wanna do fun things. They wanna show what they can do. And they’re looking for inspirations from their leaders as well, and they want to see that they can make a difference. I think that is also, from a cultural perspective, I think – of course it’s important but I think that’s also a driving force. And that’s not just the individual contributors but also the consultants and the C levels who are – I call them the flip-flop-wearing, chino-looking guys who go to the conferences, which we’re seeing them; I’m like, “Oh, I think I’m overdressed with my suit.” That’s the people who actually make DevOps happen, and they wanna have fun. They wanna do things. They don’t wanna do JCL and things like I did in a boring ops group dying of boredom.

Ashley: I think you’re talking about a couple of things, Eveline. One is the attracting talent, right? People have more selection, economic conditions aside, more selectivity about the kind of work that they wanna do, the companies that they wanna work for. There’s also just: how do you learn to develop software? If DevOps is what you’re coming into, a way of developing software, you’re looking for organizations and you expect that approach. So I think your point is right on. It’s also the audience of the people who are gonna be the adopters or the embracers or the champions of doing this. So that all makes a big difference. The command from on high, as Mark was talking about, the tablets – there’s an expression for that: “This too shall pass,” right? That’s the reaction, usually, of those kinds of initiatives. You have to have an option. And I think you spoke to that really well.

Shimel: Look, if you’re a Silicon Valley cool kid or you work at one of these organizations where flip-flops and jeans are the rule and you do the hair thing and all of that – I don’t do that so well anymore – that’s cool. But, Louise, you’ve done transformations at what we may think of as large, stodgy financial organizations, right? And they’re not Silicon Valley-based and they’re not a jeans and flip-flop culture. So how does it play there?

McCarthy: Actually, funny you were talking about flip-flops, high fives and cappuccino. I worked in government actually for a little while, the tax authority, and that was a time when the government was setting up its ____ global digital authority. And everybody in the government, all of a sudden they change from suits to wearing flip-flops and high fives and cappuccinos, and it was like a world away from the starchy government.

But, anyway, moving on to the financial services, yeah, the financial services – I’ve been lucky enough actually to do transformation in legacy financial services, and the big boys like the HSBCs, for example, which is complex. It’s like turning the Titanic around. And I’ve often written articles around: it’s like moving deck chairs around. The reason why I say that is because automation is the way forward. We talk about automation in many guises. Automation takes out people. It takes out transactional-type activities. But the legacy banks just struggle to do it. So I say it’s like moving the deck chairs around the Titanic because of the legacy system they’ve got. Transformation – they talk about it. They move things around. But nothing real and concrete actually comes out of their transformation, which is really sad. Because there’s great opportunities there in the legacy banks.

And on the other side of the fence, I’m working currently with a contender bank, a digital bank, which is new. It’s new. It’s fresh. It’s green. It’s almost as green as your screen there, Alan. It’s a green ____. And it’s great to be able to take the whole end-to-end customer journey and see it digitalized. And how quickly you can change and transform. And developing and changing technology with that suite, the same thing end to end, it’s just awesome to be able to see how quickly it happens. Whereas the legacy banks are still thinking about planning it, talking about it, cogitating over it, when the small guys are out with a new technology.

And one of the things that I’m often transforming whenever I do my transformation – it’s not transformation, it’s Christmas; it’s for life in my mindset. So it’s around continuously thinking about the innovation and it’s about encouraging these legacy banks to have innovation departments that are constantly thinking about the new technology that’s out there to take them ahead of their competitors. So like these digital banks, if the legacy banks are doing this, they’re actually seeing a way of making it happen quickly. And I think that’s the problem that we’re constantly battling: the bureaucratic slowness of moving Titanic.

Shimel: So clearly the kind of organization you’re at determines, or will have a huge impact on this. Guys, we’re coming on the back side of our time limit here. I wanted to talk a little bit about: okay, we’ve made the decision. We are moving forward with our transformation. We are adopting DevOps and agile and these new ways. How at the sea level do we – short of coming down from the mountain with the two tablets in God’s own writing, how do we translate that to the troops? How do we effect the organization? That this isn’t some passing fancy of the CIO and it’s not gonna pass in the next quarter. This is really the way we’re doing it. How do you make that change down the ranks, get people adopting as champions and being successful with it? Mark?

Settle: You know, it’s not unlike an initiative around security. When you talk about cultural change within an organization, I think leaders don’t always appreciate what a huge impact they have on the people that they lead. You know, people take cues from the way you use your time, the things that you show interest in, things you follow up on. Your time management sends tons of signals to the organization. And some of the operational metrics that I poo-pooed before as being of no interest whatsoever to people outside the technical areas are a great way to kind of keep score. You go back to what Eveline said: If there’s a sense we’re making progress, some of those ____ celebrations can be really important.

I’ll just leave you with a thought. I worked with a guys several years ago who used to say, “What interests my boss fascinates me.” As long as there’s some sustained interest – and to go back to, Alan, what you said before: I can just come back from the Forrester meeting all jazzed up, and then two months later I go to a Gartner meeting and now I’m on a whole different tangent. Now I think it’s automation; we gotta get RP robots in here. That’s gonna blow the business up. And then people in the trenches are like, “This too shall pass. He’ll go to another meeting. But I’m not gonna get my –

[Crosstalk]

Shimel: Come back with some other toy, yeah.

[Crosstalk]

Settle: “He’s so crazy.”

Shimel: Yeah. I used to feel it was whatever was the last book I read. That was the next greatest thing to me, right? ‘Cause I just read that book. But, Eveline, fundamentally – and this is something the DevOps Institute is deeply ingrained in – it also becomes a question of: how do we upskill our workforce? How do we prepare – do we just go out and hire new people? That’s hard. Do we upskill our existing people for this? At the C level, how do we effect that?

Oehrlich: Yeah. So, from our research at the DevOps Institute, we know that most organizations are actually preferring to leverage their existing resources to train them and to upskill them. Now, upskilling of course has its challenges because you don’t just upskill around processes of learning a new way of doing continuous delivery, or it’s not just about upskilling new technical skills. It’s also about human skills. That’s I think the challenge. A lot of organizations are biting themselves into that – or pushing themselves, or actually locking themselves into the corner. They think, “Yeah, let’s give them AWS training. Let’s let them understand what the latest DevOps platform is and give them some language skills around whatever the latest hotshot technology programming language is.”

But it’s also soft skills or human skills which are necessary. People need to understand how to work empathetic, how to collaborate, how to connect, how to cross functional borders, how to understand when a security individual tells me something. So having skills around these different categories is important. And there is investment needed. We see that, unfortunately, 7% of survey participants we had last year said that they have no idea what their upskilling programs are. We know 37% of these individuals – a very large sample size of almost 1,200 – said that, “We don’t have a program in upskilling.” And the rest of them either are planning one or have one. So that’s really unfortunately poor and not enough. So, anybody listening in, get ready to upskill your people. Start thinking about training. Start thinking about exchanging knowledge and allowing them to learn. Give time.

I, for myself – and we’re doing that at the DevOps Institute a little more, and our CEO does that a little as well. I call Friday my learning day. And it doesn’t matter what happens. Unless the CEO wants me there, Friday is my learning day. I learn French. I learn about design thinking. And I’m learning about metrics. That’s it. And we all have to do that. It’s very important.

Shimel: Agreed. Louise, you go in as a consultant. In terms of the skill level of the workforce, do you try to upskill them? Do you supplement it with fresh talent? It’s hard getting fresh talent in. Mark, you know in the Valley they cut each other’s throats for this. How do you do that?

McCarthy: It’s an interesting thing because you’re trying to fly an aircraft while changing the engine in some cases. And the same people _____ transform are the same people that need to drive the aircraft. And also if you call in too much fresh talent, then you would probably put the noise in the joint of the people that are supposed to be helping you run the process anyway.

So the way I’ve done it is I’ve gone in and we’ve identified some highly skilled people that know the processes really well and then supplement them with some more transactional process mappers and people like that. So that those people that run the processes can also see things like: how do they do the process mapping and how do they identify the paint points? How do they convert it into business cases? How do they use it and then convert it into technology?

So on that journey, the people that are running their processes are also being upskilled at the same time into continuous improvement and transformation. But I’d say that there’s also – it’s not about upskilling necessarily on all sorts of things. Because as technology’s changing, there’s less the need for upskilling because a lot of technology is self-serve-type technology now. A lot of the RPA touring now. People can do it like they learn Excel, like they learn Word and things like that. so the upskilling like it used to be, about spending months and months programming and that type of thing – there’s less the need for that. It’s more about the upskilling in terms of continuous improvement. And it’s a cultural change, I think somebody mentioned earlier. So it’s going in and using the resources that’re there, upskilling those people, and slightly supplementing them and doing hands-on job training.

Shimel: Excellent. Mark, Mitchell, I’m gonna give you each a chance to kinda close it out here, and then I think we’re about outta time. Mark, final thoughts?

Settle: Let me just make a final comment along the lines of this last topic. I’ve gone through many of these reskilling things, and seeding that group with new talent I think is essential. I mean, if somebody came into me and said, “We’re gonna go to DevOps and you can have consultant money; the consultants will come in; they’ll be here 90 days, 120 days” – this is an acquired skill. It’s almost an art form at its finest. And the devil is in the details. And the day the consultants leave, everybody’s left to their own devices, and it’d be just like saying, “Let’s just shut down the data center and move everything in the data center up on AWS, and we’ll get some AWS consulting in here, and then they’ll leave after 90 days, and you guys run all the production systems up there in that whole new environment after 90 days of familiarization.” I don’t think too many companies would take that kind of a risk.

So I think people get so carried away with thinking that reskilling can be effective, that people will come to embrace it. And, again, I hate to say this, but in my personal experience, if you reskill a population of people, 20% will be superstars, 20% won’t get it, and 60% will be good enough. But if one of the 60% left, you’d recruit somebody in with a higher skill level than the person that left. So they make forward progress. I’m not denigrating people’s commitment to new things. But you’ve gotta bring in that fresh talent that’s been there and done that. They know what it’s supposed to look like, right? And they can look around a corner and they can see the big fuzzy hole in the road that we’re all gonna fall into here in the next two months.

So that’s my thing.

Shimel: Mitchell, you wanna bring it home?

Ashley: Yeah. I’d like to just wrap with the human element, but maybe from a little different perspective. You know, people react to change in different ways. Your advocates – great, they’re all about it. Your resisters – love them ’cause you can actually work on that. You can help. You can help bring them along. It’s that passive unspoken middle ground, the folks that’re waiting to see: “Before I commit myself – I’m not gonna put myself, my job, my career at risk for this next thing. I don’t know if I can do it.” And the idea of bringing people in – I think one of the main purposes is to show the team, A, it can be done, and, B, they can learn it. So it isn’t: bring the consultants in for 30 days, hand over what they did, and now everybody goes, “Now what do I do?” Right?

So I think if you can de-risk, address the fear of what this means, that: “You’re gonna be able to do it and we’re gonna stick with you to help you get there, help everybody get there. And if there’s some folks that choose not to go along the journey, that’s okay too. But we’re all in this together.” I think you’ve gotta address the human element from a very personal: how does each person feel about this and whether they’re signed on to do it? And that’s gonna guide your success. That’s been my experience.

Shimel: Absolutely. Well, guys, we’re about outta time. Mark, Eveline, Louise, and of course Mitchell, thanks for joining us on this episode of DevOps Unbound. Many thanks to our friends at Tricentis for their sponsorship. Until next time, this is Alan Shimel for DevOps Unbound. Be well, be safe, and we’ll see you soon. Bye-bye.