Alan: Hey everyone. Welcome to another edition of Devops Unbound. Devops Unbound is a biweekly video series featuring relevant topics in devops. We go wherever we think develops is going and what we need to shine a light on. Devops Unbound is sponsored by our good friends at Tricentis and we thank them for their sponsorship. In addition to the biweekly Devops Unbound show of which you’re going to watch one right now hopefully every month or so we also do a devops live roundtable with an expanded panel that’s live and open to the general public for questions as well. This episode of course is a recorded one, not a live roundtable. But if you go to Devops Unbound on or devops.com you can see the schedule if you’d like to perhaps attend a live roundtable in the future.

But with that out of the way let me jump into this episode’s topic, leading a devops transformations, lessons learned. And I couldn’t think of a better panel to have us do this. For me devops, leading a devops transformation has always been kind of synonymous with my friend Gary Groover who wrote a book leading the transformation which early on in my in devops.com when we first launched was a big staple of what we were preaching then. Gary, welcome to Devops Unbound. Maybe a little introduction about you, your company and your background.

Gary: Great to be here. I’m Gary Groover. I led several large transformations. Probably the most one you’ve heard of most is the one at HP where we transformed and got a two to three X improvement in productivity. I’ve written four books in this space and I spend my time now trying to do everything I possibly can to help organizations transform how they do software development because it had such an impact on me and the businesses that I was part of.

Alan: Fantastic. Ok. Next is a woman who is also no stranger to devops transformations herself, a lot of them in the government and government contractor world where she lives a lot now. It’s Tracey Banon. Hi Tracey.

Tracy: Hey. Hi there. Thank you for the invite. My background is as a software architect and engineer so I’ve been living devops for a long time because I needed to get software into the hands of the end users and I needed to do it efficiently. Part of that required us to get that transformational thinking going. So I do spend time like Gary does in the middle of my client and my sponsor’s spaces helping them to understand, really talking straight with them about the differences that they’re going – the different thought mental model that they have to bring forward ‘cause it’s not easy. But I know we’re going to get into that today. Really excited. I work currently with the Mitre Corporation. They’re a federally funded research and development. And what that means is that I don’t compete with industry. Congress chartered us specifically to provide the expert leadership to the government to help them move in the right direction. So a little bit different perspective. Really happy to be here.

Alan: Thank you Tracy. Last but not least is William Berry. Hey William. Welcome to Devops Unbound and maybe a little introduction.

William: Yeah. Absolutely. Thanks Allen. It’s great to be here and great to be here with this panel. So I’m Will Berry. I lead our business engagement at Tricentis. I help our customers with aligning our initiative or their initiatives to continuous testing so that they’re able to derisk that aspect of delivery, be able to make those timeframes deliver faster and being able to achieve those goals that they have set forth.

Alan: Great. And thank you for joining us. So guys the topic is devops transformation. When I first started devops.com I was excited to see all these companies undergoing devops transformation and I really relished talking to as many practitioners, representatives of other, of organizations as I could to see patterns, to see what was emerging as what was the best way to do this. Right? ‘Cause there was the cultural aspects and the tools and the people and the processes. Right? But what was the best way to bring it together? And also remember when I started devops.com there was this silly in retrospect silly argument of whether devops was something just for startups and Silicon Valley unicorns or as Gene Kim would say was it just for horses as well, right, the enterprise. Were large enterprises able to adopt a devops kind of mindset.

And there were believe it or not – Gary I’m sure you remember this. There were fights raging on the Twitter sphere and the blogger sphere about was devops an enterprise thing. To me I always thought so and the consensus was yeah, of course. Stage two was ok, so all these companies started saying ok, we’re going to do a devops transformation. And you know what? A lot of them didn’t get the results they were expecting and there was this loser tech.  Devops stuff don’t work. So Gary I’m going to ask you to kick it off. I’ve given a little historical perspective. Do you think I’m crazy? Is that –

Gary: No.

Alan: Or your thoughts?

Gary: No. But the debate that I’ve had with Gene over years is if you’ve got a large system of people that need to work together the things that you’re going to do are different than you do with a small team.

Tracy: Exactly.

Gary: And a lot of the debate that I get in with Gene is Gene saying no, no. This is how the small teams do it so now we need to make the large teams do it like the small teams do it. And that just doesn’t work and fundamentally I think that’s why a lot of devops things struggled and failed.

Tracy: But small companies don’t necessarily succeed either because – so first of all it’s not about doing devops. Allen you’ve heard me say this before. I get so peeved when people say we need to do devops. They’ll bring me in and say help us. We need to do devops. We need to start to transform so we can do devops. And I’ll push back and I’ll say why. What exactly are you trying to accomplish? Right. Let’s get back to brass tacks. Let’s have a reason that we’re doing something and then we’ll track towards it. We’ll adopt the principles that are appropriate for you. But I’ve seen small organizations fail because it is pursuant to your context. And I think that’s where you’re going Gary.

You’ve got to know the context of that organization. You’ve got to understand what its business objectives are, its engineering objectives are and its people. And then you figure out which pattern might apply to them because it’s not going to be – there’s no lather, rinse, repeat recipe. There’s not a singular playbook for this. And that unfortunately is what everybody is looking for. They’re looking for that playbook. I just – I need the checklist of what I need to do. Can you give me a book ‘cause I’ll just follow that?

Mitch: Tracey I’ve seen many an organization where they will spin off a group sort of a skunk work project like back in the ‘40s and ‘50s, right with the X1 things. And those can work. They can work as a start but oftentimes they become a thing themselves and then they hit the corporate the white corpuscles, right, that come out and attack the foreign object. So I think it’s all in the context of the organization. If you’re savvy about what makes an organization tick. We’re all about data.

We’re all about measurement. We’re all about whatever it is, finance, whatever it might be and know how they adopt change or don’t. You’ve got to sort of build in the psychology of ok, great. How do things get adopted here? How do people get on board? And it’s never easy but it can be a lot harder if you sort of walk in with the bright shiny knight and sword and we’re the new savior of the day and poof, you’re the first one to get skewered and taken out to the back.

William: Yeah. And I think you hit it. I mean it’s an organizational mindset and you can kind of see it today. I mean you can see the responsiveness of what companies do in the market and what their competitors do. And you can see who has that mindset and who doesn’t based on whether or not I release like a new phone type strategy. Can T-Mobile respond? Can AT&T respond? And who responds the quickest to be able to address that?

Tracy: I was having a conversation yesterday with a fellow by the name of Steven Spear. He’s a professor at MIT Sloan. He’s done a lot of –

Mitch: Yeah. I know him well.

Tracy: Had a lot of really good thought leadership. And we were talking about the cultural overlay and how that makes a difference because we keep looking for that recipe. We keep not understanding what the culture is. Now I don’t push for culture change. I never push for culture change because if you came into my house and said you need to change your culture the first thing I’m going to do is put my hand up and say no, I don’t. But I am into culture building and culture understanding because we build a culture together. So the cultural part means a lot. And I’ll go back to what Mitch said about context, understanding the context, the cultural context of that organization.

When you think about government specifically that’s where I’m living a lot right now especially on the DOD side of the house. They are in a zero defect like low risk tolerance. Right? They need to make sure that it’s right the first time. Well that adds another level of complexity to the mix. So yeah, I want to go fast but how fast is appropriate? I want to adopt these principles and how many of those principles do I apply that allow me to get there in a cyber secure safe way. Right? How do I make sure the missile hits the target? How do I make sure that the plane is flying the right way? I mean Willian you brought up about the continuous testing and what Tricentis does in that realm. It’s interesting that the transformation has to include testing in a way that it hasn’t done. And it’s not just that automated unit test. Just automate the unit tests and we’ll be fine. Get some high code coverage. Hey. Hit 90 percent code coverage. It’s not that, right? There’s a bigger, broader set of this.

And I want to bring myself back though. Something that you all said earlier is that it matters the understanding the context of the organization matters. But where do you start? So if you’re walking in the very first time to meet somebody new Gary how do you approach counseling – I’ll use that term, counseling a new organization that you’re meeting whether they’ve been in the government space, whether they are international, whether they are a small US startup. Where do you start with that exchange of knowledge to figure out how to help them?

Gary: I tend to start by trying to understand what their problem is and trying to figure out what they’re doing. If I can get the leaders to engage not just in empowering the team and getting out of the way but really trying to take the time to understand how their current processes work and work with them to try to figure out how to make the waste in their current processes visible and then spend the time to let them pick the ideas that they think will help the most. I don’t ever go in and do devops.

I think that’s the most – I think it’s the most disservice we’ve done to the industry. It went to – it’s kind of like trying the automobile industry trying to copy Toyota in the ‘80s. Eventually they figured out that wasn’t working and it was stupid. The software industry stuck trying to copy what worked for other people instead of trying to create a culture of continuous improvement and letting the organization pick the ideas that they will champion, the ideas that they will embrace and the ideas that they will invest in making those improvements. And if we can’t get the leaders to do that you’re never going to see the organization transform.

Alan: So let me comment on that. You can’t change human nature. And there are certain – in the technology industry we emulate success. We emulate – if you succeed, right? How many business plans did we see seven, eight, nine years ago that said I want to be the Uber of? Right? I want to be the Uber of testing. I want to be the Uber of name a business model. Because what Uber did, I want to be the Uber of. I want to be the Twitter of. Right? In the technology industries this is what VCs whip out their checkbooks for. Right? And so you’re going to get that. I don’t know how you avoid that.

Gary: But if you go into one of Tracey’s clients that’s developing a missile launch type system and you go let me tell you what Netflix did and how they made it work and how they had these teams they are going to check out. Never mind checking out. They’re going to dig their heels in so hard that they’re going to shoot down any idea that you ever had and you’re never going to make a bit of progress.

Mitch: You become the new missile target I think.

Tracy: Well hold on. It’s actually in between.

Mitch: Ok.

Tracy: There are. So Gary is right. Depending on the audience some of them will just, they’ll get ashen. They’ll look down and then they’ll put their hand up and they’ll say go away. But there is a growing body of folks who have come into this they’ve grown up as those developers. They’ve been hitting up against this and they are now becoming those leaders. So there is an amazing undercurrent that’s out there and I’m getting to work with them firsthand. They are looking for that air cover so to speak. Right? They are looking for those most – they want to go the whole way up to the Pentagon. They want to go to congress. They want people weighing in.

And here’s where it tracks back to the problem that you talked about Allen. We’re not talking straight and we’re not getting the messages out that it’s not about copy catting but it’s about learning from. If we go into it and say I don’t want to use the Netflix model. I don’t want to use the Uber model. I want to look at it and I want to be informed by it. And I was to juxtapose it against my unique context. That’s where we help to get real success, incremental improvement. But we also have to come back to learning fast, failing small, failing cheap is ok. That’s a mindset shift regardless of to the industry. We always say fail fast but people react to that so say learn fast but fail small. And if you can start to fail small, surface it, allow it to be seen, allow there to be transparency into the failure, discuss it openly. That in my mind and in my observation that’s actually transformational in nature because people start to look at that and glom onto it.

Now Mitch you mentioned something which is when you spin off this group and you say ok. You guys go be that new devops group. Can you guys go establish how devops work and you guys be a pilot project. The problem is when they succeed and come back and try to scale it. Well they’ve been partitioned off as though they’re a dot com. Right? They’re over here. They do this amazingness. And what they did isn’t necessarily scalable as is. And there’s another failure point that happens because now you’re in an organization, an enterprise that’s got a unicorn team that did great things. How do I scale that? Well I don’t just pick it up and copy it. Now I have to look at how information flows, how I go about teamification when I have lots of different folks coming from different consultancies and contractors. Not all software is written by developers and by organizational resources that are owned by one company. It’s actually getting to be kind of rare.

William: So I mean that’s it. That’s what I see as the biggest challenge a lot of times when it comes to speed is the management layer is ready for it. The management teams they want to be able to do it but the executive layer still operates in a very project based initiative based thought process. And so you see this like this was supposed to play into this larger role of how I roll out devops across my enterprise so I went to this team and I did this. But it was still in this big initiative.

It wasn’t allowing teams to fail fast. It wasn’t creating that environment where these managers can really dive into what they know and figure it out and drive it and then have somebody else consolidate all that at the same time, that larger level. We’re still very much when we sit in a board room we talk years and we talk plans and we execute against in that manner. We don’t always necessarily break it into these tidbits that we need to be able to empower our managers.

Gary: And it’s a big bang transformation. And I’ve spent a lot more time recently looking at organizational change management. And they say one of the biggest barriers to people adopting new ways of doing things is risk. Any risk and when you do these big bang transformation there’s huge risk and that’s a barrier. If you do a bunch of incremental large, small changes and you create a culture of continuous improvement that’s a smaller risk. It’s reversible. It’s kind of like Tracey says. You can fail or learn quick and you can adjust and you can learn along the way. And I think what we’re missing is we’re trying to tell people what to do.

And I’ve done this whole shift to teaching people the principles and the approaches of making their process visible, letting them pick things that they’ll champion and they’ll make work and doing it in small incremental bits that they’ll get excited and they can reverse and they can learn and adjust. And it seems to be getting a lot more success in terms of teaching people how to analyze their processes and letting them pick instead of telling them what to do and seeing them resist the changes.

Mitch: And Gary I think we have made this repeated mistake over and over every time we introduce a change. It’s about telling people that they’re wrong and what they’ve been doing is wrong and it’s bad. And people have learned through some hard knocks of the folks that come in and do that, they come and go. Right? The last person that did that got fired, right, ‘cause they ran up against this or their project failed or whatever. And so it’s more about like let’s take the things that we do really well and let’s figure out how to do those even better. And as you were talking about let’s find the places where we’re either creating waste or there’s a bottleneck there. Give people a common problem to work on, not a common enemy, you, the change agent. You’re the person with the arrows in your back. Right? You’re running away from the last change project.

But I think that’s – and it’s always the shiny object, right, the next great thing that’s going to solve all our problems. Well if we just went all to Cloud native. If we just all went to devops. If we just all went to agile. It’s never that simple. It’s how do we take the ideas that this has and adopt it in our way and our style and to match what our objectives are. Because as soon as you create computing objectives like the skunk works team is this to show everybody they’re wrong and this is the right way to do it. Well poof. You’ve automatically, you’ve failed already before you even get out of the gate.

William: Yeah. And I think there’s a bit of a misnomer in the term devops because as soon as we say dev we lean towards developers and we think oh it’s a coding initiative. But really in business we’re all capable of developing something whether we’re developing a strategy or initiative or some way that we’re going to take our business to market. You’re doing something that would create a change in your organization. So then it’s about how do I make sure that that change is quality and how do I measure the impact of that change and so that I can know that I fail fast? Because that’s what I see is that we sometimes get too far into well it’s more about the initiative and not about the measures and we have to have them both together. And we have to have this be a mentality that everybody is developing something for the organization.

Tracy: There’s so much fodder with what you just said. I was jotting down a couple of different things. I wish I loved the term devops anymore. I don’t anymore because it’s another label. It’s an overloaded term. You’re right that we are hyper focused on dev. We leave the ops out of this. Yes, I know we’re focusing on this and we’re getting smart about ops. But we put so much pressure on the developers to go fast. Right? That’s what people say. Developers have to go faster. We’ve been so hyper focused on enabling that to happen and that doesn’t help transformation. And so then we say well, what we’ll do is we’ll give you a maturity model which if you have a maturity model then you can just figure out how devops-able you are. How devopsy are you because I’ve got a maturity model? So hater on the models. I do agree that it’s great to have a metric or a measurement that matters as long as you know how to change it. Right? You know what it means and you don’t weaponize it.

And a buddy of mine, _____. You guys know him. He’ll talk about the weaponizing of metrics. But I want to come back to something that you all said about not trying to change a culture but rather helping them to grow that culture by teaching them. One of the things that I’m running into is depending on the organization the individuals have muscle memory. And I’m talking incredible muscle memory. So I’m finding that if I have that same pod and I don’t insert some additional change agents, just mix up the group a little bit, I can’t get the change that I want.

And there have been some interesting studies about exactly that in the organizational change management area. If you have a group of ten people and you say ok guys, suddenly we’re all going to start behaving differently because somebody has come in and they’ve given us help and they’ve given us some guidance. What’s the likelihood that that nine or ten person group suddenly manifests without amazing amount of coaching and rigor and over the shoulder help.

But imagine or maybe you’ve been in that position where somebody joins. Somebody new joins and they have an energy and they have a different perspective and they have a diverse way of coming at it. Well then transformation starts. It’s no different than a blended family. Family unit as it is. You bring somebody new in. Somebody marries in and they have a different way of cooking and they have a different way of talking and they have a different way of doing something. Then suddenly its catching on and its becoming part of the fabric of that family. I see devops transformation as kind of putting some additional spice in. We’ve got to have the scaffolding around it. We have to have that education that’s out there.

But we’ve got to have those catalysts, those humans that bring that energy to help propagate and to help the people around them, the developer who really gets it, that quality engineer who is really excited about things, the leader, right, who is out there, able to fail publicly about something that they’ve done and really foot stomp when their team fails about how great it was that they’re moving forward quickly to resolve that. So Gary I’d be interested in your thoughts on especially on I saw you grimace when I said maturity model. Interested to see what your thoughts are about measuring transformation. How do we start to measure transformation?

Gary: So I’ve gotten to the point where I’m like you. I’ve quit using the word devops. It’s not that the principles don’t work and aren’t effective. But it’s just so balled up in a wrapped up image that I think in a lot of cases it’s doing almost more harm than good. Two, I’ve gotten to the point where I don’t want to measure whether a team is doing devops and I don’t want to do this ‘cause that assumes everybody is going on the same path. What I’ve tried to do is we’re trying to make organizations more productive and more effective and we’re trying to get them to improve on a continuous basis. And we can’t really measure throughput and some of the different things.

But what I think I’ve gotten really good at doing is measuring the waste that slows down organizations. And so we make the waste visible. We teach people how to make their process visible, how to make the waste visible. And then we give them key metrics that show when I made this change I removed this waste and inefficiencies. As much as I fought the certification thing I’m finally on board. I tried to emulate what was done in the manufacturing where you’ve got a white belt where you get a basic knowledge but to get a green belt or black belt you’ve got to do an improvement project. And in that improvement project what I’m trying to do is motivate people to make a change, make an improvement. And when you do that I’m trying to quantify the waste that they’ve removed from the organizations.

And most of the improvements that I’ve seen so far they’re removing like $50,000.00 – $60,000.00 of annual waste a year in the improvement project. And they’re able to go to the company and the organization and say look at the waste that I removed. Can I go do another one? And people are going yeah, yeah, yeah. Let’s go do another one. That made sense. Let’s go do some more of those. And we’re creating that culture of little changes one by one. And if I can get the executives to engage the magnitude of the improvements that they’re going after are just orders of magnitude higher because they’re in a position to have a higher impact on the organization just because of where they sit and how they work across teams.

Tracy: The surfacing of waste is so important. One of the air force groups that I’m working with, massive PMO or should I say massive joint – it’s actually a JAPO, a joint PMO with six massive PMOs underneath it. And we strategically went through and we did I call it rapid value streaming. It’s not lean six sigma official value stream mapping. But it was getting together and we had to be remote but using mural and talking through their processes at a very high level just to surface it. It was about two 90 minute sessions, just enough that people were like huh, look at that and allowing their own stories to hit them in the face in a very open and engaging way. We didn’t want to indite anybody but it was having them tell that story together and it was surprising just that three hours how much that meant. And we did that with each one of these PMOs. How much they learned from that to help them directionally.

Now there’s a lot of other massive challenges with acquisition and policy and other things that they have to deal with. But your point of identify where the waste was. Seeing something go into an inbox as an attachment, a Word doc attachment and knowing that it was sitting there for 18 to 25 days because there weren’t enough humans to even look in the inbox. Those are some of the things that you don’t even think about as impacting a value stream or the delivery of a flow. There’s so many amazing twists and turns that you get into. Gary do you – and I guess I should ask everybody. Are you, when you’re looking to identify waste what are some of the techniques that you’re using to identify waste?

Gary: I tend to map the deployment pipeline. And some people will call it value stream mapping. But value stream mapping assumes you’re doing one thing at a time. But in software when you get into the build release process you’re doing it as a group.

Tracy: Yeah.

Gary: Right? And so I think there’s a lot of errors that a lot of people make when they value stream map that don’t highlight the types of things that slow software organizations down. So I do value stream mapping kind of but I map the deployment pipeline and I kind of put some metrics on the requirements process. And I use that to make it visible. If you can do what you did and get the executives to take the time to understand their processes and make it visible you’re like orders of magnitude ahead of anybody else who is going to do this type of stuff. To me it’s so important that if I’ve got a company that’s willing to do a prototype and they can get the executives to sit down and go through my training I’ll give them the white belt training in a way just so that they can get a line and see it.

And I had an organization come in the other day that Brian Fenster sent me to them and they came up and they sort of said we’re thinking about surveying our culture and doing a cultural survey as the start of our devops. It’s like what do you want to do? I finally stopped. I said here. Take this free training and go off and do it. And they had three executives go off and do it and they came back together and said I can’t believe how well it aligned our thinking. We had this disconnect and we were all seeing it from our own personal view. And as we took this training it aligned our thinking. If you can get the executives to do that I think you’re going to be – the probability of success for seeing results is going to be orders of magnitude higher.

And I’m at this point of the career where yeah, I do it for a living. But I’m trying to help as many people as I possibly can. And I worked with David Farley to help with the technical side. And we’re trying to figure out how do we – now that we’re in this point in our career if we can digitize our knowledge we can help a lot more people. We can help them more cheaply and they can go off and do these things. And then they can do it for themselves and if they do it for themselves they’ll embrace their ideas and make their ideas successful.

Tracy: Right. Teach a man to fish. Teach a man to fish.

Mitch: I’m curious. Let me throw a little wrinkle in this. This sounds like a very kind of well thought out methodical process and I think a lot of it is. What about organizations that are under great threat? We have a lot of companies who their supply chain is a total mess. Right? And they’re scrambling to get new suppliers in place, new transportation if you’re up on that part of it. There’s a lot of organizations who are dealing with either market threats, just even operational threats. And so they can’t do back and let’s look at the next piece of waste. Or maybe that is a method –

Tracy: I was going to say I think we’re talking about exactly the same thing Mitch.

Mitch: How do you do that when you know what’s hitting the wall and you’ve got to like make something happen right now? At least that’s what management’s going to come to you and say. We might not have jobs tomorrow. Go fix this.

William: Yeah. I think it goes to what Gary is saying. Like look at your release pipeline. And what I see a lot of is this idea of what I call an avocado release which is you have all these people do this work and then it gets to this decision about whether we go or no go and people hold onto it like an avocado. They’re like is it ready, is it read, is it ready, oh it went bad. We’ve got to get it out there. And you don’t have this confidence in your organization and that’s where a lot of this waste comes in to make that decision, to have that go, no go to be something that’s almost automated to a sense of here’s the report. Here’s the impact. Make the decision and move. And that’s where these companies are struggling from supply chain perspective. If I’m going to hire a new vendor and I have to get 10 – 12 sign offs and it takes two months those transportation vendors are in high demand right now so by the time I get my signatures on paper they might be gone.

Mitch: They’re gone. They’re busy.

Tracy: But at the end of the day doesn’t it all track back to identifying what your set of whys are? You’ve got an imperative. You’ve got to solve it. It’s not going to be lather, rinse, repeat for everybody. If you have a supply chain issue, software supply chain or firm goods it doesn’t matter. If that is your issue and your challenge then you’re going to gaze at that and you’re going to turn it fast and you’re going to say what’s the waste. Right? To Gary’s point looking at that it might not be a devops pipeline. But if I’m looking at how fast it takes to get information in to me, how fast does it take for us to sign that off, we’re going to apply the same type of thinking Mitch so I don’t see that imperative as being any different than the software is failing in production or I can’t get a new user onto it. It’s another risk or challenge and it gets prioritized at the top of the list and all eyes are on that to solve it together.

Gary something that you and William both said really resonates with me and it comes back to that education piece. I’m at that same point where my goal is to share experience stories, get the information out there so that people are educated. When the taxonomy is not shared, when we don’t have a common lexicon. I mean why do certifications matter? Well the reason the certifications matter often is so we’re speaking the same language. Why sometimes will I look for particular certifications? Not that I know that the person can actually do the particular type of task coding but at least I know they know the words.

And in there I think that there’s merit in us thinking about getting to those lexicons, common lexicons that what is devops – oh I’m not even getting down in that path. But if we can in our own sphere of influence get to some more common terminology, augment that with the right types of education so that people can consume this and they can get on a level playing field we’re going to see continued growth and transformation. That’s at the end of the day and that’s what we’re trying to do.

Gary: And I want to go back to a little bit what Mitch said. I think that the habit that the executives get into is I’ve got this burning fire and I’m just going to beat up the teams and I’m going to beat the teams until they work harder. I had a group of executives go through this training and the senior vice president stepped back and said I had no idea of what people were dealing with on a day to day basis was getting in their way of delivering. And if they don’t have any idea of what’s getting in the way of the organization delivering they’re going to continue to focus in on we’ve got to put this fire out. We’ve got to put this fire out. We’ve got to put this. And so a big part is getting them to step back and get visibility to the things that are slowing them down.

And if they’re driving the dev team like crazy they continue to create more stuff and they’re doing manual testing they’re got an unsustainable process because dev writes 100 lines of code and test has to test 100 lines of code. That’s iteration one. Iteration two you’ve got 100 more lines of code and then QA has to test 200 lines. Right? It just doesn’t work. Right? You’ve got to get past that. But if they don’t see that and they don’t have appreciation for what the teams are going though and what’s slowing the organization down, they’re going to do nothing but what you said Mitch which was beat on what the business is beating on to get delivered. And the key is how do we get these executives to slow down and take the time to understand what’s getting in the way of getting what they really want.

Mitch: There’s nothing like a crisis to get people to rally around at times. Now if it’s manufactured crisis and it’s the 52^nd crisis this year of the week that’s only what you’re describing too. I think one of the things whether it’s a crisis or not when you can rally people around a set of challenges, set of problems. We’re really ok. Our objective, let me give you a real example. I’ve gone through two transformations both involving Cloud and devops and they were both because the conditions had changed and what we were targeting, what we were shooting for wasn’t the same target anymore. And one of them was we had moved to a much more cash sensitive company, changed the structure of the company. So we couldn’t invest in hardware, etcetera.

And so we said ok, this isn’t really 100 percent true but let’s pretend for a moment we don’t have cash. I mean we don’t have money to go buy lots of hardware and we want to figure out could we leverage the Cloud. And it wasn’t a gun to our head but it was a let’s do that scenario and figure out what we do or we need to change how we’re developing software because while we have a monolith application there’s part of it that we really would like to be able to change more quickly and iterate on and do some services around. So you can use and sometimes it is a gun to your head. Everybody is going to be working from home next Monday so figure it out. But you can use those kind of rallying cries to say ok, this is the problem we want to work on. What could we do?

Tracy: Well it’s pushed by circumstances or pulled by a drain. Right? Like carrot or stick, circumstance or drain. Tracking back to something Gary said and Mitch that you brought up the education part of this is important. There’s a group of us that go across industry, government, academia who have been meeting and talking about how do we very rapidly expose the leaders to a day in the life in their organization because it’s not going to be lather, rinse, repeat. And Gary I know you have some really incredible training and education that are coming up that you’ve been working on with Dave. And I’m excited to see if that’s something that I can leverage in this space.

But that is becoming one of our rallying cries is exposure. Simply walk a mile in the moccasins. They don’t have to do hands on all day development but I want them to see what it’s like to get those, their priorities changed. You have a sprint but now you’re telling me that I have to change up everything that I’m doing. You’re forcing me to go faster and faster and you’re only worried about my velocity and my burn down and you’re not thinking about sustainability. You’re not thinking about the quality of – you’ve not thinking about the fact that you want me to dev sec ops and I’m a hobbyist. I haven’t been trained as a cyber expert. I don’t know secure coding standards.

I mean there’s a lot that we’re putting onto them and we need to educate those leaders, a day in the life. I think a day in the life the other way might be helpful as well. So how do the developers, how do the design teams, how do folks who are delivering, how do they understand the stresses, the pressures and the strategies that the leaders have to undertake? Because I think that there’s both sides of it need a little bit of that cross understanding. But it is going to have to start with the leaders who have the bigger stick and making sure that they understand.

Alan: By the way so Tracey I don’t think it’s just two sides. This was a technique I forgot who I heard it from with people who do devops consultations and consulting which is have someone from the ops side spend a week as a dev, have someone as a dev go over to the cyber team for a couple days. Right? Have a leader do the managers role or have the leader do a non-leader role. Have the single contributor do – like empathy. Right? It’s one of the cornerstones of whether you want to call it devops or not. It’s one of the cornerstones here was empathy. And can you – I don’t know if you could really empathize until you’ve walked a mile as Tracey said in those moccasins.

And I think it goes across all of these kind of – I don’t want to use the word silos but all these kinds of roles that we’re talking about because I think you need empathy for respect and you’ve got to respect what every single person, human on that team does. I grabbed the last word ‘cause it’s my prerogative. We’re way over time guys but I didn’t want to stop you. Shocking. Anyway Tracey, Gary, William thank you so much for being our guest panel on this Devops Unbound. We probably cold have done three shows today and still not covered everything. But it was a great show. Mitchell I’ll give you the last word if you want to wrap it up and we’ll sign off.

Mitch: Well I just am in awe of the wisdom and experience that everyone on the panel is bringing to this and there’s a lot of good lessons here. If I walked away with one nugget it’s stop for just a moment and think. Take in, let’s take in what we’re doing and make sure we’re focusing on the right things or make sure that we’re learning what we can do to work on the next set of right things. And I think that’s if I had to summarize in a just general way I think that’s a lot of what William, Gary and Tracy have said today. So thank you all for that very much.

Alan: Ok. We’ll be back in two weeks with another Devops Unbound episode. Until then good luck. Be well. Thanks for joining us. Have a great day everyone. Bye bye.

[Music plays]

[End of Audio]