Day 2 Open

Welcome to Day 2 of DevOps Enterprise Summit London-Virtual.

GK

Gene Kim

Founder and Author, IT Revolution

JG

Jeff Gallimore

Chief Technology and Innovation Officer, Excella

Transcript

00:00:10

Good morning, everyone. I hope you had a terrific day one, and that you enjoyed the amazing talks and that you had a bunch of great mutually exothermic interactions in the networking sessions. So normally at the beginning of day two, I would ask, how was your day one as measured by your round of applause? So since obviously that won't work, how about we do this? I just put a message into slack asking how your day one went and because feedback is love. Could you please take a moment to attach the most appropriate emoji, uh, into that message? So I will wait for a couple seconds, uh, for you to add your reaction.

00:00:53

All right. Thank you so much. All right. So what I'd like to share with you today in these introductory remarks, I want to share with you what I've been learning as I've been having these amazing calls with, uh, Dr. Steven spear and, uh, for now let's just call it structure and dynamics. And then I want to describe what, how it applies to our community and, uh, specifically to this conference. And so what destruction dynamics. So since December of last year, I've been having these weekly calls with Dr. Steven spear, who, who you heard from yesterday. And I've been trying to understand this mental model that he's had in his head that, uh, he uses to explain how the world works. So for six years, I've been dazzled by his clarity of thinking, uh, by his amazing ability to predict how the world works, how the world should ideally be and what goes wrong.

00:01:43

And I just want to understand, you know, how he does it, uh, what is his mental model? And what's emerged out of it are really three constructs. And so I love the principle of parsimonious minus the notion that the goal of science is to explain the most amount of observable phenomenon with the fewest number of principles to confirm deeply held intuitions and reveal surprising insights. And, uh, I had this, these three constructs, certainly do that for me. So I'm going to go through each one of them, uh, just to, uh, maybe elicit the same reaction and you so dominant architectures, um, what are they and where do they come from? And so to answer that, uh, Steve might say, well, we create organizations to solve problems. And typically, uh, we need an organization because the problem is so large that no one person can do it by themselves.

00:02:35

And so, uh, whenever we do that, we end up in this situation where, uh, we got to figure out how do we decompose work so that the teams snatcher work independently of each other? And what, how do we, uh, uh, describe the interfaces and interactions with the team so that, you know, we don't let each other down. And so once we create that, uh, this, uh, dominant architecture emerges, that happens when we have processes and teams and team of, uh, that do a great job. And so it becomes very effective, very reliable, resilient, but also resistant to change. And what's so interesting is that there's so much in the literature that describes exactly this. One of my favorite books on this is called other side of innovation by two professors at Dartmouth university in the business school, uh, Dr. Govindarajan and Dr. Tremble. And so what they describe in their work is they're trying to answer the question, why is it so difficult for large complex organizations to innovate?

00:03:30

And, uh, their answer is that it's because that they have sustained greatness for decades, uh, as measured for them by, you know, billing, being able to sustain billions of dollars of revenue, you know, across, you know, uh, decades or more. And so the way they do this is through process through hierarchy. Um, and one of the characteristics of these processing Hargreaves is that they're incredibly resilient. These processes are designed such that you could take out half the bureaucrats and the process still goes on. And so what they found was that studying organizations like the first BMW electric car project, the first, uh, uh, um, uh, small tractor line at John Deere, the wall street journal, digital operations, that they were only able to innovate by separating people away from what they call the performance engine. They create a dedicated team, and that was the only way they could escape the pole of the past.

00:04:19

So I'll talk a little bit more about that later. Another famous book that addresses this problem is innovator's dilemma by Dr. Clay Christiansen. And essentially the story about this book is you, uh, when you get really good, you get into a groove, but then the groove turns into a rut, and now it is impossible. Um, it seems almost impossible to escape the past. You know, new innovations are devoured by the dominant architecture, and then he makes the observation that the dominant architecture is almost incapable of solving problems. It wasn't designed for, and moreover it is probably incapable even seeing the problems. And again, I'll talk a little bit more about this later. And so, uh, where specifically do they come from? So in the beginning, uh, in so many endeavors, everyone's in one room and it's not clear how to divide up the work so that, you know, we know what the team should do so we can meet, uh, at the end.

00:05:11

And so in startups, uh, you know, everyone does everything and large projects who often are in a situation where everyone has to be in one room just to figure out how do we decompose the work and what actually makes sense. So that's structure. Um, oh, uh, so sometimes it's just not clear what the dominant architecture should be, uh, in the Dawn of the automobile. Uh, it wasn't clear when, uh, what the metaphor for steering should be. Is it like the tiller on a boat? Is it like the rains, uh, uh, you know, controlling the horse and the horse and buggy, uh, or is it like the modern steering wheel? And so until that's decided it's a very difficult, uh, to have consistent engineering processes, uh, electric cars versus electric, uh, versus petroleum cars, to what extent, you know, are there architecture similar or different, uh, and we're grappling with this right now, online conferences, do they really look like physical conferences or are the architecture is going to be vastly different?

00:06:09

Um, one dominant architecture that, uh, we probably grapple with all the time are project management, the fiscal and budget planning processes. And so in the unicorn project that was really dedicated to the achievements of this seniors. Uh, so many successful rebellions that have, uh, told us stories here about how they've been able to take on the ancient, powerful order and, uh, bring in a new, better way of working. And certainly the person who came up with this model, Dr. Carlotta Perez will be presenting our panel tomorrow, along with my friend, Dr. Mick Kirsten. And she has his most optimistic view of the future that I can't wait for you to see. All right. So that's done architecture, let's talk about structure. Structure is how we organize our teams and how they interface with each other. And that also in our world, it also encompasses the architecture that we work within.

00:06:58

So many people will say, of course, it's obvious as dictated by Conway's law, uh, as not so obvious to me. And so this has been, uh, a huge revelation to what extent structure is almost inextricably linked to architecture, how we organize teams is inextricably linked to architecture. And so Steve Spurrier says, ideally, we want the teams shaped around the topography of the problem that teams are organized in a way, so that local problems could be solved locally with effects contained locally. In other words, a small change here won't result in a catastrophic detonation of a distant remote part of the system that we may have never even heard of. Um, just a little side note, uh, I learned in last, uh, this early part of the year, uh, to what extent Steve Spears, doctoral dissertation was influenced by Dr. Carlos Baldwin at Harvard university. Some of us may recognize her name because she wrote some of the most seminal works around modularity and software architecture, uh, which was astounding to see, uh, in the Harvard business review decoding the DNA of the Toyota production system was also super interesting and surprising to me was to what extent Dr.

00:08:06

Baldwin influenced the work of Dr. Mccarsten. So that here's two people whose work. I very much admire that they were both influenced by one person. It was very unexpected and makes me, it made me buy every book that Dr. Baldwin wrote. So what I'm learning is that's to what extent architecture constraints to solutions we can create. So I had mentioned the other side of innovation work. They studied the BMW electric car project, and what their conclusion was at the early onset of the project was that the electric car they wanted to build could not be built within the existing dominant architecture. Uh, and so they put them into a dedicated team. Uh, they put in charter that a leader from the performance engine, so that they could be credible to the performance engine, so they could figure out the best way to share resources. But here's the main reason is that in this new project, uh, the battery team would have to work directly with both powertrain and breaks.

00:09:05

And so in no, uh, previous project has the battery team ever have to talk to the breaks team. And so not only was that never done, but the dominant architecture would not even allow it. And so it was by allowing them to create an architecture of their own that allowed them to create a market beating solution. So if we look at the other end of the spectrum, let's look at the Chevy volt. Here's an example where the car that was produced was created within the dominant architecture. And as Steve spear says, uh, it resulted in far, uh, inferior outcomes. Uh, and he jokingly said, you might as well have put a gasoline powered black and Decker generator in the backseat to charge the battery. And essentially that was done because that was the only thing that the dominant architecture allowed. So there are so many examples of patterns like this, where we create skunkworks, whether Lockheed Martin who invented skunkworks, uh, the Comcast Xfinity team, uh, as told by John Moore and team at DevOps enterprise Las Vegas last year and USBank studios.

00:10:06

So it's told by Levi guy, nerd and Verner Lutes about how they've created these studios, where the goal is that they can do whatever's needed by the customer, uh, without having to rely on other parts of the organization. So that's structure, uh, that leads us to dynamics, which is basically everything else. So, uh, in structure, we define the nodes in the system and dynamics say, there's going to be signals transmitted between them. And so there are things we can do to amplify signals, such as an Alcoa, the amazing safety culture, where Paulo Neil said his top objective was to make sure that there were zero accidents on the job. And he reinforced that. And almost every interaction that he had, uh, those are things that definitely amplify signals in our community. We have blameless postmortems, we talk a lot about psychological safety. Uh, we want, you know, frequent and on pool so that we can learn all of these things, help amplify even weak signals.

00:10:59

So they get spread throughout the organization. Uh, so on the other hand, there are things that we can do to dampen signals or even extinguish them altogether. So imagine an organization where we have a culture of fear where people are afraid to tell the truth or tell bad news, uh, because, uh, they fear being punished cascaded or embarrassed. These are all things that, uh, dampen signals and impede the organization are actually learning and doing what it's supposed to do. Uh, signals also include feedback. Uh, we've talked a lot about feedback in this community and that's definitely a source, uh, that is definitely a part of the dynamics of the organization. So I, one of the famous examples of no feedback is the famous, uh, Fremont manufacturing plant. And so it was notorious for decades because it was a worst performing, uh, automotive plant, not just in north America, but around the globe.

00:11:49

Um, and, uh, Steve sewer writes that there were no effective in place to detect problems during the assembly process, nor were there Simplicit procedures on what to do when problems are found. And so, as a result, there are so many instances of engines being put in backwards cars, missing steering wheels, or tires cars haven't been towed off the assembly line because they wouldn't even start. So that's, um, not ideal, right? And in fact, you can install an, an Don cord in those plants and no one would pull them because when you do you get yelled at because you're actually jeopardizing the production targets. So the opposite of what of that is what we want. We want as much feedback in our system as possible from as many areas as possible, sooner, faster, cheaper, with as much clarity between cause and effect. And the reason we want that is that we want to invalidate assumptions, uh, minimize the separation between system as designed or as a system, as it actually exists.

00:12:40

And the more we invalidate, the more we learn, the more we can outlearn the competition. So this should also be familiar to us in our community as demonstrated by the famous organizational or the Western organizational typology model. So this shows a very prominently in the state of DevOps research. And so what Dr. Ron Western found 20 years ago was that one of the top predictors of patient outcomes and patient safety was culture. And so he created three buckets. And on the left, we have pathological cultures. What's the worst patient outcomes where information is hidden. Messengers of bad news are shot. Uh, bridging between teams is discouraged. Failures are covered up and new ideas are crushed. And then, uh, the organization with the best patient outcomes, he called generative, we seek information, uh, messages are trained to Dell. Bad news responsibilities are shared. Bridging is rewarded.

00:13:33

Failure causes a genuine sense of inquiry and new ideas are welcomed. And so one of the most decisive findings in the state of DevOps research is that this was one of the top predictors of performance. So what has been so rewarding and endlessly fascinating and dazzling to me is taking a look at all these examples that I've known about my past, but views them through the lens of structure and dynamics. So the MIT beer game is a famous business simulation that was created in the 1960s, uh, where you have four players, their beer retailer, um, distributor wholesaler, and, uh, the, and the factory, the brewery, and what they found. And, you know, thousands of trials across decades is that, uh, most teams perform spectacularly poorly. It doesn't take a lot to go wrong before, uh, inventory levels go out of control, uh, and, uh, everybody loses.

00:14:25

And so it's been so interesting to see how much of this is dictated in the structure of the game. In other words, communication is only one way, uh, you can't give feedback the other way. Um, no one can actually see what customer demand is. And so when I asked Steve, what would you do in the structure, uh, to get better outcomes? And he said, well, it would be really helpful if you could just acknowledge the order, right. And you ordered, uh, two cases last week. Um, I got it, a new order, two cases. Now I got it. You don't need to order more, um, better yet. It would be great to say order received, you will get your order in two weeks. Uh, there's nothing we can do about it. Like, uh, if there's a dam, you know, uh, a hundred miles away, you know, we open the dams and it will just take, you know, weeks for the water to get here.

00:15:12

Um, so by better being able to set expectations and better building trust, you know, we can actually ameliorate the bad effects that we see, uh, in so many examples of the MIT beer game. Uh, here's another one team of teams. This is one of my favorite books I've read in the last decade. It is the story of the joint special forces task force in Iraq, battling us fall or smaller nimbler adversary, uh, interact in 2004 with not such good outcomes. And David Crossman, one of the coauthors will describe tell you the story, uh, later today. So you listen to the story, think about, uh, what he tells you in terms of structure and dynamics and how were they able to get such amazing outcomes? Um, by changing both,

00:15:56

Um, one of my friends is a chief operating officer of the healthcare organization, and they're in the middle of trying to replicate the amazing safety culture, um, uh, that was created Alcoa. That is so brilliantly documented in Steve book. And one of the things that really caught my attention was that, uh, the chief, the COO needed to be a part of the daily safety meetings. And when I asked why he said, well, it was, uh, he's the only person who can actually escalate issues, you know, from across the organizations. I asked Steve why, and he said, it's because the only sanctioned and official way, uh, is the only official instinctual way for say nursing to talk with pharmacy. He actually says that's very typical in healthcare organizations. And he thinks my friend is lucky. Sometimes it doesn't go all the way to the CEO. It has to go to the healthcare system CEO.

00:16:44

Um, and so in the unicorn project, we call this the square, right, in order for two people to talk to each other, they have to escalate 3, 4, 5 levels, right. Um, and then back down for them to communicate and solve a problem. And so what's been an interesting thought experiment is to be able to say, all right, what interfaces need to exist between departments such as nursing pharmacy and transport in order for the, these teams to actually be able to solve problems for each other, without having to escalate up three, four levels all the time. And I think this is important because in healthcare, the level of specialization is increasing dramatically. In the 1950s, you could argue that there were really only two specialties. You had the doctors and the hospital, you had the surgeons and the nurses, right then that, that was it. These days we have far better outcomes. It's actually created scores of, of specialties. And that number is going up and not down, and that's going to happen, that's happening across every industry.

00:17:39

So let's talk about this conference. Um, so it's been fascinating to think about this as we go through the construction and delivery of this online conference, right now, it is not known what the architecture of online conferences are. They, are, they like theater where everything's live, or are they more like cinema and movie-making where everything's recorded. Uh, and that affects everything about the conference. Some of my biggest surprises for me is, uh, the degree of which I'm interacting with people within the team that I've never interacted with. So while we have video editors that we work with externally, and in previous years, uh, you know, we just gave them the footage that was recorded and they would process them, uh, create the picture and pictures and they would upload it into YouTube. Uh, but now that all the recording is happening before the conference, you know, we're having to work with them all the time and we're having to develop dramatically different workflows in order to get all the work done in a way where you can be watching them today.

00:18:38

And so, uh, it's been involved a lot of learning, uh, I'm using tools that I've never used in my career, like video editing tools, um, uh, recording tools and so forth. Uh, so it has been a wild, uh, couple of months. So, uh, before I turned it over to speaker, I just want to say how much I appreciate. And I'm amazed by the, uh, effort, uh, that all of the speakers have put in. Uh, I've always admired, you know, how much work they put into creating these presentations, rehearsing it. But, uh, what they've done this year is at a whole new level. They had to get the recording set up, deal with lighting camera, audio, and all the experimentation to, to get things right. Uh, each of the plenary recording sessions have average a one hour and 45 minutes. And I've just been again, blown away by, uh, the work that our speakers have put into it.

00:19:25

So if you've been enjoying this presentation now, please make sure you give that feedback to them because I, again, I am in awe. So, uh, I actually collected some speaker, uh, setups of, uh, just the wild configurations that, that people have created to enable great recording. So, uh, uh, this is, uh, John all spa. Uh, this is, uh, Victoria Mayo. You can see the stack of books, uh, that was used to be able to create, uh, uh, to get the microphone to the same height, uh, Victoria Mayo, uh, just moved to Zurich and, uh, she was moving furniture around so that, uh, she could, uh, get things where she could see things. In fact that, uh, uh, tables to get a light in the right position. Uh, this is, uh, James Head, uh, using a ladder, uh, Tim Sweeney, uh, ah, well, that's interesting. You're using a ladder as well.

00:20:12

So just the amazing, amazing amount of improvisation and experimentation required, uh, to deliver these recordings to you. And by the way, I couldn't leave this section without showing you mine. So, uh, what you see here on the screen, uh, is he is being recorded here, and this is what I see. And then you can see the stack of encyclopedias and microphone off camera on the camera. This is, uh, evolved over weeks of recording, trying to figure out, you know, how, how do you actually do this in a way that, uh, actually isn't unpleasant for you. So with that, uh, that is my opening remarks. Uh, we have a great day for you today. Uh, we have the team from nationwide, uh, credit Swiss David Silverman from team team Scott Pruitt from CSG and John Willis. It's a great day. I hope you enjoy it. I'm going to turn it over to Jeff. Thank you.

00:20:59

I hope everyone is fired up for a great day to have the DevOps enterprise summit. Just a quick update from yesterday's virtual happy hour. I am happy to report no donuts, lots of croissants. Everyone was open to new people and new conversations. Just a reminder to get your session feedback in for the sessions that you attended yesterday. Remember, feedback is a gift and sharing is caring. You can engage with speakers again today. They'll be available in slack during their scheduled talk time, just post your question. And the correct and corresponding asked the speaker channel in slack at mentioned the speaker both during and after their presentation. And if you have thoughts on a question that somebody else has asked, please contribute. We have the networking time again today. Again, dedicated programming, no other programming. So the FOMO should be low. We have birds of a feather, lean coffee and chat roulette again today for birds of a feather.

00:21:58

This is a place for people of like-minds and interests to get together and talk. We've got birds of a feather channels set up. Each of those is prefixed with B O F. So join one. If you haven't already for the topics that interest you, then at the networking time, join the act of call that's in the channel so that you can engage with your other attendees and participate in the discussion post in slack during and after, and then continue the conversation just like yesterday. We've got lean coffee again today, Dominica to grant us. Who's our lean coffee leader. We'll be running that we'll be using zoom, breakout rooms and mural, which is that collaborative virtual whiteboard. If you can find your way to the zoom call, we'll take care of the rest. And then last we've got chat roulette. This is a way for you to have one-on-one conversations with other attendees, with similar interests.

00:22:52

If you haven't already joined the snack club channel in slack, answer a few questions to build your profile. And then when we're ready to chat, just type slash snack to be randomly paired with other attendees, we have the session slides and videos available. All of the videos from the keynotes yesterday are available. Now the videos for the keynote talks today will be available after they air. The videos of the breakout talks are all available for all three days as are the slides, which were available for download in Dropbox and get hub. Thank you to ITU revolution for bringing us this amazing event in partnership with snake who were really tapping their expertise to help us bring a great virtual experience to you. A big thanks to our virtual BFF sponsors, our community sponsors our media sponsors and remember sponsors add sparkle to your dev ops journey. So let's get ready for a great day to Jean. Let me hand it back to you to introduce today's for speaker.