Eric Ledyard

[0:02] Well, hello, and welcome. This is the last day, right? Towards the end of the day? Very good. Sorry, I'm very jet-lagged. As you can tell, I'm not a Brit because I sound real nasally compared to all of you. So what we're going to do is basically walk through. We're going to give a presentation. I'm going to talk more about some of my experiences in DevOps and talk about how we're approaching DevOps. But for the love of God, I promise I will not make this a sales pitch, and I will not make this all marketing. So I want to be interactive, and the whole reason I'm here this week is to get more feedback from all of you as to, do the messages that we're talking about, do the challenges that we're talking about, do all of these problem statements, do they resonate with you? Are you seeing these same things? Have we missed the mark? So what I would ask from all of you is to come find me afterwards or flood any one of my social media pieces with feedback on, "This was good, but you're missing the mark here. This isn't real.

[0:51] We don't really do things this way." That sort of stuff is priceless to me, so please provide all that awesome feedback at the end. So what we're talking about today is this concept of fast, not furious, and it's very timely because ever since I read Gene's books, many, all of his books so far up until "The Unicorn Project", I didn't even realize he was going to call his next book "The Unicorn Project", but we have talked for the last three years about the difference between the unicorns and regulated organizations, and how you can't be a unicorn if you're a 200-year-old bank that still has extreme technical debt on the legacy side of things. So what we've always talked about is how do you bridge this? So we are looking at this in a number of ways that we're going to show you and just run some ideas by you. The first thing I have to show you is everything you guys are going to see today is all pre-GA. We are working on some products in this space, so you're going to see a sneak preview of a bunch of work that's being done by some really smart people like Colin O'Brien, who's in the room here.

[1:48] So these guys are building a product and also working on solutions across our entire platforms, integrating with all these vendors that are out here in the expo center to try and come up with really, really good use case problems to go attack and figure out how to solve and help all of you guys out as well as help ourselves out. So the fast, not furious slide. Oh, the safe harbor statement. Sorry. That means that everything you're about to see will probably change. 100%, it will change, or else we're not doing our job. We're not agile, for sure. So we do monthly releases of code drops right now, and we are in a pre-GA controlled go-to-market with some pilot customers that are part of a customer advocacy program and pilot feedback program. So again, if you guys have interest in wanting to do some of that stuff and I know some people are really geeked out when they get to help drive product direction, come find us afterwards, and we'll see if we can help you or get you into that program. But everything you're seeing will definitely probably change. We change it weekly. So we were just in a meeting last week where we made a big shift to say, "Hey, we're getting a lot of feedback from customers that we need to support this product, not that product." And so we literally had engineering go, "Okay, well then let's shift all of our sprints and go pick this up

[2:54] and figure out how we resource for this." And so that's what we're doing. So the safe harbor notice is, please don't make any decisions based on what you're about to see because it will in fact change by the time it releases. So fast, not furious. One of the people I was just talking to, the guy that's helping with all this stuff, he said, "So it's 'Fast and the Furious?'" I said, "No, no, no, it's 'Fast, not Furious.'" It's kind of like we get you excited, and then we slow you down. I said I should have done the theme song and edited it to go from the "Fast and the Furious" theme and then turn into classical music. But the reality is, what we're trying to do here, and the whole concept behind this, I didn't coin this. Richard Haas, he's actually out at our booth. He's really awesome and brilliant and my boss. So yes, I'm brown-nosing a little bit.

[3:34] No, he's super smart. He came up with this idea because he kept asking us, he's the marketing guy, right? So he was saying, "How do we make this message resonate?" And I said, "Look, it's they really want to go fast, but they cannot afford risk." So no matter how you want to word that, it's yeah, the unicorns, 186,000 production releases a day, and we're amazing, and we're doing all this crazy stuff, and the stories about the Google developers who, they own control of release and when it's ready for production, and there's no CABs or change. That all works if you're not regulated. But if you're regulated, you're never going to get past auditors. You're never going to get past change management, release management, everything else. So what we tried to say is, so is it infeasible? Is it infeasible for any of these regulated companies to actually get the benefits of DevOps? And the reality is, it's a resounding no. It's not infeasible.

[4:20] You just have to know what you're up against. And my favorite part, I just wrote it in a blog that's up on our communities place because I talk to it every day. Gene wrote in a book, and it was either Gene or Jez or one of the folks that was contributing. I don't know exactly who to attribute it to, since most of you are probably in the room somewhere or here at the conference. They literally said that one of the myths of DevOps is that it's not ITIL compatible, that DevOps kills ITIL, or DevOps isn't compatible with ITIL. And they said, "No, absolutely not." In regulated industries, more than ever, we need change control. We need the ability to do this. Or what I'm hearing this week that's kind of a new buzzword for me is change registration, which I think is really sweet because we don't even need approval per se, but we do need a record. We do need audit.

[5:02] We do need proof that this happened, and attestation that we did stuff. So no matter what it is that you're up against, there are regulations that we have to adhere to, especially in any kind of regulated company. So you have to be aware of the fact that you can't approach them like a unicorn. So why am I talking about this? Why is it me up on stage and not this brilliant guy over here who's much better looking than I? I actually had to go try and fight this battle. So I fell for it and actually got sold a bill of sale from a 200-year-old bank that said, "Leave your job at VMware that was awesome and come do platform as a service and lean and agile transformation at this bank." And I said, "You guys are never going to do that." And they said, "Yeah, we are." Seven interviews later, I bought in, and I was like, "Okay, I'll come do it." So I was a mid-level executive. Actually, one of my favorite people in the world, Chris Nowak's right here. He and I were both executives on the same team trying to do this for the same bank. And if you want to get a pint, we can tell you all sorts of amazingly hilarious and fun stories of our journeys.

[5:59] But the point was-I got to this bank and I was this techie guy coming from a Silicon Valley company, and I was ready to disrupt and change the world from within, and all these fancy buzzwords, and yeah, it was amazing. I had four big consulting companies with me. I had 40 architects with me. Yeah, it was just great. And then, roughly eight months in, we realized, "Oh my god, this is failing so hard." So I actually toured with Gene. I did nine cities with him at ServiceNow when he released the DevOps Handbook. And I wasn't telling the whole story. So I would tell like, "This is what we planned. This is the reference architecture. This is all the goodness we did." And then I would just shut up. And he's like, "Why aren't you telling-- Then what happened?" I was like, "Oh, I don't want to talk about that." And he goes, "Why?" I said, "Well, I'm at ServiceNow now, right? It's like 11 months later.

[6:47] Do the math." And he goes, "Well, what happened?" I was like, "I asked to be fired, bro. It was a huge failure." And he goes, "Okay, let's go to lunch." So first I text my wife and I'm like, "Oh my God, I get to go to lunch with Gene Kim. I'm such a nerd. This is great." I'm a huge fanboy of Gene Kim's and I always will be. I don't care. So I go to lunch with him and he's like, "Tell me the story. What happened?" And I was like, "We're going to be here till dinner if I tell you all of what happened." He's like, "No, let's hear it." So, okay, well, this is what happened and this is what failed, and this is how this went wrong. And it was all this problem and this, and we ran into culture and so I went through this whole story and he's like, "Dude, that's the presentation. Chuck the rest of those slides and that's the presentation." I was like, "You want me to stand in front of everybody and just say how bad I failed for the last 11 months of my career?" And he's like, "Yeah, that's where the good stuff is."

[7:36] I'm like, "Well, I'm glad I can help you, Gene." So I iterated for about the next six cities walking through and every time he'd be like, "Ooh, I really liked that story of failure and when you got pain and misery. Can you go deeper on that?" And I was like, "Sure, Gene." I was like, "I don't have PTSD or anything about it. Let me just pop another Advil and I'll tell the story." Anyway, so I have some history bleeding on these swords. That was the whole part of the story was that I have some credibility in this. And Chris and I, day after day, would be in our offices and we would be just like, "Why do they not get it? It's not that hard. We just need to change this policy so we can get this to go." And we had what we called the water balloon effect, where, I don't know, it's a toy over in the United States that you can get for your kids. It's like a rubber tube that's folded in on itself and it's filled with liquid.

[8:25] So when you try and hold onto it, you just keep squeezing and it keeps shooting out of your hand. And so we called it the water balloon effect because every time we fixed one problem, we would like squeeze it. Yeah, I got a handle on that problem. It would just go bloop and squeeze out of your hand, and you'd be like, okay, wait, now that problem. Bloop. And it was like, ah, that problem. Oh my God, how long is this? And it just was eternal. And then finally, the nail in the coffin was when the corporate antibodies had come out and attacked us, and everybody was seeing this was a virus that was infecting our system of 18 years of doing the old-fashioned business as usual. We all hit a roadblock where we finally hit our heads on the wall, where we said, "Okay, we got a system built. We have a path for .NET, we have a path for Java, we have a path for UrbanCode." Because Chris built this entire amazing UrbanCode system. He said, "So we have these three factory lines.

[9:08] We've got them all tooled up. We're ready to go. Now we just need to go. We can do nightly releases. We're just going to try nightly once a day, not 186,000 times a day, one time a day." It's like a horse. It's not anywhere close to a unicorn. It's not even a horse. It's more like a donkey. And so we literally paint this donkey up in zebra stripes, and we're like, "We're going to slap it out and send it out into the world." And the first thing they tell us all is, "No, you don't get to do nightly releases into production." We're like, "No, that was the whole purpose of this project was- ... we were going to increase flow. We were going to get stuff into our hands of our customers. We were going to compete against Wealthfront, that you guys told me they don't have a deploy cycle. They have a push button." All this stuff that they had sold me.

[9:47] And then they said, "No change management. We're still twice a year, every six months." I'm like, "So what do we do with the nightly builds?" And they're like, "Just queue them up and we'll just dump them every six months." I'm like, "I'm not sure you guys get how this works. It's supposed to be continual improvement, not like, 'Eh, let's just load a pile of crap on the truck and wait to drive it to the customers.'" I'm like, "Do you understand how this isn't working?" So anyway, I'm telling all of you this just to give you an idea that we've seen some really bad results with things that are planned poorly. And the fast not furious thing is we're trying now to kind of figure out, okay, well, based on all these horror stories that we hear from me and everybody else in this room that have experienced these kind of problems, how do we bridge this gap, right? And so how do we bridge the gap from being as agile and nimble or as fast as furious as these unicorns, but keeping ourselves regulated and governed and not introducing risk?

[10:40] Because ultimately, I talk about this as well sometimes, which is everybody asks me, they're like, "What was it like becoming an executive?" And I said, "Well, honestly, it's not much different than being an individual contributor. You just have a lot more risk." And they're like, "What?" I said, "The lens that you learn..." So everything in my career, I've had a really blessed career, and I've got to do a lot of stuff from turning wrenches to being in marketing now to just kind of weird career shifts that I've just kind of rolled with. And every time my perspective shifts a little bit, and then once it shifts, you can't unsee the thing. So when I saw this whole piece about being an executive, I always boil it down to I'm like, really, executives only care about three things. They don't care about tool chains at all. They don't care about whether you like Jira better than this, or whether you like Jenkins over this, or whether you like Ansible over that, or Kubernetes over what. They literally don't even remember those names.

[11:31] They write the check because you told them to write the check. They purchase the product because it goes through procurement, and then you guys are responsible for, and all of the people that are in the room, and my team was kind of half and half, for getting it implemented and getting it to work, right? And actually showing value. But the only thing the executives care about at that level is not getting stabbed in the back by other executives, which is doing something that allows anybody to introduce risk to say you caused something to crash or you caused something else, because they're all just waiting with their knives sharpened and ready and dripping with venom. Toxic venom. Anyway, the second thing is, can you save me money? Can I show a CapEx or OpEx reduction? A big deal. That's about as attractive... It's my least favorite thing. It's like saving money is, to me, the most boring conversation you can have, and the most non-agile DevOps thing in the world.

[12:17] We're all here to disrupt the world, leave a dent in the universe, and do all these amazing things. Saving you a couple hundred million when you're got a $5 billion budget, I know that sounds crazy, but it's really not even a drop in the bucket and no one cares. The third one is my favorite thing to do, which is driving top-line revenue. So how do you make your company relevant again? How do you make yourself competitively better than anybody else in the market? That was the type of executive I loved to be, and that was kind of my driving thing. There's a fourth one that I talk about, but not every executive buys into this one yet, but I think most of the people in the room do, and that's improving the life of your employees and making it a better place to work, making it a fun place to work. And that one most executives sadly overlook, but it's coming around. We are definitely moving the needle on this, because they're starting to realize that this transformation to product not project is really, a lot of that's being driven by the fact that for years we built projects with no mind of the customer, no voice of the customer, no user experience. Now we're flipping that.

[13:15] So anyway, the first things that we're looking at in this space, and the whole reason I told you that story about being an executive was the risk piece. So the risk is an unacceptable factor whenever you're trying to do DevOps. You can want to be as fast as you want, you can say we're going to do all these great things, but at the end of the day, and Chris and I can tell you, the second another executive can look at your executive leader and go, "Man, you're really sticking your neck out on this one. You better be careful," that's when life goes from first attempt in learning is what fail means, to you better not mess this up. And it goes to, you don't have to show any results year one because we figured out how to do it over three years, to you better show results year one and they better be big results. And the language just shifts immediately.

[13:57] And so that's what you got to get into, and it's all based on risk exposure, so you got to be careful about that. So anyway, that's the bridge. Hopefully I gave you enough background and context. So what have we found? So we went out there and said, we've talked to a lot of customers. I would talk to customers all day, every day if I could, just to hear what everybody's doing. And we've come up with really three unique challenges that people are having in DevOps today that we think are keeping people from achieving DevOps in regulated companies, really. And what do I mean by that? There's a person who I've blogged about, who I've copied his work, who I espouse continually. Austrian fellow, hilarious as hell for an Austrian, and has this YouTube video that literally is second to none, and I'm never going to top it so I literally always just link to it. But Klaus Leopold, and I don't know, for all I know Klaus could be here at this conference. Klaus Leopold did this presentation where he had been working with Barclays, and he had interviewed their team about what measurable impact is your DevOps initiatives having?

[14:54] And at the end of the day, they realized zero. But if you talk to anybody on the dev team, they will literally espouse for days and stand up at conferences and be like, "We are the most agile development team on the planet. We have totally, fully successfully transformed. We are amazing." And he started to dig into it and he's like, "Okay. Yeah, you guys are doing a really good job from the development side. Have you fixed release management, change management, ideation? Have you fixed this?" And he has this entire chart and it's like out of 17 stages of the full software development lifecycle, the only thing they modified was we can write code faster. And what's really interesting, well, he's Austrian. I don't know how he pulls this off. I would probably lose my job. But he literally had a slide that said, "Oh yeah, we're so effing agile. Yay!" Which is why I think he's brilliant and hilarious.

[15:40] So, anyway. But then when you start to dig into that, why? Why aren't these customers seeing an improvement? It's the same exact story that Chris and I faced. Yeah, you built a Ferrari, but you get to only drive that 20 miles an hour, ever. And it's like, because of regulations. We're putting a rev limiter on your system. And it's like, well, what are those regulations? And then we had Forrester and Gartner. I talked to a lot of analysts too, and they've said, yeah, the Forrester research says about 85% of our customers that have done DevOps have seen no increase in release frequency. And we go, what the hell is the problem? And they go, they can't get past their governance boards. They can't get past their regulations. They can't get past their release management. They can't get past all of the pieces that they didn't touch when all they focused in on was, and this is my biggest pet peeve in this industry, and I hope I'm not going to hurt anybody's feelings, but every time I walk into an organization, I say, "Let's talk about DevOps," they immediately start telling me, "Well, we have Jenkins and Maven and Git, and we have this." And it's, let's dive into my tool chain. And I'm like, "Okay, but what else have you fixed?

[16:37] What else are you addressing? What other processes are you fixing?" And they're like, "Uh, what do you mean? We're doing this. We're doing DevOps." And I'm like, "Okay, that's where we're starting." And that is, it's always been this tool discussion. But what we're starting to see now, 10 years into this industry trying to do this shift, is that you're not going to tool your way out of a bad process. And I don't know who to attribute that to, but I've heard it 50 different ways, but that is the reality. You can never apply any kind of software to a bad process and expect it to magically become Will Smith, genie in a bottle fixed. So that's what we're looking at. So what do we start to see is really there's three key areas that people are having problems with. The first one is change management. By and large, it is the nemesis of DevOps, right? So if you talk to any developer and you say all the dirty words that ServiceNow represents, CMDB, CIs, ITSM, ITOM, ITIL. If you talk about any of that stuff, most developers will literally throw you out of their office or throw a brick at you or something. And it's no fun, right? Because they hate it.

[17:39] And quite frankly, as an executive of a development team, I hated it. I am paying developers an insane amount of money. Some of these developers we were picking up out of Stanford and MIT, I couldn't believe how much money we were paying them. And then instead of having them write code, we're having them sit in a CAB meeting four hours long, where they're trying to explain that they're updating a UI element, and they get to go 17th on the list, then we might get to them this CAB meeting, or they may have to do the next CAB meeting. Then you've got a grumpy person in the CAB meeting saying, "You didn't fill out the form correctly." And now I've got a developer spending 25 days trying to get a change approved for a UI element that should've been a no-brainer. And it's like this is a horrific waste of time, effort, talent, and everything else.

[18:20] And by the way, the developer might quit because they're so sick of these processes. And believe it or not, we had a 40% attrition rate at the place where I worked, which I won't name publicly because we're on YouTube. But I do have a LinkedIn account. So, at any rate, we had a 40% attrition rate of new-hire developers that we were hiring out of Stanford, MIT. We were trying to track. We had all these, oh God, I love these words, the incubator programs. And it was a little ASMR there for you guys later. But the incubator programs were all these ideas of getting the best, most talented developers on the planet, and then putting them into this environment and going, "It's going to be eight to 10 weeks before you can write your first line of code." And they go, "Huh?" They're like, "Well, we've got to get you a laptop." "What? I don't already have a laptop?" "And then we've got to get you rights to the environment. Then we've got to get you through security risk audit.

[19:11] And then once we get you through security risk audit, we'll get you through..." 10 weeks later, these kids that are coming out of college, and I call them kids because I've got gray in my beard now, they're wearing flip-flops, good old Birkenstocks with their Beats headphones on and their T-shirt, sitting at their desk going, "I haven't written a line of code yet. I'm not disrupting the world. I'm not leaving a dent in the universe sitting here in my cube." And they would be like, "I'm bouncing. I'm going to some startup. I'm leaving. All my friends are writing cool code, and I'm sitting here doing nothing." And so that was literally 40% of the new hires, and that's insane. And literally, the answer was, "You guys have never heard of a virtual desktop?" I mean, Jesus, how hard is this? Like, an onboarding process, anything? Anyway, so I digress. But one of the biggest challenges was change, and it really, really is not the friend of development teams or really ops even.

[20:00] So why is that? So change managers tend to get a really bad rap, and it's kind of a bummer because it's not really their fault, right? Their job is to make sure we don't introduce undue risk into the organization, and they're trying to be good Samaritans, trying to keep the developers, save them from themselves, be the parachute in their backpack, so to speak. I've also heard my favorite one is, "Get as many fingerprints on the gun as possible before you pull the trigger." That's my favorite. So that's what the change managers are trying to do. That's their entire job. So they're not bad people. As a matter of fact, I just worked with a woman out of Miami, and she's like, "I love salsa dancing. I just wish I could go to salsa class one week, and I'm not sitting here." And I said, "Well, why can't you get out of here?" And she goes, "There's 400 of them.

[20:46] There's four of us." And I'm like, "What?" And she goes, "There's only four people on my team, and there's 400 people in dev and ops that are submitting changes. We cannot hit everyone." And I go, "Well, so how many of those do you think you could automate?" And she goes, "Oh my God, I could automate, like, 70% to 80% of them." And she goes, "Oh, and that's not even counting the ones that they subvert the entire process on." I'm like, "Wait, what? There's a subversion process?" She goes, "Yeah, they call it standard change or emergency change, but effectively, that just means they don't have time to wait for us, so they just go." And I'm like, "Oh, cool. Do they document anything?" And she's like, "Well, they sort of do. They submit this form. They're supposed to fill everything out, but we don't even have time to check." And I'm like, "Oh, my dear Lord.

[21:25] How does that make you feel?" She goes, "I can't sleep." And I'm like, "All right." So the first problem was, again, understanding this. Change management people aren't bad people, and they're usually way understaffed, and they're trying to keep up with this massive speed that's now in the dev teams. And then the other problem was when something breaks, how do we audit it? And again, we're taking these expensive developers and spending weeks trying to gather the data and the forensics of what happened. Why? Why would anybody spend that much time to gather data that you should've just captured during the process? So that's kind of our theory on the two things. So what we're trying to do is take things from 23 days on average, that's our average right now. I always have customers say, "Jeez, mine's like two months." And then I have other customers saying, "Yeah, we already fixed this.

[22:05] It's like two days." And I'm like, "Okay, cool." But on average, what we've seen is around 23 days. And then the three FTE weeks equivalency was for some of the customers we have in the program already, and we're taking that down to literally what we call push-button audit. And this is just the way we're approaching this problem. Again, I'm not trying to push product on you. I'm trying to just tell you some of the problems we're thinking about and how we're looking at solving them. So how are we doing this change thing? So we're automating it. So we're basically capturing data from all the tool chain, and we're basically writing an API. Well, we've already got the API. We write the interconnections into Jenkins and Git and everything else. We grab all the committer information from Jenkins. We grab all of the information coming from our build pipeline, which is Jenkins.

[22:43] We grab all the automated test results, which we tied in through Jenkins. We bring all of that into our system, and then we have a condition rule set, business rule set, where you can say, "Here's an input, here's a decision tree, here's an answer. Can I auto-approve this?" And so what we're effectively trying to do is evaluate risk, do a bunch of really cool stuff. We're even talking about machine learning and AI in this in some point. We talk about stuff like developer karma, developer FICO score, so that a guy like me that writes bad code all the time, that's why I don't write code anymore, would have a developer score of seven out of 100. And then someone like Chris would have a developer score of 99 out of 100. Well, Chris would get special permission to actually produce code that he could push right into production. Whereas me, I'd have to be babysat three or four times and probably get turned away a lot of times.

[23:30] So anyway, the point is, we're talking about all these cool concepts of how can you automate a change through the process using a machine to make the decisions rather than sitting in a CAB meeting that's a waste of time for everybody. The second one with the audit chain is just tying all the data together and making a report. So how we took our approach to this was, we didn't want to make developers or any teams lose the tools that they're already good at. So Look, I hate these conversations. And listen, I had these conversations for years. I was in infrastructure. So I started writing code, sucked at it, went to the infrastructure side, found out I was actually okay at infrastructure. I didn't break stuff too often. And so I stayed there for about 14 years of my life until I got into leadership, where I'm truly useless and found my niche.

[24:11] So once I got there, it was like this idea of, I'd have a whole bunch of people from software companies come to me and try and sell me their stuff and be like, "Ours is better than theirs. We've got these features and they don't have these features." And I'm like, "Cool, cool." And then they'd come in when I was an agile leader, and they'd be like, "Okay, so we can provide you all this greatness, but you just have to gut your entire tool chain and do it with this tool chain." And I was like, "Cool. So how long is my development team going to not be writing code while they go learn how to use your platform?" And they're like, "Oh, ah." And I'm like, "But the whole point of agile is to increase flow through the system, and you're telling me, step one, retrain your entire staff. Hmm. That hurts. All right. Well, maybe. You better have some really cool features you're providing for me to take that kind of a hit to my productivity." So anyway, I was really happy, and the whole reason I took this job at ServiceNow was because I said, "How are you guys approaching this?

[25:03] Because if you're being a me-too product, I'm out. I'm not even going to play this game." And they said, "No, we're going to leave everybody where they're at. You don't have to change your tools. We're going to create this open data model where we bring in data from everybody else's tools as an integration and workflow platform, and then we can execute all the cool things that we've done around service management, ITSM, ITOM, HR Service Management, all that stuff. We're going to be able to apply that across the tool chain for development." And so that's really what they're doing. I say they because I didn't build this so it'll work. The really smart guys like him built a lot of this, so it's awesome. But that's the approach that was taken. And so I'm really stoked about the vision, and the approach to it. So the whole concept is to stay above the tool chain, provide a whole bunch of really cool features, and tie together the entire life cycle from ideation all the way to production, and then continual feedback into the loop. And that's the approach we're taking.

[25:53] And again, I'm not here to sell you guys software. I just want to tell you the approach we're taking, because I want to hear if it resonates with you, if this is cool. So the best way for me to see if this resonates with you, and I only have a few minutes left, is to show you this stuff. So let me run through it very quickly. And if you guys want to go deeper, we'll be at the booth, and you can come by and I'll run you a live demo if you want. But the idea is that change isn't that hard to do. Change authorization, we make tons of jokes about this, and most of them I can't even repeat in here because I could get an HR incident. But the point is, the best story that Gene ever told when I watched him present-- Well, not the best, he has awesome stories all the way throughout. But a really good story that I use every day is, he tells a story about a woman that started at Google.

[26:32] Brilliant woman, starts writing her first app. She gets her app ready to go be produced and goes up to the leader and says, "Okay, where do I go for the CAB process and to make sure that I get change?" And they go, "You're at Google." And she goes, "Yeah?" And she goes, "Okay. You wrote the code. Is it ready for production or not?" And she's like, "Wait, what?" And they're like, "You wrote the code. Am I going to go have you spend four hours trying to tell somebody that has no idea what you did to see if it's okay to push that into production?" And she's like, "But that's how everybody does it." And they're like, "That's not how Google does it." But Google's a unicorn, so they've literally shifted it entirely left, so that the entire responsibility lies in the hands of the developers themselves. Most regulated companies literally cannot do that.

[27:18] They just can't. There's a separation of duties. The person that wrote the code can't even do the change control, can't even approve the change, can't even push the stuff. You got to have separation of duties. But there's no reason why we can't capture that data in real time of what's in that change and make some decisions on it using a computer that's never going to be wrong. It's always going to run the same rule set. It's not going to be sad because its puppy passed away or that somebody yelled at him on the train or whatever. It's going to make the same decisions all the time based on very set rules, which, by the way, auditors like. They love consistency. So that's the idea. So quickly going through this, what we did was we built a system-- Again, I say we. I had nothing to do with this. I just get to say we because I have the same logo on the paycheck. So anyway, the smart people built this amazing system that has inputs, and we have inputs.

[28:01] We created three of our custom ones for this. It's anytime there's a change request, anytime there's a a stage execution. So we have pipeline stages in our application. So we have table space that keeps track of where in the pipeline things are. And there are app stage pipeline because the only app stage might not be just in Jenkins. There could be some other things that we're doing as far as the app stage goes for CI/CD that's outside of just your build tool. So that's why we created another construct called an app stage. So there's build stage coming from Jenkins, which we call a pipeline execution stage, which is the one underneath that. And then there's the actual pipeline stage in our app, which is saying that's the pipeline execution plus our own execution equals the stage execution. But what we're allowing to do is, that's allowing us to see all the data during those points, and those can be triggers for any kind of decision tree.

[28:48] So if I see a trigger coming in as a change request that was automatically created, in this case, I have a four-stage Jenkins pipeline build that does CI, UAT deploy, UAT test, and prod deploy. Super simple. And it's a web Java app. It's just going to a Tomcat server that runs literally on my Jenkins server. And we literally just walk through this staged approach. We create a change request for two stages. I don't need one for CI, I need one for UAT deploy, and I need one for prod deploy. I don't need one for the testing either. So what we do is we have a change decision tree for prod deploy and UAT deploy. It basically says, anytime I see a change request or one of these execution stages come through that's going to trigger this incident kickoff or this decision tree, I'm going to run these policies against it. And if I see these conditions being met, and what does a condition look like?

[29:35] It looks like this. So what I'll say is stage execution.calculated risk is low. How do we calculate risk? It's kind of cool, kind of fancy. It's going to get better over time. We're talking about using AI for this. It's pretty neat. Stage is UAT.Test cases passes percent is greater than 90%. We've actually changed that to 100 in some cases. And then this was for a healthcare organization. I put category is not HIPAA. So if it's a HIPAA one, it goes through a different rule set because we have different rules. Over here, you guys have GDPR, or GDPR, sorry. I always call it GDPR. You have GDPR, which is the bane of everyone's existence, I hear. No, it's there for good reason, but totally different rules. So you could put rules in here about GDPR if you wanted to. And then finally, what ends up happening is you can see that the change gets created automatically and everything flows through.

[30:20] I'm running really quickly because I got about 30 seconds left. But the end-to-end demo that we show is that the cool part about this is the developer never has to touch anything. They write code, they submit code, they tie a story ID to that code that they're working on. They burn down their backlog. By them copying... I always want to walk and point to something, which it's going to be hard to do here. But by them copying the story ID colon into the commit header information here, or sorry, just commit message. I called it a header and everybody said, "You don't call it that." The commit message in GitHub, for example, if I copy my story ID and I hit commit, that's the end of the developer's change management process. They never have to go fill out a form. They never have to worry about anything. We took all that crap and moved it behind the scenes.

[31:02] So most developers I've talked to about this love that. They're like, "You're taking change management completely off?" I'm like, "Yes, we are." And they're like, "Well, how do you do that?" And I'm like, "Well, what we're doing is we effectively tie that commit record, we build a work item, we tie your commit information to the job from the story ID from Jira or from Agile or from whatever other planning tool, Azure Pipelines, whatever you got for planning. And we then tie all the commit information back to that story, that epic, that art, that whatever you're doing from Safe or however you guys do your planning. And then we basically tie this entire workflow together from commits, to job builds, to changes, to incidents, to problems, to events, whatever." So it's the idea of making these relationships between all the data in the pipeline and being able to report on that, create insights on that, make decision trees on that, et cetera.

[31:46] So that's the thing, and I'm running out of a lot of time here, so come by the booth and I can walk you through the demo and stuff. But the idea is that we automate the workflow through the build tools and through all the systems. We automate the change process. We automate the audit trail, so you can see exactly what happened, when, and by whom. And then the biggest, coolest part about this is what we can do with all the data, which is provide tons and tons of insights and analytics around it, where we can do reporting and make basically data-driven decisions about your CI/CD pipeline, your developers, your commit information, your ideation practices, everything. So with that, there's a lot more slides to show, but again, I didn't want to kill you with product or with any of that stuff. Hopefully, what I've said has resonated with you. Please, again, the most valuable reason that I'm here in London with no sleep and tons of jet lag is that I want to hear from you guys.

[32:34] So please inundate me with feedback. Does this resonate? Is this cool stuff? What else would you guys want to be looking for? What would you want to see in products? We ship this fall, so you guys could help inform all this. And with that, I will shut up and let you guys get on with your day. So thank you.