 And since I'm last, I'm also going to say, how about I ran a round of applause for the organizers? Because this is a lot of work. And they're all volunteers. OK, so my talk today is actually the culmination of several years of working in continuous delivery space and DevOps space. And frustration over, oh, I'm just going to buy this tool. And then I can do the DevOps. And as a tool vendor, that does not work. So what I'm trying to do is show you some ways that there's statistics that'll help you drive and do these changes inside your organization, but also talk about some strategies for socializing the change and actually getting people to do the things that need to be done and convince them that it's the right thing to do. So background, I am a technology evangelist for ThoughtWorks. I'll go into a little bit more about what that means. But in about 25 years, I've held pretty much every position in a software company. So tend to come at it from a little bit different angle than other folks. So for this talk, I'm going to do some stats and stories, because there is information that'll help drive change inside the organizations, but then some misconceptions, excuse me, about using that information, but then some patterns that might help, again, having to do this in several organizations over the years. So the first challenge, you're going into your organization. You want to do the DevOps, and you have people pushing back. The issue is that they've really heard all of these stories before. There's different methodologies, different techniques, different architectures. Everything's going to make you better. If I buy these three products from those three vendors, they're each going to save me 30%, and now I just get to go sit on the beach. And it doesn't work. So one of the things they did is I went on Wikipedia and looked up software methodologies. So this is a partial list of methodologies that are on the Wikipedia page that'll make you better. So it's pretty hard to parse that. So when you're, again, trying to drive the change, these people have all heard this before. The big one that I latch onto a lot, because it was my life. I used to be an agile coach 10 or so years ago, was the agile thing. So we all know that agile makes the pain go away, right? But one of the reasons continuous delivery exists is that agile was really good about getting working software in front of a product manager or a customer advocate or something like that, but not necessarily the customer. And so for a lot of people, this didn't deliver. Now, part of the reason it didn't deliver is they didn't actually change behaviors. So I think Andrew had said something during his opening keynote yesterday about you can have all the things, but you have to actually change the way you work. If you just stand up instead of sit down during the meetings, that doesn't make you agile. So yeah. Now, I believe, and there's a lot of people here that know me, I do a lot of DevOps days and so forth, and I'm kind of a cynic. I believe there are two reasons that people do things. They're either trying to make something better, I'm gonna make more money, I'm gonna buy a boat, I'm gonna whatever, or to avoid pain. Now there's, you know, little in between, but this is kind of the deal. So what I'm gonna do is I'm gonna go through some of these that might help you inside your organization. So you wouldn't be here if you didn't think that DevOps to delivery was a reasonably good idea. Not everybody in your organization agrees. So first off the carrot, what can it make better? And you'll know a lot of this, but just wanna reinforce. If you haven't read the state of DevOps report, please do, anytime in the next six or eight hours is fine. This started out as a marketing thing, okay? It absolutely did, Puppet was the original one, we were sponsors of it. It was, hey, look at how cool DevOps is. But what's kind of cool is that some people went off and made this all science-y. So Jezz Humble, who was one of the authors of the continuous delivery book, and Gene Kammer wrote the Phoenix Project, among other things. Nicole Forsgren, who's at Chef, who has a PhD in analytics. They now do this, and they're really applying a lot of science. As a matter of fact, there's a reference here later, but search for a video called Science in the Crap out of DevOps. They've made sure that the surveys are valid questions, that they've had it peer reviewed and published in a scientific journal. So this is good ammo for inside your organizations. In there, they talk about a bunch of things that are just gonna be better if you do the DevOps. For high performers, and they define high performers using a metric of deploys per day. Not sure I love that, to be honest with you. Certain software shouldn't be deployed many times a day. But at any rate, what they found is when things go wrong, not if, when. These people had a 24-time faster recovery from errors, failures, three times lower change failure rate. I mean, these are all the metrics that you've probably heard all day long. I'm gonna go through it fairly quickly, but this is the kind of thing that is gonna matter inside your organization. It's kind of funny, because Mary posted a thing there. Everyone's hiring. Sorry, Mary, I called you out, I did it. If you're trying to hire people, people in these organizations, 2.2 times more likely to recommend the organization to a friend, to some place to work. So these things are actually really good for retention. And then I did mention that they science the crap out of it. So I think we're gonna do slides later somewhere, but if anyone wants to take a picture, oops, sorry. So we believe in mean time between recover, right? Not mean time between failure. So I don't know if you guys saw us like scrambling up here. My laptop wouldn't work on the projector. So this is Jason's. Anyway, that's SSRN, that's where the paper is, so you can go get it. The state of DevOps report, you can go and it's all glossy and marketing and so forth. This is the science. They have all the formulas in there, all the math, the methodology, everything else. So for the data driven people, it's really pretty nice. So this is one of many sources for the carrot. Next we have the stick. So a bunch of us that are into DevOps, Canuse Delivery, and Lean are real big fans of Deming. This is a quote that's often attributed to Deming, which it doesn't appear he actually ever said. But it is true. Survival's not mandatory. You don't have to do this stuff. You don't have to stay in business, okay? But your competitor's gonna. You will have security issues, period. Okay, so we remember Heartbleed. When this came out, this was a SSL issue. I think if I remember right, average, maybe someone will correct me if I'm wrong. I believe that of the websites they surveyed, average recovery was something like 10 days until they were updated and so forth. But there were a lot of sites that were fixed in 30 minutes because they had solid continuous delivery pipelines and they could make a change to a Chef Recipe, a Puppet Manifest, whatever, run it through their entire process and still get out to production very, very quickly. I am often quoted as saying it's not continuous delivery if you can't deploy right now. And that's, security's a big reason for that. Also Symantec, who I'm sure everyone's familiar with, it done a survey here. These are the number of zero-day vulnerabilities by year and I can't read my own notes but I think that's 13, 14, and 15. So it's getting worse. So you need to be able to recover. One of the most overused stories, I don't have upstairs but I'm gonna do it anyway. Anybody know the night capital story? Okay, so actually a lot don't. That's good for me. 2012 Night Capital was a trading firm. Now they still are. It's a trading firm that did not a lot of trades but they were big trades. And they had a manual process and they deployed the software to seven servers. Now they were using a thing I like, a technique I like a lot called feature toggles. But they weren't cleaning up after themselves and they had an old one and it wasn't automated. And the problem was that they actually have eight servers and they deployed the new software to seven of them. So it started trading software or trading stock what was supposed to be a program that checked to see if they had major change but didn't actually do a trade. So it was a notification. So this value of this stock changed by this much. Instead they actually traded the stock. So the next day a bunch of investors got together, put together $400 million and took over the company. The people at Night Capital were gone in 45 minutes because it just blew up and that's bad. Also I mentioned a minute ago, things will break. It's not a if, it's a when. Famous one from a few weeks ago. I was talking to some people at the party last night who got paged for this as they were boarding a plane for vacation. Couple weeks ago, some poor soul at Amazon typed a command and brought down a whole lot of servers. For two hours, they couldn't actually update the status page. Did anybody know why? The red icon was served out of S3. So S3 was down. So if you went to the dashboard it was still green because they couldn't serve the red icon. Little bit more than four and a half hours later they were back up. Now I live in Seattle. I know a lot of people at Amazon and I have to say Amazon is incredibly good at this stuff. They are really, really good. And it still took them four and a half hours. What's funny though, not funny. That's the wrong word. This is according to a business insider how much revenue was lost for other companies during that outage. S&P company is 150 million, financial service is 160 million, Amazon zero. Because they had the process. Apple, Walmart, Newegg, Bestbay, Costco, Amazon, Zappos, whatever. They just switched data centers. No big deal. Because they had the processes to do that. So those are the neat little metrics and you can print out the white paper and you can give it to your CFO. So I like to say you're now armed with facts. That's obviously the very, very short version. And this is what I believe those facts will get you. Absolutely nothing. They're important to have. You're going to need them, but people don't do radical change because you showed them a metric that says you're gonna get 6% better. And so you have to be able to drive the change in a way that makes sense to the people you're talking to. So highly opinionated, but I'm gonna go through some things that I think are wrong. Oh, okay, wait a minute, Mary. There you go. Gotta play to the audience, right? Anyway, so things that are wrong. Those of us that have been in technology for a while, those of us that have a heartbeat know that there's a lot of products that come out that maybe weren't the best idea. Okay, so ideas actually aren't judged 100% on merit. If they were, beta would have beat VHS, old guy. Okay, so there's a lot more to it. There has to be a good idea, but there also has to be the implementation, which is a corollary, if you will, is that you can't just introduce it. So you can't do a session inside your organization and say, hey, here's the DevOps and get people to go, hey, I'm gonna go do that. I'm gonna sign up for DevOps days. I'm gonna watch these recordings. They're not gonna do it. There's work, it has to be done. It's an ongoing process. The other one that's my favorite is top-down change. So I was at an organization many years ago, obviously pretty easy to find out online who it was, but we got acquired. And one of the reasons we were acquired is because we had some really good agile processes. We were very lucky, the development managers at the time were real students of the craft, students of learning, and they did a really good job. So we had all the agile-y things, all the good things. So we were acquired by our competitor, and one of the things that we were asked to do was bring those folks on to these new processes. At the same time, we were end-of-lifing their product and going forward with ours. Now imagine you're an engineer at an organization, or a person at an organization, you've been working on a product for three months or six years, you beat your biggest competitor, you win, you acquire them, and then the announcement comes out that, and by the way, we're killing the thing you built and using theirs instead, because it's better. They just weren't good at implementing it. So we went around and we taught people what a user story was, and we taught people about estimation, and we taught people some things that are probably now wrong. And we got 100% compliance. Everybody now did user stories. One of the groups literally took their Word document, their waterfall thing, separated it on paragraph markers and numbered them and called them user stories. Okay, so we got compliance. We did not get commitment. We certainly didn't get any buy-in, and it failed miserably. Okay, they've since rebooted and they're in a good place. But you cannot say, okay, CEO, CIO, CFO, CTO said, we're gonna do the DevOps. It does not work. You have to have change. I didn't have a reference up here, but if you wanna search for something, Polycomtois from Hearst Media does a great talk about what he calls middle leaders and where the change comes from. Okay, so some patterns for gaining acceptance. As an engineer, I'm a real fan of patterns, things that are repeatable, things that I can say to somebody, I'm gonna go do a thing, and they know what that thing is. That said, this is blatant theft. So, Linda Rising and Marilyn Mans have written a few books. Fearless Change is what most of the next several slides are gonna come out of. Not verbatim, verbatim, whatever the word is. So first off, you actually, if you wanna drive change, have to become an evangelist. So I said my title is Technology Evangelist. I'll be honest, when I got it, I was like, I'm not sure I like that title. But the truth is, this is what it is. It's going around to teams inside your organization, going around to people inside your organization, and getting a critical mass of support. Because you cannot do this stuff without a culture change. You can't buy a tool. It will not work. Okay, so you have to go through, and it's an ongoing process. You're also never done. Now when you're doing this, it's incredibly important that you tailor the message. So if I'm talking to the person who's judged on uptime, please don't ever do that. But if I am, then I'm talking about the ability to recover, and mean time to recovery, and how fast can they get faster than failures. Things like that. But I'm actually not using that language. I don't know if anyone's been in sales before, but when somebody joins retail sales, the first thing they get is this thing called feature advantage and benefit. Okay, I don't care that you can deploy 200 times a day. I care that you can deploy 200 times a day so that you can react quickly and protect the company from financial loss. Okay, so when you're communicating these things, communicate the benefit, not the feature. I'm a big fan of personal anecdotes, and it's National Pet Day, who knows what I know about. So another story, we were looking for a car very recently, and went into the Mazda dealer. I was waiting for my girlfriend to arrive, and I'm looking at the new Miata. It's very, very, very cool. And the guy comes over and he starts naming off all of the features that he thinks I should care about, because he cares about them. As it turned out, I didn't care very much, because I'm never, ever going to be able to drive a Miata. His brother's about 10 pounds less than him, and they need to fit in our car. So we were looking at SUVs, but he assumed, hey, this is really cool, they got the new hardtop, they got the new whatever, I was looking at it because it's cool. Okay, but I didn't care about it. So we bought a Toyota RAV4, okay, because we just didn't hook up. It's the same kind of thing. So some ways that you can do this, everyone's familiar with the old Lunch and Learn, okay? Lunch and Learn is a great tool for communicating these things, because people have, like everybody here, you have a day job. Be a little bit creative, you know? I mean, I like pizza, I could live off pizza, but most people can't. So bring different things, take up for different dietary concerns, you know, et cetera. And do this, do some upfront planning. Know what you're going to talk about, have a plan, this is my goal, you know, et cetera. It's nice to have an informal thing, but you're not, nothing's going to get done. Make it interactive. So this type of thing is nice, it's a good way to share things with hundreds of people, but it's not nearly as valuable in my opinion, I'm actually going to hit this twice, as things like the open spaces later that are interactive. People are going to learn more if they're on a keyboard or whatever. Have tangible takeaways. When you leave this Lunch and Learn, you're going to know this. You're going to know how to do that, make people want to come and promote it. So I work for a company with 34 offices, I did a Lunch and Learn at our New York office, I put it on the calendar and I did nothing. And I went to New York and I went to the office and I got an hour to myself. You have to promote it, you have to sell it. You have to say, hey, come to my Lunch and Learn, this is what we're going to do, this is what we're going to learn. You know, I went to DevOps days, I learned this great stuff, here's what I'm going to share with you, et cetera. You got to promote this or people aren't going to show up. Another thing I like to do is, and this is, I just stole out of the book, but leave hints around. So there's a bunch of stickers over there, there's white papers, you know, make your own, print out web things, whatever, just leave them around. By the coffee pot, put a stack of DevOps, state of DevOps reports. So people can take it to their own time and get curious, just build that curiosity. It actually really does work. So I didn't hit the buttons, but yeah. And don't be, you got to get Lunch and Learn? Post flyers. Now the other challenge that people have, I mentioned this a little bit, is you have a day job, right? I mean, everybody has a day job? Or wants to? If it's just depending on the size of your organization, it actually makes sense to lobby, to become a dedicated champion for the cause. So to be the person whose job is to help spread the ideas and teach people, you know, et cetera. Because now you're going to get measured on it. If I'm measured on something else, then that's the thing that's going to take priority over this thing, right? So you can make it your full-time job. There's some risk involved, okay? But if you really want it, but it allows you to focus. It allows you to say, this is the thing that I'm working on. That said, also find innovators to help. So everybody has that friend that is the person who has to get the new thing as soon as it comes out. I mean, that's me. I had the first iPhone. I paid whatever ridiculous price it was. Do you have these people in your organization? Find them. You probably don't know who they are. Try to get them excited and then they'll get excited and they tell two friends and they tell two friends, et cetera. It's really good for early help. That said, don't build a strategy about it because these are shiny object people. So again, you need to hold the attention and that's hard to do. Also some other places to ask for help. So don't hesitate to ask for introductions to other teams. Not only just to say, here's who I am and get in there, but also because others have trusted relationships that you may not have. So if you're in a traditional siloed organization and you're in ops and you want to convince Dev, it might be that you need to find somebody senior in that department to introduce you to help you do those things, to move it along. So take advantage of those relationships where you can identify them. Please say thank you. Yeah, okay, I asked for that. I admit it. Yeah, it's really funny. There's been study after study after study that is sincere, thank you. I appreciate you did that because it helped me do this. So spell it out is actually more effective than the $20 Starbucks card. I mean, it just is. Do this. And also celebrate your little successes. So if anyone here's ever done any kind of, trying to push an organizational change, you know that it can be very hard. There will be lots of challenges. There'll be people that don't care. There'll be people that were burned by rad or rub or scrum or lean or whatever. So there will be these challenges. So internally, acknowledge your successes. One of the things that I often speak about is burnout in the technology industry. There's others here that do as well. And not acknowledging when something goes right is a really good way to laying yourself down that road. These are hard, do this. That said, I'm not a big fan of participation trophies. Okay, so be honest with yourself and seek feedback. If you do the lunch and learn, if you do the presentation, if you do the thing, don't be like, woo, 20 people showed up. And meanwhile, those 20 people are like, God, that sucked. Okay, if this sucks, please tell me afterwards because I don't wanna submit it again. Okay, if only the people that come up and say, hey, that was great, then I'm gonna submit it again. And then 400 other people are gonna have a sucky talk. Okay, so please be honest. Sometimes you just kinda gotta do something. So we also wanna talk about actions. Little bit different to me than a lunch and learn is something that we call a study group. We use this quite a bit. So there's no money, even pizza. Sorry, I'm not buying the pizza and the organization won't. But there's probably other people inside your organization or in your community, meetups, et cetera, that are also interested in these kinds of things. We have in most of our offices every Friday, some thing. And then once a month, it's a four hour thing. But it's just skill building, et cetera. Take some organizational support if it's not off hours, but you can do this. So colleagues in what have you consider inviting outsiders. I live in Seattle, but you guys are really lucky at those that live locally. You have a really great, and I'm not pandering, you have a really great technology community here. You can get up in front of your colleagues and talk about the things, but somebody else getting in front of your colleagues and talking about the things is actually more powerful. Maybe it shouldn't be, but it is. So don't hesitate to invite outsiders and offer back and forth. Hey, I'll come speak to your company, you come speak to mine. Those are really nice. Internal events. So I'm a huge fan of the DevOps A structure because I like to get some of the presentation and some of the open spaces, et cetera. You can do these internally. A larger organization, if you have 12 people, it's probably not gonna be super productive. But you can hold internal events where you're free to talk about your challenges. By the way, we all have the same challenges, so when you're in open spaces later, just admit it because somebody might have overcome them. So don't think that, oh God, I'm the only one that does that. So I submit talks, I think presentations are good. There is no replacement for interactive sessions. I help organize the Seattle DevOps Days and when I do the introductions, one of the things I say is, if you leave this conference, and this is true for here too, and you didn't learn the thing you came to learn, it's your fault. Because after me is Ignites and after that is you getting up and saying, I need to learn about this. Incredibly powerful. Someone here has tried it, they've succeeded, they've failed, you can learn from them. Also, don't hesitate if you do know how to do the things to mentor people that don't. I was talking with one of the organizers earlier about doing these kinds of talks and doing them at non-DevOps, non-continuous delivery things, and how it's beginner. We're talking about the same thing for years. But it's new to the people in the audience, it's new to them. They don't know how to start. So don't hesitate to mentor and step back a little bit and do that. A lot of times just having someone around that's done this before will really help the team. I have to do this at least once per talk, I gotta piss off some of the people in the audience. This is the only valid use of the term DevOps team. Okay, sorry, soapbox, creating another silo does not solve silos. But I have seen one of the more publicized instances of this was Nordstrom. They had a bunch of people that strongly believed in this stuff, knew how to do the things, et cetera. They formed a DevOps team, but their job was to go embed on other teams. So they would pair with the developer who didn't know how to do infrastructure as code. They would pair with the sysadmin that didn't know how to do useful monitoring, whatever it happens to be. And then they'd go back to theirs and share four stories and learn and so forth and so forth. So perfect way to share learning and it's their full-time job. Their job was then to make the organization better at continuous delivery in a DevOps culture. So the other pattern, please don't get fired. Depending on your organization, you might be able to just do it. But here's the thing, don't just do it on the safe project. Don't find the thing that's not risky and if I do this and it fails, then nobody really care because they also won't care if it succeeds. So find something you care about that could benefit from these things and try it. Don't forget the small successes and don't get discouraged. So I don't know if this is true. Well, I know it's probably true. This was all in the press because somebody did it about new year's resolutions and they fail. I know I do this. I come out and I'm like, I'm gonna do this thing and I'm gonna change the world. You get all these lofty goals and then they don't really come through right away and okay, I'm done, next shiny object. So understand that set expectations but make sure they're reasonable expectations because this stuff is really hard. But at the end, it's really worth it. HP, Gary Grover, Expedia, there's story after story after story of organizations that were saved from the brink of extinction by coming to the point where they were able to respond faster. How did I do? Time, not too bad. Some references and I have what? Two minutes for questions, if there's any. See, no questions is not a good sign. All right, thank you very much.