Host Intro (Gene Kim)

Gene Kim: 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?" 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 into that message? I will wait for a couple of seconds for you to add your reaction.

All right. Thank you so much. All right. 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 Dr. Steven Spear. For now, let's just call it structure and dynamics. Then I want to describe how it applies to our community and specifically to this conference.

What is structure and dynamics? Since December of last year, I've been having these weekly calls with Dr. Steven Spear, who you heard from yesterday. I've been trying to understand this mental model that he's had in his head that he uses to explain how the world works. For six years, I've been dazzled by his clarity of thinking, by his amazing ability to predict how the world works, how the world should ideally be, and what goes wrong. I just want to understand how he does it, what is his mental model. What's emerged out of it are really three constructs.

I love the principle of parsimoniousness, the notion that the goal of science is to explain the most amount of observable phenomena with the fewest number of principles, to confirm deeply held intuitions and reveal surprising insights. These three constructs certainly do that for me. I'm going to go through each one of them, just to maybe elicit the same reaction in you.

Dominant architectures: what are they and where do they come from? To answer that, Steve might say, "Well, we create organizations to solve problems, and typically, we need an organization because the problem is so large that no one person can do it by themselves." Whenever we do that, we end up in this situation where we have to figure out how we decompose work so that teams can actually work independently of each other, and how do we describe the interfaces and interactions with the team so that we don't let each other down.

Once we create that, a dominant architecture emerges. It happens when we have processes and teams and team of teams that do a great job. It becomes very effective, very reliable, resilient, but also resistant to change. 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 The Other Side of Innovation by two professors at Dartmouth University in the business school, Dr. Vijay Govindarajan and Dr. Chris Trimble. 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? Their answer is that it's because they have sustained greatness for decades, as measured for them by being able to sustain billions of dollars of revenue across decades or more.

The way they do this is through process, through hierarchy. One of the characteristics of these processes and hierarchies 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. What they found was that studying organizations like the first BMW electric car project, the first small tractor line at John Deere, the Wall Street Journal digital operations, 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 pull of the past. I'll talk a little bit more about that later.

Another famous book that addresses this problem is The Innovator's Dilemma by Dr. Clay Christensen. Essentially, the story about this book is when you get really good, you get into a groove, but then the groove turns into a rut, and now it seems almost impossible to escape the past. New innovations are devoured by the dominant architecture. 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 of even seeing the problems. Again, I'll talk a little bit more about this later.

Where specifically do they come from? In the beginning, in so many endeavors, everyone's in one room, and it's not clear how to divide up the work so that we know what the team should do so we can meet at the end. In startups, everyone does everything. In large projects, you 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. That's structure.

Sometimes it's just not clear what the dominant architecture should be. In the dawn of the automobile, it wasn't clear what the metaphor for steering should be. Is it like the tiller on a boat? Is it like the reins controlling a horse in a horse and buggy? Or is it like the modern steering wheel? Until that's decided, it's very difficult to have consistent engineering processes.

Electric cars versus petroleum cars: to what extent are their architectures similar or different? We're grappling with this right now. Online conferences: do they really look like physical conferences, or are the architectures going to be vastly different?

One dominant architecture that we probably grapple with all the time are project management, the fiscal and budget planning processes. In The Unicorn Project, that was really dedicated to the achievements of this scenius, so many successful rebellions that have told their stories here about how they've been able to take on the ancient, powerful order and bring in a new, better way of working. Incidentally, the person who came up with this model, Dr. Carlotta Perez, will be presenting a panel tomorrow along with my friend Dr. Mik Kersten, and she has the most optimistic view of the future that I can't wait for you to see.

All right. That's dominant architecture. Let's talk about structure. Structure is how we organize our teams and how they interface with each other. In our world, it also encompasses the architecture that we work within. Many people say, of course, it's obvious, as dictated by Conway's Law. It's not so obvious to me, and this has been a huge revelation, to what extent structure is almost inextricably linked to architecture. How we organize teams is inextricably linked to architecture.

Steve Spear says, "Ideally, we want the teams shaped around the topography of the problem, that teams are organized in a way so that local problems can 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.

Just a little side note. I learned in this early part of the year to what extent Steve Spear's doctoral dissertation was influenced by Dr. Carliss 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, which was astounding to see in the Harvard Business Review decoding the DNA of the Toyota production system.

What's also super interesting and surprising to me was to what extent Dr. Baldwin influenced the work of Dr. Mik Kersten, so here's two people whose work I very much admire, that they were both influenced by one person. That was very unexpected and made me buy every book that Dr. Baldwin wrote.

What I'm learning is to what extent architecture constrains the solutions we can create. I 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. They put them into a dedicated team. They put in charge of 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: in this new project, the battery team would have to work directly with both powertrain and brakes. In no previous project had the battery team ever had to talk to the brakes team. Not only was that never done, but the dominant architecture would not even allow it. It was by allowing them to create an architecture of their own that allowed them to create a market-beating solution.

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, it resulted in far inferior outcomes. He jokingly said, "You might as well have put a gasoline-powered Black & Decker generator in the back seat to charge the battery." Essentially, that was done because that was the only thing that the dominant architecture allowed.

There are so many examples of patterns like this where we create skunkworks, whether Lockheed Martin, who invented skunkworks, the Comcast Xfinity team, as told by John Moore and team at DevOps Enterprise Las Vegas last year, and U.S. Bank Studios, as told by Levi Geinert and Werner Loots, about how they've created these studios where the goal is that they can do whatever is needed by the customer without having to rely on other parts of the organization.

That's structure. That leads us to dynamics, which is basically everything else. In structure, we define the nodes in the system, and dynamics say there's going to be signals transmitted between them. There are things we can do to amplify signals, such as in Alcoa, the amazing safety culture where Paul O'Neill said his top objective was to make sure that there were zero accidents on the job, and he reinforced that in almost every interaction that he had. Those are things that definitely amplify signals.

In our community, we have blameless postmortems. We talk a lot about psychological safety. We want frequent andon pulls so that we can learn. All of these things help amplify even weak signals so they get spread throughout the organization.

On the other hand, there are things that we can do to dampen signals or even extinguish them altogether. Imagine an organization where we have a culture of fear, where people are afraid to tell the truth or tell bad news because they fear being punished, castigated, or embarrassed. These are all things that dampen signals and impede the organization from actually learning and doing what it's supposed to do.

Signals also include feedback. We've talked a lot about feedback in this community, and that's definitely a source that is a part of the dynamics of the organization. One of the famous examples of no feedback is the famous Fremont manufacturing plant. It was notorious for decades because it was the worst-performing automotive plant, not just in North America, but around the globe.

Steve Spear writes that, "There were no effective 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 so many instances of engines being put in backwards, cars missing steering wheels or tires, cars having to be towed off the assembly line because they wouldn't even start. That's not ideal, right? In fact, you can install an andon 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.

The opposite 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. The reason we want that is that we want to invalidate assumptions, minimize the separation between system as designed versus system as it actually exists. The more we invalidate, the more we learn, the more we can outlearn the competition.

This should also be familiar to us in our community, as demonstrated by the famous Westrum organizational typology model. This shows up very prominently in the State of DevOps research. What Dr. Ron Westrum found 20 years ago was that one of the top predictors of patient outcomes and patient safety was culture. He created three buckets. On the left, we have pathological cultures with the worst patient outcomes, where information is hidden, messengers of bad news are shot, bridging between teams is discouraged, failures are covered up, and new ideas are crushed. The organization with the best patient outcomes he called generative: we seek information. Messengers are trained to tell bad news. Responsibilities are shared. Bridging is rewarded. Failure causes a genuine sense of inquiry, and new ideas are welcomed.

One of the most decisive findings in the State of DevOps research is that this was one of the top predictors of performance. 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 viewing them through the lens of structure and dynamics.

The MIT beer game is a famous business simulation that was created in the 1960s, where you have four players: the beer retailer, distributor, wholesaler, and the factory, the brewery. What they found in thousands of trials across decades is that most teams perform spectacularly poorly. It doesn't take a lot to go wrong before inventory levels go out of control and everybody loses. 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. You can't give feedback the other way. No one can actually see what customer demand is.

When I asked Steve, "What would you do in the structure to get better outcomes?" he said, "Well, it would be really helpful if you could just acknowledge the order. You ordered two cases last week. I got it, and you ordered two cases now. I got it. You don't need to order more." Better yet, it would be great to say, "Order received. You will get your order in two weeks. There's nothing we can do about it." If there's a dam 100 miles away, we open the dams, and it will just take weeks for the water to get here. By better being able to set expectations and better building trust, we can actually ameliorate the bad effects that we see in so many examples of the MIT beer game.

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 a smaller and nimbler adversary in Iraq in 2004 with not such good outcomes. David Silverman, one of the co-authors, will tell you the story later today. As you listen to the story, think about what he tells you in terms of structure and dynamics, and how were they able to get such amazing outcomes by changing both.

One of my friends is a chief operating officer at a healthcare organization, and they're in the middle of trying to replicate the amazing safety culture that was created at Alcoa that is so brilliantly documented in Steve Spear's book. One of the things that really caught my attention was that the COO needed to be a part of the daily safety meetings. When I asked why, he said, "Well, he's the only person who can actually escalate issues from across the organizations." I asked Steve why, and he said it's because it's the only official and sanctioned 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. In The Unicorn Project, we call this the square. In order for two people to talk to each other, they have to escalate three, four, five levels and then back down for them to communicate and solve a problem.

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 these teams to actually be able to solve problems for each other without having to escalate up three, four levels all the time? 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 in the hospital, you had the surgeons and the nurses, and that was it. These days, we have far better outcomes, but it's actually created scores of specialties, and that number is going up and not down, and that's happening across every industry.

Let's talk about this conference. 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. Are they like theater, where everything's live, or are they more like cinema and movie making, where everything's recorded? That affects everything about the conference.

Some of my biggest surprises for me is the degree to which I'm interacting with people within the team that I've never interacted with. We have video editors that we work with externally, and in previous years we just gave them the footage that was recorded, and they would process them, create the picture-in-pictures, and they would upload it into YouTube. But now that all the recording is happening before the conference, 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. It's involved a lot of learning. I'm using tools that I've never used in my career, like video editing tools, recording tools, and so forth. It has been a wild couple of months.

Before I turn it over to speakers, I just want to say how much I appreciate and am amazed by the effort that all of the speakers have put in. I've always admired how much work they put into creating these presentations, rehearsing it, but 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 get things right.

Each of the plenary recording sessions have averaged one hour and 45 minutes, and I've just been, again, blown away by the work that our speakers have put into it. If you've been enjoying this presentation, please make sure you give that feedback to them because, again, I am in awe.

I actually collected some speaker setups of just the wild configurations that people have created to enable great recordings. This is John Allspaw. This is Victoria Mayo. You can see the stack of books that was used to be able to get the microphone to the same height. Victoria Mayo just moved to Zurich, and she was moving furniture around so that she could get things where she could see things, in fact, tables to get a light in the right position. This is James Head using a ladder. Tim Sweeney, wow, that's interesting, using a ladder as well. Just the amazing amount of improvisation and experimentation required to deliver these recordings to you.

By the way, I couldn't leave this section without showing you mine. What you see here on the screen is being recorded here, and this is what I see. You can see the stack of encyclopedias, a microphone off camera, and the camera. This has evolved over weeks of recording, trying to figure out how do you actually do this in a way that actually isn't unpleasant for you.

With that, that is my opening remarks. We have a great day for you today. We have the team from Nationwide, Credit Suisse, David Silverman from Team of Teams, Scott Proulx 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.

Conference Logistics (Jeff Gallimore)

Jeff Gallimore: I hope everyone is fired up for a great day two of 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 in the correct and corresponding Ask the Speaker channel in Slack. @mention the speaker both during and after their presentation. 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, 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 BOF. Join one, if you haven't already, for the topics that interest you. Then, at the networking time, join the active 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 DeGrandis, who's our Lean Coffee leader, will 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.

Last, we've got Chat Roulette. This is a way for you to have one-on-one conversations with other attendees with similar interests. If you haven't already, join the Snack Club channel in Slack, answer a few questions to build your profile, and then when we're ready to chat, just type /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 are available for download in Dropbox and GitHub.

Thank you to IT Revolution for bringing us this amazing event in partnership with Snyk, who we're 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 DevOps journey.

So, let's get ready for a great day two. Gene, let me hand it back to you to introduce today's first speaker.