Sam Fell

Welcome, everybody. Thanks for coming back for the third and final, unfortunately final, day of the DevOps Enterprise Summit. You guys are all having a good time. I heard the cheers and the claps before, but how about one more?

Cheers and claps for Gene and the program. Fantastic content.

Welcome. Gene, me. Okay, we went through this. The code of conduct, you guys all know what it is. I don't think there have been any incidents, which is fantastic. Thank you all for being so respectful to your fellow conference-goers.

Don't forget the passport game. It's not going to be at 1:30, like I said yesterday. So continuous improvement. It's 1:15. We're shifting it left, which is good. Be in the Electric Cloud booth by 1:15. You've got to be there to win. Marguerite Kim is going to be announcing the winner, and I hope that you all win. So there you go. You all win.

I do hope you all win. Yeah, but I know that's impossible.

Lightning talks. Who went to the lightning talks last night? Right on. John and Damon, fantastic job.

Gene, what were some of the thoughts about the lightning talks?

Gene Kim

I thought they were amazing. You had asked me backstage which one was my favorite, and I then came up with, "All of them." It was great. I was sitting right there. I respect all the incredible courage to do those.

I've done one lightning talk, and it was many years ago, and if I have it my way, I will never do another lightning talk again. They are so stressful. So thank you so much for doing that. You guys were awesome.

Sam Fell

Very good. All right. Right on. And I'm going to hand it off now to you, Gene, to talk a little bit more about some of the content that we've seen and some of the new content that we'll be sharing.

Gene Kim

Excellent. All right. Thank you, Sam. Thank you. Thanks, everybody.

So yesterday, a couple people have said how much they enjoyed the first two days. By the way, how has the conference been so far?

Good. In fact, someone actually did say, "How do you top that?" And I could see why you would say that, but before I tell you why I'm so excited about day three, I want to share with you some of the highlights for me over the last two days.

One was certainly the talk that was given by John Resig and Stephanie Gillespie from KeyBank, because they had the CEO of the bank talking externally about how the efforts that they had worked on were helping KeyBank win in the marketplace. That actually led to, as John Willis predicted in 2010, that DevOps would actually be mentioned on CNBC, on Mad Money. It seemed insane back then. And yet, on Jim Cramer, they're talking about Docker, Kubernetes, and quotes from the CEO, which I thought was incredible.

The second one was Topo and Jennifer from Capital One, about how DevOps leadership and former auditors are now working together, working towards common objectives, not only to be secure, but to help make it defensible to internal auditors, external auditors, compliance professionals, regulators, and even lawyers. I think that is just an amazing and seminal moment in certainly DevOps Enterprise, but I think in the DevOps Enterprise community as well.

And then three is the John Allspaw talk yesterday. It was incredible. For me, I got chills when he said that he had not felt so passionate about an idea that he felt was so important. The last time he felt that a topic was this important was his 2009 talk at Velocity with his colleague Paul Hammond, about doing 10 deploys a day, every day.

And I think you were probably like me when your jaw dropped, and maybe your brain melted, when he said, "We have the stuff above the line, right? And then we have the stuff below the line. And everything below the line doesn't actually exist." Right? That everything below the line, the code, the environments we run in, is almost like Schrödinger's cat. The mere act of observing it changes it. In fact, one could even say that there's nothing really there.

And I think for me, the feeling was like reading Zen and the Art of Motorcycle Maintenance. There's a famous passage, just a sweeping passage, about what is quality, really. Anyway, I think for me, that was definitely one of the top moments.

So what's the next slide?

Okay. So day three. I'm going to make a claim that may seem hard to believe, but day three is going to be as good, maybe even better, than days one and two.

So in the remainder of the opening remarks, I just want to share with you two things. One is a little bit about explaining further and maybe quantifying the value that I think DevOps is going to create. I had shared yesterday the work of Dr. Carlota Perez in terms of the deployment age, about her claims that led my friend Chris Little to say that we're just at the tip of the iceberg of the value that DevOps will create, even to the tune of something like 20 years of prosperity.

One thing I forgot to mention here is that before the inflection point, before and after: before is financial capital; after is production capital. One of the things that I found very surprising and hopeful was the fact that the period of financial capital, during this period of speculation and innovation, is actually a period of ever-increasing inequality in terms of wealth. The rich-poor gap continues to grow.

What makes the golden ages of production capital so exciting to me is that that's actually the tide that lifts all boats, and this actually reverts the wealth distribution gap. And so I think one of the outcomes is that we actually do get a more just society. So I think that's important.

But let's talk about numbers. So in The DevOps Handbook, we make this claim in the book, just to try to pencil out what is the economic value that DevOps will create, and we put a number in there at $2.6 trillion.

So what I want to do just for a minute is just walk you through that calculation. Let me just walk through the calculation, and it's really seven rows in a spreadsheet. So what you do is you first take the GDP for the year 2011, so that's $62 trillion. And then you go to Gartner's statistic that says 5% of global GDP is spent on technology. And then you do the calculation, and then you end up with $3.1 trillion.

And then you say, "All right, how much of that is on operate and maintain? And of that, how much of it is on unplanned firefighting?" And so John Allspaw yesterday said, "This is the sunk cost that is forced upon you in terms of what reality gives us."

So then you do that calculation, and you get 518, I think, billion. I'm getting lost in my head here. Let's see, 3.6, 300 million. Okay, so that's 518 billion. I'm getting lost with my numbers here.

So then you say, what happens if we could halve the amount of waste on IT and redeploy it in a way where we can get five times the value back, right? In other words, what is the opportunity cost of all that quote-unquote waste? And the number is $2.6 trillion, right?

And so you can come up with a million reasons of why this is too optimistic. You can argue about any one of those numbers. And by the way, for every one of those, I can argue back. For every number here, I can argue why it should be higher. So let's just put that aside.

I think what is amazing is that the units of value here is in the trillions of dollars per year. So you think about what does that mean to me? You take a look at the biggest problems facing this world, whether it's climate change, whether it's poverty, whether it's opportunity that children can't get access to. All these problems seem unsolvable now. If you can generate trillions of dollars of economic value now and for decades in the future, suddenly everything seems solvable, right?

So exactly what the numbers are, we can have that debate all day long, but the point is there's trillions of dollars of economic value per year that's going to be generated. That is my belief. So that's the first thing I wanted to share with you.

The second also comes from The DevOps Handbook. There's a book that we mentioned called The Other Side of Innovation by Dr. Govindarajan and Dr. Trimble, and they're at the Dartmouth School of Business. And it was a critical aha moment for me.

And so in their book, what I want to do is just kind of zoom in and share with you some of their learnings that I think are very relevant to this community. So the problems that Govindarajan and Trimble set out to solve was the notion of disruptive innovation, that they wanted to understand why is disruptive innovation so hard for large, successful organizations to adopt, right?

And anyone who's read Clay Christensen's book, The Innovator's Dilemma, essentially this is the same problem. And so as part of their journey, they studied the first electric car project at BMW, the first small tractor line at John Deere, the first consumer-driven auto insurance products at Allstate, the first digital publishing operation at The Wall Street Journal, the first innovative trail running shoe at Timberland.

And all of these were innovative efforts that all succeeded, and essentially they came up with a model of what they did differently that allowed them to succeed where most innovative ventures don't.

And the constructs they provide is this. Essentially, they say there's something called the performance engine in successful organizations. And so how do they define a successful organization? It is any organization that is, say, doing billions of dollars of revenue that spans over decades. It means that they have created greatness in daily operations. And not operations like in IT operations, but in every aspect of the organization, they have figured out how to maintain this amazing level of performance, whether it's product development, supply chain management, transportation, logistics, all these things.

And so the way you preserve greatness, they observe, is often through process and bureaucracies and functional silos. And so these are what allows organizations to preserve greatness, even when half the people disappear.

But what's good for the performance engine is actually death for transformative innovation. And by the way, this book was introduced to me by Robert Cummings, who actually worked for Courtney Kissler when they were at Starbucks together.

So the notion of a dedicated transformation team is someone who can be put outside of the performance engine. They're held accountable to a result, but they are freed from a lot of the processes and procedures and regulatory things that are great for the performance engine but will absolutely prevent the transformation team from succeeding.

So there's a phrase in this book at the end that I just found very meaningful. The first one was about the nature of the people who lead these dedicated teams. They have to be politically savvy, skilled at building partnerships, because they have to do this delicate dance of driving success for the dedicated team, but also having to interface with everybody in the performance engine.

So when I read this book, it just immediately reminded me of all these behaviors that I've seen in the DevOps Enterprise community.

The second phrase I found very meaningful because it predicts sort of what the trajectory of these people are. In other words, the people in this room. It said after you have succeeded leading disruptive, innovative things, they get promoted, often sometimes to the CEO of the company. And they become the obvious choices of who will drive the next important initiative.

And there's really three characteristics of these people. One is they are worthy of it. Two is they have a broad experience that is unmatched in the organization. But the third one, I still get goosebumps reading, is that it is someone who everybody knows has the best long-term interest of the organization at heart. It's not about the transformation effort. It's not about DevOps. It really is helping the organizations not only just survive in the marketplace but thrive in the marketplace.

So if there's one book I would say that has just a tremendous amount of advice and guidance, it is really The Other Side of Innovation. So I think that is my final slide.

Right, and so then my next job is to introduce the next speaker. And by the way, I was talking to a couple of you last night, and some of you actually didn't believe me when I said that Sidney Dekker was on a tugboat in the middle of San Francisco Bay. It really is true, right? So we found out at 4:00 PM, and it's, "Oh, God..."

And here to introduce Sidney is my good friend John Willis. And I'll just repeat that he's the author of Just Culture, Safety Differently, The Field Guide to Understanding Human Error, all these books that so many of us have read and have taken guidance from in our own journey. So John.

John Willis

Thanks, Gene. It's been a wild ride.

Yeah, I asked Gene if I could come and introduce Sidney because I've been trying to get him at this conference for four years now, since the beginning. I met Sidney at the first, it was a DevOpsDays Brisbane, and he was keynote one, and I was day two keynote. And I went, and I saw his presentation, and I was just blown away.

And I'd read some of his books. And I went to him after, and I said, "I think there's a commonality between what you're talking about and things like Lean." And I said, "What you're talking about is non-determinism." And I challenged him. I challenged him to look at his work through the eyes of Deming.

It turned into a challenge. It ended with a friendship. I'd love to introduce to you all Dr. Sidney Dekker.

Sidney Dekker

Thank you, brother. Thank you.