Gene Kim (00:00):This episode is brought to you by IT Revolution whose mission is to help technology leaders succeed through publishing and events. You're listening to The Idealcast with Gene Kim. Brought to you by IT Revolution. If you haven't listened to the last episode where I interviewed Mike Nygard, go listen to it now. If you have listened to it, here is a talk that I promised you. This is the entirety of Mike's 2016 DevOps enterprise summit presentation, where he talks about maneuverability and how to get teams, and teams of teams, working towards a common objective. The pitfalls that often large organizations stumble into and the principles and patterns on how one might overcome them. Join me as we listen to this presentation and like last time, I'll be breaking in periodically adding my own running commentary on points that I found particularly impactful, both when I originally listened to his talk, and listening to them now. And by the way, I got Mike's title wrong in the last episode. I introduced him as the vice president of enterprise architecture and platform development at Sabre. It's actually senior vice president of enterprise architecture and platform development. Okay, here's Mike. Michael Nygard (01:20):I am absolutely delighted to be here talking to you at the DevOps enterprise summit. This truly feels like my tribe because I've spent a lot of my career in large enterprises and I've spent a lot of my career trying to move towards this thing that we now call DevOps. Just a little bit of history, I've been a developer, I've been an architect, I've been a consultant. I also made the move into operations in the early 2000s and discovered just how little I knew about operations when I made that move. And discovered how badly most of our software survived in production, because I was part of a company providing outsourced operations and guaranteeing SLAs for software we didn't write and sometimes didn't have the source code to. If that sounds like fun, it actually can be, sometimes. But I got the opportunity to see hundreds of production failures and discover some patterns around them. Michael Nygard (02:18):And that's what went into my book, Release It! It's about patterns of production failures and patterns of solutions that you can apply to solve classes of those failures. I want to tell you a story from that time. I would say it's a story of DevOps, but DevOps as a term didn't exist then. This is a story of despair and hope. We have the hero of the system or hero of the story, my poor defenseless system. If this were a different kind of conference, I'd tell you about my poor defenseless system being under assault from a ravaging hoard of developers, carrying the fearsome multi tools, except for the brave sysadmin standing like Horatius at the Tiber. I'd talked to you about [inaudible 00:03:04] and how I wouldn't let them [inaudible 00:03:06], but we're not at that kind of a conference. Instead of that kind of a conference, the kind of story we have is more like a medical mystery. Michael Nygard (03:15):There is a victim. There is a patient that we need to save and nothing makes sense until the last 10 minutes after the final commercial break. And then we can solve everything. The patient in this case was the website. The victim in our drama was the bags of money, not the system. We were heading into a holiday season and our projections looked like we needed about $10 million of new hardware to make it through the holiday season. And that's assuming that all of our throughput scaled linearly. Well, when you start diagnosing a problem, you usually start with a connection diagram, something like this. This is maybe a little bit of an abstraction. There's some details left out here. Gene Kim (03:55):Gene here. I just want to explain that joke. Mike displayed a slide with basically two boxes on it. One box had the word application written on it and the other box had the word database written on it. And that's what people are laughing at. Obviously this is a gross oversimplification of a complex environment. Okay, back to Mike. Michael Nygard (04:15):We draw a connection as this arrow between boxes, but if you actually started getting closer to the wiring, you'd see things that didn't even appear in the previous one. Between the head and tail of that arrow, there's this whole other box. Actually two whole other boxes. And there's another thing off to the side. What I observed in the run up to this holiday season was very high IO on the backend monitoring switch. The one that didn't even appear on the original diagram. So we have our hosts running the apps. They don't actually look like this. They look more like this. And what we're dealing with here is something on one of these network ports is overactive. Well, it's a medical drama. So when you're in a medical drama and you don't know what to do, you biopsy something. Pretty much anything. Michael Nygard (05:06):And a biopsy for us looks like packet trace. So here's the packet trace. I'm looking at it and I see tons and tons of TCP connections from all of the app hosts to all of the other app hosts. Now they're going through a monitoring switch and they're not supposed to do that. That's a little bit weird by itself. But I'm also seeing that it's a lot of setups and tear downs and only one packet being exchanged on every connection. So we have this backend interface being hyperactive. We have about a hundred app instances and each one is opening up 99 connections, closing 99 connections. Turns out after some tracing and some, shall we say unauthorized code decompilation, I uncovered the problem, which was that products being displayed on the main page were having a transient attribute touched. Just like a blast display time. That attribute was not supposed to be written through to the database because you know, why do you update your product catalog when you're displaying it? Michael Nygard (06:05):But it was causing cache and validation notices. So anytime a product was displayed on any app instance, it was being knocked out of cache of every other app instance. It's not much of a cache when a thing can only be in one of them at a time. So basically we were doing this. I found the problem. I wasn't really in a position to fix it, but I could talk directly to a friend of mine in development who knew how to get things through the system. So we got a change request in, we bypassed a little bit of process and we got it done. He implemented the fix and started getting it passed through the release process while I started the change control process. Great collaboration, perfect example of dev and ops working together, except we kind of violated all the rules and broke the system a little bit. Michael Nygard (06:50):This worked because we could meet at a concrete language. We both understood enough of each other's realm to be able to communicate effectively. So we had abstractions in common. We could talk about the machines, the files, the sockets, the ports. I didn't need to talk about ITIL processes or San LUN remapping. He didn't need to talk about ESB transformations or any of that stuff. And so we were able to have this very rapid dialog and get some fast feedback going. That fix probably has the best return per byte of any fix I've ever made because we changed the word true to false and saved the company $10 million that year. Not bad. Kind of thing it makes you wish you worked on commission. So we had fast feedback going and fast feedback is a value that I think we all share here, but I need to sound a little bit of a note of caution. Michael Nygard (07:43):So I've listened to many of you talk about your stories of transformation in your companies. I've been consulting with a lot of companies that are transforming as well. And these things will sound like they're way off on the horizon, but I'm telling you what to expect next year or the year after, because feedback can actually start to cause problems. In fact, in systems, if your feedback gets too fast, you can generate noise. In aviation there's this thing called pilot induced oscillation. That's where your aircraft starts to nose up so the pilot pushes the stick forward. It starts to nose down, the pilot over-corrects pulling back, and you get this porpoising motion that's pretty hard on the equipment and really bad on any passengers that are up and about say, going to the lavatory. This is the type of thing that happens when your controls are changing slower than your feedback cycle. Michael Nygard (08:36):Your feedback is coming around faster, you're starting to feel the movement, you change your control, and there's some inertia in the system. It takes a little while for that thing you've done to propagate through and actually affect the variable that you were observing. And so you can get noise amplification in electrical circuits. This will happen with op amps that aren't damped. It can cause a lot of wasted energy and even damage. So since we're talking about aircraft, I'm going to reveal, or share with you that I grew up around the air force. I was an air force brat. A lot of what I've learned comes from studying other disciplines, including the military. There's this concept in the military called maneuverability. Maneuverability doesn't just mean sort of being quick on your toes and being able to pivot rapidly. It comes from a guy named John Boyd who was a fighter pilot and air combat instructor and later in his career became a military theorist. Michael Nygard (09:37):Boyd was a difficult person to like. He was confrontational, he loved to win an argument. Unlike every other jet fighter pilot you've ever known. One of the things he did was he created the first manual of air combat maneuvers, and actually taught this. So here was a set of practices that pilots had been sharing and doing, but no one had ever written them down and actually called them a discipline. So here's an example of a maneuver. Our protagonist here is the plane that goes up and comes back down versus the other one that's taking a wide bank. The idea is to get inside the opponent's turn radius so you can get them in front of you and get a firing solution. Michael Nygard (10:18):This maneuver consists of two parts. There's one part where you're exchanging kinetic energy for potential energy. And then there's the part where you change the potential energy back into kinetic energy. So as the plane is coming up, it's going to slow down quite a bit. It's that slowing and redirecting of the attitude that allows you to get inside the opponent's turn radius and get a solution on them. Boyd called this, energy maneuverability theory. He actually kind of taught himself an aerospace engineering degree to be able to work out the mathematics around this and was able to find that the key things in this are how fast you can change, exchange, kinetic and potential energy. How quickly you can gain and shed momentum and how rapidly you can change maneuvers. Now, I find this very interesting because we talk a lot about velocity. Velocity of course, is a speed and a vector, but we don't talk about acceleration in the sense of changing which direction our velocity is going. Michael Nygard (11:19):And that's really going to be a key component, especially as we atomize our teams and atomize our software. Following through on Boyd's story a little bit, he actually stole a bunch of computer time at Eglin Air Force Base near where I live now to run all of his calculations. He compared every aircraft in the US military with every aircraft in the Soviet military and found that they were all pretty much inferior to the Soviet aircraft and would lose fights because at every altitude and at every airspeed, the Soviet planes could gain and shed momentum and redirect their attitude faster. Pictured here is the FB-111. At that time, the proud new aircraft of the US inventory. This was the darling of the Pentagon and the darling of Congress because parts were made in every congressional district. Michael Nygard (12:06):This was supposed to be a fighter. It turned out to be a bad fighter so they relabeled it as a fighter bomber. It was a bomber that carried two bombs. Boyd put up a graph in front of the joint chiefs of staff that showed a sea of red with one tiny little dot of blue. That tiny dot was the one combination of airspeed and altitude where the FB-111 could win in a dog fight. Didn't make him any friends, but Boyd and a few others kind of did their own grassroots underground movement. He was assigned in the Pentagon and formed kind of a coalition of people that became called the fighter mafia. One of their projects was this aircraft, the F-16, one of the most successful fighter aircraft in human history. Relatively small, relatively lightweight. It actually has more thrust than the weight of the aircraft. So you can sit it on its tail and accelerate upward, which to me kind of sounds like a rocket, not an aircraft. But there's a couple of counterintuitive things about it. Michael Nygard (13:06):For one thing, it has very high drag. The short little stubby wings generate a lot of drag and we think of drag as a bad thing. Drag is wasted energy, right? But if you're trying to lose speed, drag helps. And so in a dog fight, this aircraft can accelerate rapidly, it can slow down rapidly and because it's kind of unstable, you can repoint it. And sometimes you even repoint at the direction you want to go. This aircraft flies at the edge of instability. Well, Boyd took this EM theory and developed it further into maneuver warfare, bringing in ideas that say, to defeat your enemy, you do it by generating fear, uncertainty, and surprise to demoralize the enemy and dislocate them from their centers of gravity. Distilled, the principles say, I should control the tempo of the engagements. I should take the initiative and I should send ambiguous signals so it's unclear what my ultimate objective is. Boyd also did this thing called the OODA loop. Some of you will have been exposed to that. We are not going to need it today so it's the last you'll see of this. Gene Kim (14:12):Okay. Gene here again. I want to concretize a couple of things Mike just mentioned. One is pretty obvious and one is certainly less obvious to me. First Mike mentioned the problem of slow feedback, which is at the heart of so many problems discussed in previous episodes with Elizabeth Henderson, Steven Spear, and the MIT beer game. This is what Mike is referring to when he talks about porpoising such as when a pilot tries to regain control of an aircraft without sufficiently fast feedback. The second point, which is less obvious, at least to me, was around something that Mike mentioned in the last episode. He mentioned Gregor Hohpe in the context of the architects elevator. Hohpe gave great talk last year that mentioned something that really caught my intention. He said that architects must increasingly live in the first derivative. In other words, the first derivative of position is velocity. Gene Kim (15:01):And the first derivative of velocity is acceleration. These days, the motivation for architecture involves something to do with the rate of change. In a legacy system where there is no need to change at all, there's often no need for further architecture, let alone a new architecture because it's a stable state. The current architecture can handle the needed rate of change. But an environment that is very dynamic, where we need to maneuver, we need to lower the cost of change. This is a term that I'm trying to understand better. So how many times have we wanted to do something, but we weren't able to act fast enough? Consider the discussion that I had with Steve Spear about the book, Team of Teams. when an enemy leader was sighted, if we couldn't rally ourselves quickly enough, that would never lead to capture the intended goal. Somehow the cost of change was simply too high. Gene Kim (15:49):Either the effort was too high or it would require too many moving pieces to mobilize. Something, prevented us from enacting the need to changes. Something, prevented us from making it so. Whatever that is. Instead, what we want is a lower cost of change. So when an opportunity is found, we have the ability to organize ourselves fast enough to deliver some response or some offering to the market. Obviously the fact that I'm having so much difficulty articulating this says that it's not quite straight in my head, yet, but I think when Hohpe talks about living in the first derivative, I think he's suggesting that we need high maneuverability. We need a lower cost of change. Hohpe goes on to say, maybe that's why we care so much about continuous integration and continuous deployment because it is the method of which we inject change into production. Ideally, we want to do it smoothly, quickly, accurately without causing chaos and disruption. I'm going to put a link to Gregor Hohpe's presentation in the show notes. Okay. Back to the interview. Michael Nygard (16:51):A lot of what we're talking about with this idea of being on the edge of instability is what you get in complex systems that reach a sort of self-organized criticality. And I contend that our enterprises are in fact complex systems, specifically complex adaptive systems, and they will tend to push themselves to the edge of instability. They'll create this self-organized criticality. Now mathematicians have analyzed this in great detail with things like avalanche models, catastrophe manifolds, earthquake distributions, and other very reassuring ideas. These are all examples of nonlinear phenomena that occur in organizations as well as dynamical systems, but they're kind of undirected. You don't get to bias them towards a positive outcome. So what we need to do though, is find a way to take our systems and organize them to create nonlinear responses in a direction that we'd like. And this is where we can come back to maneuver warfare and find some lessons from it. Gene Kim (17:56):We are so much looking forward to the DevOps enterprise summit, Vegas, virtual, which will now be held on October 13th to the 15th. As always, the goal of the programming committee is just to bring you the best experience reports and to out program all our previous events. And this year we expect to deliver on that promise again. I am so excited about the speaker lineup we have for you, partly because they are among the most senior technology and business leaders that have spoken at this conference, showing you how important the work of this community is. Maya Leibman is CIO of American Airlines who presented at our annual forum in April and we were fascinated by the perspectives that she shared with us. I'm so excited that she will be co-presenting with our longtime friend, Ross Clanton about the American Airlines journey. And since 2014, we've all been dazzled by the CSG journey as told by Scott Prugh and Erica Morrison. Gene Kim (18:49):I am so thrilled that this year Scott Prugh will be co-presenting with his boss, Ken Kennedy, executive vice president, and president of CSG, the largest provider of customer care, billing, and order management in the US. Ken and Scott will be sharing their story on the interplay between business and technology leadership and how it resulted in their amazing accomplishments over the years. This is just the beginning. Stay tuned for more exciting announcements about our amazing speaker lineup. This will undoubtedly be the best DevOps enterprise summit program we've ever put together. You can find more information at events.itrevolution.com/virtual. Michael Nygard (19:32):A brief capsule description of maneuver warfare. The old thinking in warfare, going back to Clausewitz and others, was that you win by having superior forces, more material and manpower, and simply destroying the enemy's ability to conduct battle. And then you can just roll over them. This is the war of attrition, and it's what gave us things like trench warfare in World War I and became exceedingly costly. The idea of maneuver warfare is to say, instead of committing to an objective early and digging in trenches, we're going to see where progress can be made. This is actually an older idea of warfare. It's be strong where your enemy is weak. So find where you get a bit of an advance, push harder there, and enlist or pull other forces in to help you. I'll contend that this is the opposite approach of typical corporate IT management. If you have a failing project, you tend to put more resources into it. If you have projects that are successful, you tend to drain people away from them and reassign them elsewhere. Michael Nygard (20:36):What we should be doing is probably more like this, where we try and take the successful projects and let them draw in more resources and further capitalize on that success. Now, in order for this to work, we have to have the ability to change directions. So this is the maneuver part. We need to be able to gain or shed momentum. We need to be able to redirect where we're going. We can do this in our work by applying these ideas of disposability, disposable infrastructure. By the way, I don't like the term immutable infrastructure. I much prefer disposable infrastructure because it gets more at what I want out of it. I want to be able to destroy and recreate these things as often as I need. Michael Nygard (21:13):I also like the idea of disposable code. I think code is inventory, not an asset. You should make it so that you can delete any piece of your code and recreate it as cheaply as possible. Dependencies definitely need to be disposable. Dependencies in code in between teams are the number one thing that will slow you down. I'll say, maybe even the teams need to be disposable. That doesn't mean lay people off, but it means be able to say this service is no longer serving its purpose, so we're going to shut it down and reassign the people. Or we're even going to take that team as a unit that's already functioning as a unit and give them something else to work on. Michael Nygard (21:50):Okay. So reminder, we're going to set the tempo, obscure our ultimate objective, defer commitment. And so let's talk about tempo. You've probably encountered tempo in this sort of a notion, the steady ticking of the clock, the clunk of the metronome, this idea of tempo comes from takt time in Lean, but it doesn't work all that often in the work that I do because takt time really requires standardized work, which we rarely have. The other notion of tempo is again, coming from the sort of military arena, tempo is how rapidly you can engage, disengage, move somewhere else. If you take an experienced combat unit with a convoy of say, 200 trucks to come in and set up an encampment, they can set up in one hour. Michael Nygard (22:42):They can tear down the next day in one hour and continue moving. An inexperienced or green unit will take six hours to set up camp and six hours to tear down camp. That doesn't leave you very much time to actually get farther down the road. So there is benefit to the experience of doing this and having done it many times. It comes from 10,000 small decisions and small pieces of knowledge. How to pull the trucks in so that you can pull them all out in order, instead of having to shuffle around. Pulling them in with enough spacing so you can get in and out and load and unload gear. Knowing where to set up tents. There are safety issues involved too. A unit that has experience will have less accidents and injuries. One of the sadly common things was when a soldier would set up his sleeping bag someplace that the trucks would drive over the next morning. Michael Nygard (23:32):People will joke about the right way, the wrong way, the army way, but it turns out knowing where to find the mess hall, where to find the latrines, knowing where not to walk, because it's a microwave line of sight beam, these all help you achieve higher tempo. In our world, this means there are common skills that people need to know how to do. So, you know how to use version control, but you still need to learn how to use this team's version control or this organization's version control. You know how a build pipeline works, but do you know the differences between Jenkins and Spinnaker? It matters when you make that switch. Well, this is a force that kind of pushes against the idea of every team for themselves, every team does their own thing, because there can be some efficiencies that you gain from having people able to move fluidly and be effective. Michael Nygard (24:21):This doesn't mean you push back to one size fits all and everyone in the company is in our Perforce system. It means there is some granularity where the flexibility of a team picking their own tools, meets the utility of people being able to move around. Okay. So after this talk, we're all going to go back to our company and say, from now on, I set the tempo. Well, of course it doesn't really work like that. Tempo is another emergent property. It's the result of your ability to maneuver. It comes from some characteristics of your organization and really has to be built at every level. Something that we observe in the military context is what we call horizontal and vertical integrity. The idea is that if I'm a small unit commander, I have a pretty good idea of how other small unit commanders near me are going to make decisions. I don't necessarily know exactly what decisions they're going to make, but I know how they will think about things because we've all been trained the same way. Michael Nygard (25:22):This is something that's actually really lacking right now, because as you go upward in the organization, you sort of pass through geologic strata, but in an inverted way, right? The higher you go, the older the skillset gets. So the methods of training, the assumptions, the ways of doing things are not uniform up and down. One of the characteristics that they talk about in maneuver warfare is that everyone should share the same fingerspitzengefühl, which means fingertip feeling. And it's sort of an idea of instinctive actions given a context. So if you were presented with a particular production outage and you want to make sure it doesn't happen again, what's your go to response? Hopefully here, you'll say the response is systemic. We need to increase safety in the build pipeline, we need to increase the resilience of the systems. But I guarantee you there will be people in your organization whose response is process-based and about instituting greater reviews. You do not share the same fingerspitzengefühl. I practice this word so I have to use it enough times to make it worthwhile. Michael Nygard (26:32):Communication structures are another piece of how you can get flexibility out of these units. So imagine we have a structure like this, could be your service structure, be your team structure. They're probably isomorphic, right? So imagine that your comms kind of go like this, you know, something's going wrong, you need help. And you have to go up a chain to reach a sufficient level of management, and then back down the other chain. By the time you get help, it's going to be way too late. So this would be the equivalent of a unit in the field requesting close air support and having to go talk to the Pentagon to get an A 10 dispatch, to come and provide close air support. By the time it gets there, it's tomorrow and it doesn't matter. Or in our context, we finally get all our applications into Puppet, but the devs have moved on to Docker and we have to redo all that. Michael Nygard (27:19):A better version of communication is to have direct lateral communication during the events, and then provide the after action review later on, after the, well, after the action has happened. The prerequisites for this are those ideas of common language and definitely some trust and common priorities. One of the things that impeded this in the US military for years was something so stupid it's hard to believe, but different branches of the service had procured different radios that couldn't communicate with each other. They used different frequency hopping codes and algorithms. So you'd have an air force unit and an army unit that literally couldn't talk to each other. We wouldn't have anything like that, right? Like, one team in HipChat and another one in Slack. Michael Nygard (28:08):Okay. There are things we can do at the team scale, we've spent a lot of time talking about this and looking at it, but there are also things we need to think about at the group scale. There are a couple of ideas from domain driven design that I think we can apply here, the notion of a bounded context and a ubiquitous language. So within the bounded context, we should all be speaking the same language. Product teams help here. And then I'm going to add a notion called intent and I'll come back to what that means in just a moment. I think discoverability is hugely important and I think temporary assignments across different groups or across different divisions also really help build that lateral trust across your organization. Michael Nygard (28:52):Okay. So intent is another idea that has been taken up in the military quite thoroughly. The idea is when you give an order, you don't just say, what is being done? You actually do explain why. This will come as a surprise to people whose idea of the military is still based on world war II movies. But actually the command and control notion was broken down a long time ago, back in the eighties. These days, there are different variations in different branches of the service, but all of them have some notion of a complete order, including all of these ideas. So situation is, who are the friendly forces, who the enemy forces, what is the terrain like? Are there civilian structures in the area? The mission is who, what, where, when, and most importantly, why. The commander's intent always includes why. What is it? What is the purpose of the action you're about to take? Michael Nygard (29:48):Execution has a lot of military stuff in it. What's the vulnerability? How are you going to exploit it? What's the desired end state? What are the tasks? What's the coordination? Actually, none of that really sounds military does it? That kind of sounds like how you execute on any strategy. Administration or sustainment. The fun way that I heard that described is beans, bullets, and batteries. That's what you need to keep the units operating. And then command is your signal structure. Who is the decision maker? Who's the secondary if the decision maker can't respond? What is the command structure and what's the succession in the command structure? So this notion of intent is typically expressed as five paragraphs on one page or two pages. It's used at every level. So generals provide intent to colonels, colonels provide intent to captains and lieutenants and so on. Michael Nygard (30:40):The final idea I want to bring in very quickly is initiative. Now initiative doesn't mean you're rolling to see who moves first. Initiative here comes more from the idea of Go. There's this notion of Sente in Go, which is a move that demands a response. So when you have sente, you determine the rate of territory change. The inverse notion is Gote, which means you must respond. So a couple of quick examples, when Amazon created AWS, they took sente from all the hosting providers. I know, I was working at one and jumping up and down, trying to get them to listen. When Uber went into Thailand, they undercut the tuk tuks. And in Thailand, you don't mess with the tuk tuks. The tuk tuks and the cab drivers convinced the government to ban Uber. So that was them taking back sente. Uber was a move that they had to respond to and they did pretty successfully. Michael Nygard (31:37):Contrary example. When Uber went into London, the black cab drivers protested by disrupting traffic and blocking people from getting to their jobs. This did not make people angry at Uber, it made them happier with Uber and mad at the cab drivers. So that was not recovering sente. If you combine initiative and tempo, then you are taking the initiative. You're making moves that your opponents have to respond to and you're actually going to accelerate away from your opponents. You're going to advance faster than they can catch up. And so this is how I think we can combine the emergent properties of tempo, maneuverability, and initiative so that in our autonomous teams, we can all be moving in a direction and accomplishing right actions as the easy path, rather than trying to re corral things and have the pendulum swing back to centralized control in another decade. Michael Nygard (32:32):So if you would like a copy of the slides, please send an email to this address, mtnygard@zip.sh with the subject tempo, you'll get the slides and a few other bonus items. And I thank you for your time and attention. Gene Kim (32:45):Wow. That is such an interesting presentation and I'm so glad Mike expounded on so many of these concepts in the interview you heard in the last episode. I listened to this presentation before I interviewed Mike for the first time, and again, before recording [inaudible 00:33:01]. It's so interesting to me that after each episode, I feel like I'm definitely understanding better where this quest to understand organizations and how they work, where that quest is taking me. One of these concepts is definitely lowering the cost of change, which came up in a discussion that Steve Spear and I had only two weeks ago. So I'll be bringing you some of those aha moments in the weeks to come. I want to end by making three observations. One is about the comm structure. So when Mike talked about having to go up five levels down three in order for two engineers to work together, that is what was called the square in the unicorn project. This is clearly something that happens way too often when the structure of the organization doesn't allow the right type of interactions between individuals. Gene Kim (33:47):The second observation is this. So often we talk about deployment as if that were the goal. And sometimes we talk about learning as if that were the goal, but actually neither of those are the goal. Achieving the goal is the goal. So John Cutler is a person whose work I love to follow. He said something to me last year, that's taken me over a year to understand. He most recently said this at the DevOps enterprise talk in London. He said, "Are you shipping faster than you're learning? Or are you learning faster than you're shipping?" I think what he means is this, is that it's easy to think that once we've deployed a feature into production we've achieved the mission, but that actually falls so short of what we really need to do. Gene Kim (34:29):We have to make sure that what we did actually achieved the intended desired effects so that we can get even better at achieving similar goals, understanding the real customer problems so that we can do even more of it. Often we don't take the time to really understand and study is a customer reacting in ways that we want them to? Are we taking the customer down a journey where we can provide even more value? And if we're not doing that, it might not make sense for us to keep shipping more features based on clearly incorrect assumptions. So when Mike talks about taking Sente or taking initiative from our adversary, this is what it reminds me of. The question is, are we really winning in the marketplace? And that question is so much larger than an engineering concern. Gene Kim (35:15):And the reason why I bring it up is that it is my observation that within the DevOps enterprise community, that challenge is not being adequately addressed. In other words, the product and UX community are not rising up to solve these challenges. And it is often the technology leadership community that's filling that gap. My third observation is around Mike's talk title, DevOps, maneuverability, and tempo. I think what makes this talk so interesting that it's partly a talk about strategy and it's partly a talk about tactics. He talks about things like creating structures and decentralizing decision-making and communicating in a way so that we can unleash affects far larger that can be generated by a single team. It's about how do you organize teams and set them up in a way that creates a system where the hole is much larger than the sum of its parts? Gene Kim (36:10):Okay. I hope you enjoyed that presentation from Mike Nygard from DevOps enterprise 2016. In the next episode, I will post my followup interview with Mike, as we further explore the nature of great architecture, dive more deeply into the trade-offs of that amazing payment processing example and how to tell whether we really have too many notes or actually generating simplicity that enables better agility in the future. And we'll talk about more of what he learned about architectural coupling from Rich Hickey, the author of the Clojure programming language. See you then. Gene Kim (36:46):Thank you so much for listening to today's episode. Up next will be Dr Steven Spears, DevOps enterprise summit presentations, both from 2019 and 2020, where he talks about the need to create a rapid burning dynamic, as well as how to create them. The 2019 presentation talks about many of the case studies we talked about today, but in more detail. And in 2020, he talks about one of the most remarkable and historic examples of creating a dynamic learning organization at scale, which was in the US Navy at the end of the 19th century at the confluence of two unprecedented changes. One was in the underlying technologies, which you found in ships and in the strategic mission that they were in service of. As usual, I'll add my reflections and reactions to those presentations. If you enjoyed today's interview with Steve, I know you'll enjoy both of those presentations as well.