Gene Kim

Good morning. Welcome to day three of the conference.

I hope you had an amazing day two, and rest assured that day three will be no less amazing.

What 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 predict 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 architectures emerge 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 establishes itself, it is very effective, reliable, resilient, and also extremely resistant to change.

One of my favorite books on this topic is "The Other Side of Innovation" by Dr. Vijay Govindarajan and Dr. Chris Trimble, two professors at Dartmouth. 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. One of their conclusions is that the performance engine, the dominant architecture, is what sustains greatness over time. The dominant architecture kills threats to itself. It has an immune system. It is why organizations tend to favor TWADI, the way we've always done it.

Another great book in a similar vein is "The Innovator's Dilemma" by Dr. Clay Christensen. He writes, "You get into a groove, but the groove turns into a rut."

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.

Over the years, we've talked about the works of Dr. Carlota 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 eras created a new management system to properly exploit the new technology revolution, and that created factory subsystems, subcontracting, Taylorism, Fordism, and so much of the technology community points to project management, an 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? I would assert that it is really dynamic learning organizations that Steve talked about yesterday.

So structure is: how do we organize our teams, and how do they interface with each other? Structure also includes the architecture that we work within. Ideally, teams are shaped around the topography of the problem so that local problems can be solved locally with effects that are contained locally. Teams can work independently without causing disastrous global effects, and they can make decisions without requiring vast escalations up to the CEO of the hospital system, like Steve talked about yesterday.

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. 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 & 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.

Dynamics is everything else. Nodes within the structure transmit and receive signals. Signals can be amplified. So famously in the Alcoa safety culture, Paul O'Neill, their CEO, his top objective was always zero on-the-job accidents, reinforced in every interaction that he had. Practices like postmortems, psychological safety, the Andon cord, all of these things allow for signals to be amplified so that teams can receive them and act upon them before they cause a fiery crash.

The opposite of that is where signals are dampened or extinguished entirely, and this happens in a culture of fear, where a few people are afraid to tell bad news, and this is where 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 probably one of the worst automotive plants around the globe for decades, there were no procedures in place to detect problems during the assembly process, nor were there explicit procedures on what to do when problems were found. As a result, there were instances of engines being put in backwards, cars missing steering wheels or tires, cars even having to be towed off the assembly line because they wouldn't start. Obviously, that is not what we want.

One of the best examples that I think would be very familiar to everyone in the DevOps community is the Westrum organizational typology model. Dr. Ron Westrum studied healthcare organizations and studied those organizations with the best patient outcomes. What he found was that culture was a significant predictor: those organizations with the worst patient outcomes had these characteristics: information was hidden, messengers of bad news were shot, bridging between teams was discouraged, failures were covered up, and new ideas were crushed.

On the other hand, the organizations with the best patient outcomes had these characteristics. They were generative. Information was actively sought. Messengers are trained to tell bad news. Bridging between teams is rewarded because responsibilities are shared. We know that InfoSec is not just InfoSec's job, just like uptime is not just ops' job. It is everybody's job. When failures happen, it causes a genuine sense of inquiry, and new ideas are welcomed.

I'm so delighted that we had David Silverman and Jessica Reif 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 SEALs still reported to the Secretary of the Navy, the Army Rangers still reported to the Secretary of the Army. However, they were all matrixed 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.

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 to which we integrate feedback into our standardized processes.

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 US Naval Reactor Corps, the US Navy pre-World War II: a high degree of standardized work as well as a high degree of feedback integrated into standardized work.

In the lower right-hand corner, we have a high degree of standardized work, but very little feedback integrated into that standardized work. This is called the standardized model by Dr. Amy Edmondson, where we have not a culture of learning, but a culture of compliance. Examples of this might include the US space program, where weak signals were extinguished, and maybe the US Navy during World War II, as they had to increase their manpower, where it was not about exploration, but it was about exploitation.

In the lower left-hand corner, we have a low degree of standardized work and lower degrees of integration of feedback. This is where really we're relying on trial and error versus methodical experimentation. We have no memory of how problems were solved before, basically rolling dice to make decisions.

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 because, for me, it satisfies, for many, the definition of science. It explains the most amount of observable phenomena with the fewest number of principles. It confirms deeply held intuitions and reveals surprising insights.

I'm so excited by the work that I'm doing with 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.

Before we go to our talks, let me first turn it over to Jeff.

Jeff Gallimore

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've 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.

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 tank might just be completely empty. 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.

A huge thanks to our premier sponsor, Sonatype.

A big thank you to all of our virtual BFF 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. Gene, back to you to introduce the final day's first speakers.