Las Vegas 2020

Day 3 Opening Remarks

Welcome to day 3 of DOES Las Vegas-Virtual! Join us to begin with conference updates and learnings.

GK

Gene Kim

Founder and Author, IT Revolution

JG

Jeff Gallimore

Chief Technology and Innovation Officer, Excella

Transcript

00:00:06

Good morning, welcome to day three of the conference. I hope you had an amazing day too. And rest assured that day three will be no less amazing, but I'd like to do this morning is just take five minutes to concretize some of the concepts that Dr. Steven spear presented yesterday. As I had mentioned since January, I've been having weekly working calls with him, trying to understand how he views the world, because I've always been dazzled by the clarity of his thinking and his amazing ability to protect how the world works and should work. And what I've learned is this, he views the world through the lens of dominant architectures, structure and dynamics. So yesterday he discussed how dominant architects are emerged so that organizations can solve problems. We decompose work so that teams can work independently with well-defined interfaces and interactions between teams and once a dominant architecture establish itself is very effective, reliable, resilient, and also extremely resistant to change.

00:01:04

One of my favorite books on this topic is the other side of innovation by Dr. Govindarajan and doc tremble. Two professors at Dartmouth university and their area of study is trying to understand why it is so difficult for large complex organizations that are dominant in their category to innovate. And one of their conclusions is that the performance engine, the dominant architecture is what sustains greatness over time, and the dominant architecture kills threats to itself. It has an immune system. It is why organizations tend to favor twatty the way we've always done it. Another great book in a similar vein is innovator's dilemma by Dr. Clay Christiansen. He writes you get into a groove, but the groove turns into a rut. Uh, the observation is that the dominant architecture is incapable of solving problems that it wasn't designed for. And in some cases it is probably incapable of even seeing those problems.

00:01:59

And over the years, we've talked about the works of Dr. Carlotta Perez. Her PhD dissertation was about the causation behind the economic boom bust cycles. She writes that there have been five technical revolutions, the industrial revolution, the age of steam and railways, the age of steel and heavy engineering, the age of oil and mass production and the upcoming age of software and digital, each one of those areas created a new management system to properly exploit the new technology revolution that created factory subsystems, sub contracting Taylorism Fordism. And so much of the technology community, uh, points to project management and offshoot of Taylorism as one of the top obstacles to achieving their goals. And so the question then becomes, as we enter the age of software and digital, what will replace Taylorism and Fordism, and I would assert that it is really dynamic learning organizations that Steve talked about yesterday.

00:02:50

So structure is how do we organize our teams and how do they interface with each other structure also includes the architecture that we within. So ideally teams are shaped around the topography or the problem so that local problems can be solved locally with effects that are contained locally. So teams can work independently without causing disastrous global effects, and then it can make decisions without requiring vast escalations up to the CEO of the hospital system. Like Steve talked about yesterday. Um, and often it is structure, which includes architecture that constrains the solutions that the organization can create. In the other side of innovation book. One of my favorite examples that they talked about was the BMW electric car project, where they actually had to create a dedicated team because in no scenario in the previous cars, would the battery team ever have to work directly with powertrain and brakes.

00:03:43

The dominant architecture would never allow it. So it's interesting to see that unlike BMW, unlike the Toyota Prius Chevy volt was actually built within the dominant architecture that dominant architecture constrained the design. As Steve said to me, they might as well have put a black and Decker generator in the backseat to charge the battery because it was a vastly inferior way of solving the problem. So structure is the way we organize our teams. The interfaces teams are allowed to interact with each other. It is the architecture that we work within and dynamics is everything else, uh, with no does in the structure transmit and receive signals. Signals can be amplified. So famously in the Alcoa safety culture, Paulo Neil, that the CEO, his top objective was always zero on the job accidents reinforced in every interaction that he had, uh, practices like postmortems, psychological safety, the, and on court.

00:04:36

All of these things allow for signals to be amplified so that teams can receive them and act upon them before they cause a fury crash. The opposite of that is where signals are dampened or extinguished entirely. And this happens in a culture of fear where few people are afraid to tell bad news. And this is where a weak signals are. Extinguished signals of course include feedback. There are systems where feedback is almost entirely absent in the Fremont general motors manufacturing plant, which was notorious for decades because it was not only the worst performing automotive plant in north America. It was a, probably one of the worst automotive plants around the globe for decades, because there were no procedures in place to detect problems during the assembly process, nor were there explicit procedures on what to do when problems are found as a result, there were instances of engines being put in backwards cars, missing steering wheel to tires causing even having to be towed off the assembly line because it wouldn't start.

00:05:33

So obviously that is not what we want. And so one of the best examples that I think it would be very familiar to everyone in the dev ops community is the Westrum organizational typology model. So Dr. Ron Western studied healthcare organizations and studied those organizations with the best patient outcomes. What he found was that culture was a significant predictor that those organizations with the worst patient outcomes had these characteristics information hidden messengers of bad news are shot bridging between teams with discouraged failures are covered up and new ideas were crushed. And on the other hand, the organization was the best patient outcomes had these characteristics. Uh, there were generative information was actively sought. Messengers are trained to tell bad news, uh, bridging between teams is, uh, rewarded because responsibilities are shared. So we know that InfoSec is not just Infosec's job, just like uptime is not just opposite job.

00:06:25

It is everybody's job. And when failures happen, it causes a genuine sense of inquiry and new ideas are welcomed. And so I'm so delighted that we had David Silverman and Jessica arrived talk about how these principles and the practices that show up in team of teams are so applicable to this community. What I learned is that the structure remained mostly unchanged according to the org chart. For example, the Navy seal still reported to the secretary of the Navy, the army Rangers still report to the secretary of the army. However, they're all matrix into short and medium term mission teams with common objectives, with radically different ways of interfacing with each other, which resulted in a whole set of new dynamics where decision-making was moved to the edges. A whole new layer of middle management leaders were able to reallocate resources to best achieve the mission.

00:07:15

The last thing I want to share with you is this quadrant on the X axis, we show the degree to which work is standardized to which it is repeatable on the Y axis is the degree, which we integrate feedback into our standardized processes. So on the upper right-hand quadrant, we have these experimental cultures where learning is encouraged and integrated into everyone's daily work. Examples include the Toyota production system, the Apollo program, the safety culture at Alcoa, the U S Naval reactor core, uh, the U S Navy pre world war II. So high degree of standardized work as well as high degree of feedback integrated into standardized work and in the lower right-hand corner we have of status work, but very little feedback integrated into that standardized work. Uh, this is called the standardized model by Dr. Amy Edmondson, where we have not a culture of learning, but a culture of compliance.

00:08:04

Examples of this might include the U S spatial program where weak signals were extinguished and maybe the U S Navy during world war two, uh, as they had to increase their manpower where it was not about exploration, Beauvoir, exploitation, and then, um, on the lower left hand corner, uh, we have low degree of standardized work and low degrees of integration of feedback. So this is where really we're relying on trial and error, uh, versus methodical experimentation. We have no memory of how problems were solved before basically rolling dice to make decisions. So the reason why I share this with you is that for me, this is a very parsimonious way to describe organizations through structure, through dynamics. Some of which emerge into a dominant architecture. Now I use the word parsimonious, uh, because for me it, it satisfies for many, the definition of science explains the most amount of observable phenomena with the fewest number of principles. It confirms deeply held intuitions and reveals surprising insights. And so I'm so excited by the work that I'm doing with, uh, Dr. Steven spear, to try to explain as much of the world around us with the fewest number of principles and maybe reveal why organizations struggle to do the right thing when we have a pretty good idea of what the right thing is. So that concludes my mini lecture. So before we go to our talks, let me first turn it over to Jeff.

00:09:24

We've had a great first two days of the DevOps enterprise summit, get ready for a great final day as well. I just wanted to do a quick check in with you. How are you feeling? Well, you might be totally fired up about all the things you've learned. You might be feeling like you finally found the place where you belong your community. You might be thinking about all the things you've learned and the people you've talked to and wondering what you're going to do with all of it. You might finally be realizing that the struggle is real.

00:10:01

You might also have a sense of resolve a sense that you can do it. You can make a difference. And if you've been staring at a screen for the last two days, your tape might just be completely empty. And if you're like me, you might be feeling all of these all at the same time. That's okay. Plug in, fuel up, get ready for a great day. Three of the DevOps enterprise summit. We want to hear your stories. We want to hear what you've learned. The people you've met, the ideas you want to try out and the actions you'll take. When you go back to work, please share those with us in the summit stories channel in slack, please, please, please. That's three pleases. Get that session. Feedback in the feedback is so valuable to us. The speakers and the program committee feedback is a gift sharing is caring, thanks to it, revolution for bringing us this fantastic DevOps enterprise summit event and getting this amazing community together.

00:11:03

A huge thanks to our premier sponsor. Sonatype a big thank you to all of our virtual BFS sponsors. Thanks to our virtual good friend sponsors. Thanks to our media sponsors for helping get the word out about the amazing things happening in this community. And thanks to LaunchDarkly for sponsoring the 2020 DevOps enterprise journal. If you haven't gotten the journal yet you owe it to yourself to do that. Thank you to all of our sponsors, because as we know sponsors, add sparkle to our DevOps journeys. Now it's the final day. Get ready strap in. It's going to be terrific. Jean, back to you to introduce the final days for speakers.