 Thank you for coming. I got to tell you, about 10 minutes ago, I thought that's when this thing was started. And nobody was in here, and it wasn't funny. My little heart hurt. And thank you all for showing up and making me feel so much better. So before we get started, take out your phones. Take a picture of that, okay? That is gonna be a link to this presentation. Also a link to get a t-shirt. Also a link to join me at LiquiBeers six o'clock tomorrow if you're around, all right? I stole this idea from Stephen O'Grady at Red Monk. And I really like him buying me beer. And so I thought I could buy you beer. So, close by if you're around. So, you know, look, y'all are doing amazing. Oh, did you notice that, the y'all? I'm from Texas, I apologize, all right? But y'all are doing amazing things. Y'all are having outsize impacts on your organization. And nobody's seeing it. And that's what this presentation is about. This is about highlighting the business value of continuous delivery, of showing that to the powers that be, and to get everybody on board to get you budget and recognition for being the hero that you are. That's what we're gonna discuss today. If you didn't want that, then you need to go to another room. I hope that we're all in the right place, okay? This is about leveling up and telling the world how awesome y'all are. Now, a lot of the times when we do continuous delivery, we implement a thing. And all of a sudden we say, oh my goodness, the billing app, it went from 72 hours to 15 minutes. Good job billing application team. And it was y'all that did this. So that's what we're gonna be discussing today. We're gonna be making sure you get the recognition that you have earned, not just deserve. And of course, I would love to see you tomorrow and buy you a fancy beer. So, look, keep in mind that this comes from a culture that I am most familiar with. This is very Western focus. Your mileage may vary. But if we're talking about being a hero, we really need to discuss the hero's journey. And you are the adventurer. You are embarking on a journey fraught with risk and peril. You're gonna change, you're gonna evolve, you're gonna pick up some cool doodads, you're gonna learn, and you're gonna return victorious and change as a person. Your epic goal is to improve the lives and fortunes of your fellow adventurers, these are colleagues. Your family that has suffered a natural disaster that's your company, and return to your home with riches, budget, a changed person, having a successful CD project that is across the entire company. So I was kind of looking for things to describe the hero's journey. I do Star Wars, I piss off the Star Trek people, I do Marvel, not everybody gets that. So let's work with Wizard of Oz. It seems like kind of a relatively common touchstone. And so, you know, at the end of this, you're gonna get your Ruby slippers. And that's what we're gonna talk about. Now there's gonna be three acts here. And the first one we're gonna be discussing are cast of characters. Who are the folks that we're working with? And first of all, this is you. You're Dorothy, you're the hero. You know, you're team members, this is your Toto, these are your DevOps, CD, CI, Ryder, Dice. All right, these are the folks that get it. They just understand it innately, they're natively. And of course, you know, right when this scene happened in the movie, and we don't see her, Miss Elmira Gulch, she just had some interaction with Dorothy. And she said some very, very mean things about Toto. And so Dorothy goes and talks to her aunt and uncle about this. And she's like, hey, this bad stuff is happening. And her aunt and uncle are all busy with the baby chicks. And this is very similar to the interactions that you've had with your company. We're too busy to automate this. We're too busy to improve this. We don't have time, we don't have budget. We're just gonna keep throwing bodies at the problem. So then Dorothy goes and talks to the farmhands. And hey, you know, this is happening, bad things are happening. And the farmhands go, you know, tell Dorothy, hey, hey, chill out, you're gonna get in trouble. You know, this is very similar to, we've always done it that way. You know, don't try and improve things, we're good here. And finally, we meet Elmira Gulch. You know, in the movie, she's the antagonist, but in this case, she really isn't. This is not the antagonist, you're, you're, you know, big bad, you know, big bad evil guy, big bad evil girl, your BBEG. That's not who this is. We're gonna talk about that in a second. But once we've met all these characters, bad things happen. There's a tornado. And then all of a sudden we're off an adventure. And amazingly, these characters look a lot like those farmhands, really weird. And you know, each one of these characters has joined your journey. And when you're setting out to change the entire organization, sure, you brought in open source technology. It's working on this one project. And the developers love it. The line of business owner loves it. The application PM loves it. Everybody loves it. But it's not getting outside of that core group of believers. And so while you're going on this journey, it's really important to understand for each one of these different people, the with them, what's in it for me? What is each one of these team members, each one of your characters getting out of it? Now, for your true believers, your rider dies, they just get this, right? It was like, oh yeah, of course we're doing this. You know, the folks that read Accelerate and are like, duh, of course it's like that. You know, these folks are gonna support you. They don't need to be convinced, but you need to understand when you're speaking with application developers, product managers, even business executives, they are very focused on their needs, just like all of us are. And that's okay. It's on you to understand where they're coming from. And that's what we're gonna be talking about in Act Two and Three here. You know, for App Dev, it's decreasing workload, hassle and heartache. All right, that's pretty easy. For our product managers, it's delivering their vision to customers faster with higher quality. Okay, cool, during on that. And certainly for our business executives, it's realizing more revenue or cutting costs. That's good, all right, dollars and cents. Each one of these is gonna have a different view of the world. And you have to kinda build your case that appeals to all of them. Now, I talked about this. In the movie, yes, she's the antagonist, but that's not the antagonist that you're fighting. There is no BBEG. There isn't, all right. What you're fighting against, ambivalence, apathy and inertia, you're fighting against the other 27 other priorities that your organization is struggling with. And you need to build a case. You need to appeal to the things that they believe are important to get the budget, to get the recognition. These are the things you're fighting against. It's not the executives who don't get it. It's not that other department that just doesn't understand it because they're chuckleheads. That's not it. They just, you need to build a case to fight against these three. These are your three enemies. These are your three antagonists. Okay, so let's talk about how we do that. Now, look, I know it doesn't look that way, but I am punk as hell, all right? And there was a period in my life where I was actually a tour manager for a punk band. And so there's kind of a little push pool inside me when we're talking about money like this. Because when I talk about DevOps, when I talk about CDM, it's like, no, no, no, no. This is about people's workload. This is about helping people, not just deliver better software faster, but also to get home to their family, to do cool things, the important things in life. But if you want budget, if you wanna spread these solutions throughout your organization, you have to look at it in terms of money. And so, a lot of times as CD professionals, we'll say, hey, we took this 72-hour process and it took it down to 15 minutes. It's no longer manual, it's automated. And we look at that and we say that that, well, that's inherently good. Of course, this is great. We should do this everywhere in the organization. And that might be where you're at today. We've had success in this pilot. We went from 72 hours to 15 minutes. Well, why aren't you implementing this throughout the entire enterprise? And we need to put this in terms of metrics that drive revenue that lead to cost savings. All right, so let's think about this. So when we talk about taking something from three days to 15 minutes, and it's like, oh, well now I can do this. I can fire off a process or it's automated. I go get a cup of coffee and it's all done. And some line of business owners like, so, these people don't care about your coffee breaks. I care about your coffee breaks, I really do, right? It's right around the corner if you want some. But you need to put it in terms that they understand. So 72 hours, that's three days. So three over 365. So if we have an application that's responsible for say half a billion in revenue, we're looking at a savings of $4.1 million. All I did was I took 500 million and multiplied it by three over 365. Well, shit, $4.1 million, that's a lot of money. We're no longer talking about individual time, individual times, we're not talking about a developer's time, we're not talking about a DBA or anybody else in the stack, their time. We're talking about dollars and cents. And this starts to get people's attention. But we can also talk about this in terms of opportunity costs. So opportunity cost is the cost that you have to spend, you have to give up to do another thing. So if it's taking you 72 hours to do a thing, what else could your team, your company be doing with that 72 hours? Well, we could be getting out more releases. We could have more features. We could be able to really change how we develop and release software in this company. I mean, think about it. If you take something down to 15 minutes that was taking three days, well, we can make a change and get it pushed out to the servers like that. This is powerful. This has also had some impact on security as well. That's interesting. And then finally, oops, sorry, I lost it. And then finally, we start getting into better utilization of resources. Do we really want people sitting around waiting for that 72 hours to be done? Do we really want to do the kind of waterfall deployment method? I don't think so. So when you take actual dollars and cents, $4.1 million at savings, we start talking about opportunity costs. We talk about better utilization of resources. Whoa, we got the beginnings of a business case here. This is not, well, it's really cool. Look at what I did. It's something bigger than that. All right, let's put all this together. All right, time check. See when I gotta land this plane. There we go. We're doing great. All right, so let's put this all together in an example business case. So we've journeyed down the Yellowbrook Road. We've got our friends. We've met our challenges. We've learned. We've grown as individuals. We've picked up some cool things. And so let's put this all together in an example business case. So we're gonna have three slides. Now, remember that QR code I showed you before? You can get these slides and get this business case. All right, so you can use it, go ahead, tear it up, claim it as your own. So the first thing we're gonna do, we got three slides here in a spreadsheet. Three slides in a spreadsheet. The first thing we're gonna do is we're gonna tattle. We're gonna talk about all the bad stuff that's happening right now. We're gonna talk about, wait a minute. Now look, on the technical oversight for CDF, I'm also founder at Liquibase. This is the business case that I have. I'm not pitching you database scheme updates, but you really should use Liquibase, it's open source. But I'm just putting it in there. So just kinda use your mental regex here, search and replace to whatever solution you're pushing. So the thing that we talk about here is that database scheme updates are a manual process. Fact, we have a 72-hour SLA for DBAs to take a ticket and persist that change to production, 72 hours. Our average time for a ticket is 71.4 hours. That weird? It's like right up to it, okay? And so what does that impact to the development team? So we've looked at some of the implementation that we've done and we have found that there is an improvement of 4.5% developer's time. Because we've done this implementation. You have done some kind of CD implementation and you've got metrics for this. You've asked developers, you've asked managers, you asked PMs about this, all right? So you got a metric here and this resulted in $29.9 million in hard cost savings. I'm gonna show you the spreadsheet towards the end, all right? So just hold on to this, all right, wow. This is costing us almost $30 million a year. Now you got my attention, all right? Now this is really good. And then we're realizing that the failure rejection rate here, all right? The failure of a ticket, hey, go and do this change, it failed. Or go and do this change, I don't like it, get it out of here. The DBAs say reject 50-50. I guess you're flipping a coin, you're not rolling the dice, all right? That's one out of six. And this results in delays and interrupts to the dev team's slowest development. So this is our current state. This is the tattle, teacher, teacher. They're doing bad things. That's what this is. Okay, let's paint a picture of what it could be. And so we're talking about safely enabling self-service or lower that time, that SLA time, 72 hours to 15 minutes, deliver critical application changes in minutes, not days. Okay, savings of over 10 million a year, we'll show that in the spreadsheet. And then we're gonna eliminate interrupt costs and speed development. All right, so first slide was, this is bad stuff happening. Second slide is painting a picture of the benefit. All right, cool, great. And let's show them how we did it. So we did a successful pilot with three divisions, effectively eliminated that 72-hour SLA. DBAs moved from tier one, no longer tier one support. Dev is doing it now. Okay, this is good, DBAs like that. We've got self-service for developers resulted in zero downtime. We have tried this and it worked. And then we increased overall number of deployments for my accelerate friends, yes, key metric. And then all other metrics. All right, great. Cost, when we did these three pilots was 10% of our savings. And we're also attaching ourselves to an initiative that's really hot at the company. So let's imagine that your company is trying, in this example, they've got a development platform initiative. Development platform initiative. Okay, really pushing hard on this. CTO is all about this stuff. Great, let's attach to this. All right, so these are three slides. Remember, and we'll show you the QR code at the end. But bad stuff is happening. This is what it could be. And this is us proving it happening. Bad ass, all right. Now let's talk about these numbers here. Now this is a spreadsheet that we made kind of fancy to look good on the slides. But the first thing here is we've got 4.5%. This number was from interviews and information that we got. So whatever you have implemented, you have done some level of improvement. You can go back and look at how often you're deploying. You can ask people. You can get this kind of metric here and say like, I am going to improve the lives of our developers by 4.5%. Great. Now we multiply that times the number of developers. We've got 3,500 here. And the number to the right is just 4.5% of 3,500. So that's why we get that 157 and a half. Okay, this is good. Now, we start putting this in terms of salary. So if you were trying to figure out the number of hours that you work a year, good rule of thumb is give yourself 50 weeks a year. All right, you got two weeks off. Actually get more, but we're gonna do 50 weeks. All right, just to make the math easier. You have earned more than two weeks. And we are gonna multiply 50 times 40. Anybody wanna throw out a number? 2,000, all right. So 2,000 times 3,500 is 7 million. Okay, 4.5% of that, 315. Then we attach a dollar number to that. So in this company, they have said like hourly rate for dev is 95 bucks. All right, this is a little dated. We multiply these two monster numbers together and that's where we get our 29 mil. Holy crap, that's a big number. Now, a lot of folks are gonna look at this and say, oh, I don't know, that's a lot. You can't guarantee you're gonna save $29 million. Okay, well, how do you feel about this? How confident are you? It's certainly somewhere between zero and 30 million. What do you think? And in this case, they said, okay, 35%. I think you can get 35. All right, we'll multiply 30 million times 35% and we come up with a little over 10. And everybody feels good about it. So this solution can save $10 million. So this is how you're gonna work it out. You have already implemented these small pilots through your company. You've already done this. You have these metrics. And so now you need to start building a very tiny spreadsheet to show the business value of what you did. Can't be quantitative or qualitative anymore. Has to be quantitative. So when you're presenting this business case, it is not about getting a straight yes or no. You're not checking homework here. You're starting a conversation. Hey, I put these metrics together. What do you think? So Dorothy's going through some crap. Bad things are happening. Who does she go to first? She goes to ride or die. She goes to Toto. You need to go to your CD, your colleagues, your CI colleagues, your ride or dies. Hey, what do you think? I'm trying to build a case here. You know that? Remember that awesome crap we did last quarter? All right, cool. All right, let's figure out what that impact was. And then we go to the application developers. They're like, hey, what did you think of that? How did that benefit you? What did that do for you? And they say, well, it made life easier. Well, how easier? Like 20% easier, 30%? Let's say 30%. Great, how did you come up with that number? So you're asking these questions. You're starting a conversation and you start building and building this coalition of the willing that you can go eventually up to those business executives and say, hey, look, you want 10 and a half million dollars? I got it right here. Really easy, we've proved it out. Now, here's the insidious thing about this, folks. I don't know about insidious, but this is really about you. This is about each and every one of you sitting in this room right now. Now, sure, you could go through this exercise to get budget and roll out this stuff, or you could also do it to justify and show what a badass you are. This might be something to do maybe right before annual review time where you get to say, hey, you know, remember when I went into the Batcave and I came out a couple of weeks later and awesome stuff followed me? Well, that's what it meant for the organization. This also helps for upcoming interviews that you might have. Yeah, well, what did you do at Company X? Well, let me tell you what I did at Company X. I helped save $10.5 million, and this is how I did it. So it's not just about getting budget. It's not just about, hey, we're trying to implement these things. It's also about you. It's also about making the case of telling the world, current employer, future employer, of all the awesome stuff you're doing. So don't just think about it like, hey, you know, I'm just doing this for the company to implement stuff. This is also about you. You could go back and back test this with other stuff that you've implemented. Okay, so how are we doing on time? I think we're doing great. I think I've landed this plane with like five minutes left in questions. All right, so again, there is our QR code. All right, so we're gonna have liquid beers. Tomorrow at six, if you're around, tell your Vancouver buddies. I think we're going to magnet, I think so. I don't know, somebody open it up, you tell me. I think that's what it says. Also, you could sign up and get a t-shirt shipped to you because guess what? I'm not taking them all on the plane and then leaving with them. All right, so we're gonna do one to one here. And then finally, to get the slides in that business case, let me know. Of course, you can email me, track me down, I'll hook you up. But folks, thank you so much. That's the end of my presentation. I'm gonna hang out, answer all the questions you have. If you have questions, I mean, I guess we've got five minutes left. I don't know if we have a microphone, but any questions, thoughts, feelings, possible cases that you have? Yes, in the back. Oh, turn, yeah. Turn that thing on, I wanna hear you. There we go. I've tried to make a business case like this, like these many hours of saving, developer costs saved, et cetera. The thing is a lot of things run in parallel, right? So they say, well, yeah, it takes 72 hours, but it's a request you can send in, it comes back. So there's a small team that is fulfilling that request, right? But there are consumers who are waiting on that request to be fulfilled, right? If you make the business case on the team that is servicing those requests, the number is very small. Yes. But if you make the business case around the people who are waiting for the request to finish, right? The number is large, but at the same time they do, they can do and it's expected for them to do something in parallel and not just wait for the database scheme updated, right? Yeah. What are your thoughts and pointers around that? Well, it's something I've heard before. Well, we can save, you know, all this time for DBAs. And you tell that to line of business, executive, they say so, that's their job. Yeah. So you need to look at it in terms of, well, what is that interrupt cost? So how many times is a ticket submitted? I hate saying that word. Such an anti-pattern, right? But a ticket is submitted, it is what it is. Ticket is submitted and it gets rejected. So maybe we can look at what is the rejection rate? All right. Well, if there's a rejection rate, that means it gets sent back. And I would, and these are folks that those scrum masters, they love solving these kind of problems. Like, hey, you don't appreciate it when stuff gets sent back. You know, it was supposedly closed in the sprint. Now we got to open it up. What is the reopen rate of our stories? Oh, okay. And what is that costing? How many stories do we have that we thought were closed? Just we took care of it, wrapped a bow in it, shipped it off and it comes back to us. What is the rate of that and what is the impact on the future sprints? And so going to the dev team and saying, what do you think? What can we do to decrease this reopen rate? I guess maybe we'll call it that. So you're gonna have to go and find metrics from other folks. And this is that coalition of the willing. I need to get away from the speakers so they don't have feedback. That coalition of the willing. Like, hey, I'm trying to do this. All right, help me put a metric on this. And does that sound reasonable? Does that kind of sort of answer your question? It's hard to get the metrics, but yes, it sounds reasonable if you can get the metrics from other teams to say, but yeah, it's the interrupt cost that is oftentimes not realized or it's very difficult to map it to how many dollars is the interrupt cost. Because you're not just servicing one service ticket oftentimes to deploy to cloud. Yes. Tens of requests that you have to put in. Well, look, that's a valid point. And thank you for bringing that up. Look, we're all software engineers here. That's what we do. It means we're engineers. It means we like to get a discreet answer. This is gonna get a little fuzzy. And you're gonna have like kind of a range. And remember I was talking about that spreadsheet. That is where you start having a conversation about these things and seeing where people are comfortable. It's gonna be hard. And you are gonna have to do some horse trading to a certain extent. Like what do you think it is? Well, it's not 40%, it's 35%. Great, fine, 35%. Multiply that by 30 million. But notice that I started on that spreadsheet with, well, this is what we're spending today. We hold these truths. Well, I'm in a different country. I'm not gonna do that. All right. But there are certain things that we're like, okay, this is absolute fact. We have this many developers. We're paying them this much. This is great. All right, cool. So now we have some percentages to play with. And we, great thing about the spreadsheet, it'll automatically update. Thank you. Yes. Why don't we discuss this at beers tomorrow at six or after this? Quickly though, humans, I love them. They're a lot of fun, but they are selfish creatures. So what do they want out of life? What do they want? And understand what is their motivation? What are they evaluated on? What is their boss hassling them about? What do they care about? What are their pains? And if you solve their problems, well, they're gonna help you solve yours with them. What's in it for me? And understanding that. Looking, this took me a long time to understand this. It took me a long time, decades to really get this down. And I still don't. I still don't. But at the end of the day, you in continuous delivery, you are in service to your developer friends. This is why you do this. You want to help them. And so I think approaching it with that perspective, I'm here to help you, help me help you. Come on, let's solve this problem together. I think you'll probably build those coalitions maybe a little bit faster, maybe. I don't know, yell at me on Twitter if it's not true. Go ahead. Any other questions, thoughts, feelings? All right, class dismissed. Thank you very much. Thank you. Thank you.