Host Intro (Gene Kim)

One of the most impactful learning moments for me was taking a workshop at MIT Sloan in 2014, which tremendously influenced my thinking. I went to this specific class because it was taught by Dr. Steven Spear. He is famous for many things, but he's probably most famous for writing one of the most downloaded Harvard Business Review papers of all time. This was in 1999, called "Decoding the DNA of the Toyota Production System." This was, in part, based on his doctoral dissertation that he did at the Harvard Business School.

And in support of that, he worked on the manufacturing plant floor of a tier one Toyota supplier for six months. And since then, he's extended his work beyond just high-repetition manufacturing to engine design at Pratt & Whitney, to the building of the safety culture at Alcoa, and to how we can build genuinely safe healthcare systems. Recently, he was part of a US Navy initiative to create high-velocity learning across all aspects of the enterprise.

I've had the privilege of having weekly working calls with Steve since January, and my goal was to try to understand how he views the world, and I've learned that it's through the lens of structure and dynamics. So structure is how we organize our teams and defining what are the allowed interactions between them, in other words, the interfaces. And dynamics is almost everything else. Is there a system where weak signals of failure are amplified so they can be acted upon before they cause a disaster? Or is there an environment where these failure signals are extinguished and dampened entirely?

Is there a system where everyone gets fast feedback on their work, or is there no feedback at all? I've asked Steve to teach us what we've learned together, and I trust you will find it as riveting as I do. Here's Steve.

Dr. Steve Spear

Gene, I got a question. Why? And I know in 2020, the question why is a big question about a lot of things, but let me narrow it down and package it a little bit. Gene, why do organizations exist? And you're probably going, "Oh, man, why did I bring this guy into my conference? He teaches at the MIT Sloan School of Management. Wouldn't he know why organizations exist?" And you're probably thinking to yourself, too, one, you have students paying tuition to a guy who doesn't know why organizations exist, and he's teaching about management, and duh, everyone knows the answer. Why do organizations exist?

Because someone's got to make planes, trains, and automobiles. And yes, that's true, Gene, but a little bit of foreshadowing on this. Let me tell you what's important in an organization. Gene, it's relationships. Relationships are what are so important in an organization. And I'm not talking any kind of that hanky-panky stuff. We're going to get into what I really mean by relationships here, all right? But let's come back to what you said was planes, trains, and automobiles. That's fine. Someone's got to make a plane, train, automobile, frosting for your cake, et cetera.

But let me ask you, where does that stuff come from? It's like you just go, boom, give me a plane, give me a train, give me an automobile. I don't think so, because first you got to start out figuring out who actually has a need, and that's the problem to be solved, because there's a lot of people in the world, and you got to figure out who you're going to focus on. And then when you figure out, "Oh, these are the people I'm going to focus on," you got to figure out, well, actually, what's the nature of their needs? Why do they have these concerns? And then you have to design a solution.

What do you actually need to deliver them that will deal with some more problems. And then when you have a design, it's not like at that point you give them a plane, train, automobile, or the frosting for their cake. You got to figure out how you're actually going to make and deliver the thing, whether it's a thing physically or figuratively, whatever it is, you have to figure it out. And when you solve all those problems, yes, eventually, there's the plane, the train, and the automobile. Now you might be saying, "Yeah, all right, Steve. Fine.

Yeah, you got to solve problems, but then you're really in the business of delivering planes, trains, and automobiles." Not so fast, mister, because here's the thing. Once you solve one problem, you got new problems coming back. It's just problem after problem. And you want proof of this? Mr. Walt Disney. So think about Mr. Walt Disney. What's the first problem he's trying to solve for? He's trying to give people the happiest place on Earth. And it wasn't like he reached into his pocket, pulled it out, and said, "Oh, here's the happiest place on Earth."

That took a lot of creativity to figure out what Disneyland would look like. And you could argue he actually solved that problem because people started showing up, and guess what? They showed up with their kids, and their kids are going, "I'm hungry. I want something to eat." All right, boom, new problem you got to solve. Now you got to figure out how you're going to feed all those people who are showing up at the happiest place on Earth because not exactly fully happy if they're all hungry. But now, you think about the Disney folks. They did a pretty good job, happiest place on Earth.

They're feeding you well and then people say, "Hey, honey, this is really a very happy place. But we got here in the morning, we're leaving in the evening. I'd really like to stay for a couple of days." New problem that's got to be solved. So you got to figure out the hospitality so people can have the happiest place on Earth for more than a few hours. Now, you get the happiest place on Earth with the food is good and you can stay multiple days. Guess what? It gets crowded. You got a new problem. Why am I waiting so long for everything? You got to solve that problem, too.

And our buddies at Disney, what have they done? They came up with these magic bracelets. So wherever you go, boom, exactly what you want, when you want it, when you need it is there. No waiting. It's fantastic. All right. So anyway, why do organizations exist? To solve problems so they can deliver their planes, trains, and automobiles. And oh, by the way, Gene, it never ends. It's just problem after problem. All right. Now let's take this a step further. It'd be one thing. All right, so Gene's got to solve a problem. Anne's got to solve a problem. Jess and Aaron have to solve their problems.

But it's not so simple, right? Because what's the deal with the problems? The problems are hard problems, right? And so it's not just solving problems. We got to be solving problems collaboratively. Big problems, big problems with people working on it together. Anyway, let's step back. Gene, if you think about my presentations the last couple of gatherings we've had. I talked about, a couple of times ago, the United States Navy having this come-from-behind victory against the Japanese Navy at Midway in June 1942. And we say, "Well, where did that come from?"

We say, "Well, the Navy's in the business of beating Japan in 1942." We say, "Well, yeah, but the root cause of victory in 1942 is in the 1920s and 1930s, the United States Navy defined its job not necessarily in the moment as beating Japan, but figuring out actually how to do it if it ever came to that." And the conversation we had back then was that in the '20s and the '30s, the United States Navy actually ran exercises which they called problems. Not rehearsals, not practice, not preparation, problems. Because they've got all these problems we've got to solve with thousands and tens of thousands of people.

We got to be in the business of solving problems very aggressively through the '20s, through the '30s. How to defend the Panama Canal, how to do island hopping, how to refuel at sea, how to defend and support army garrisons which are on islands throughout. How to do a beach landing. Didn't know how to do that in 1920. You had to figure it out. All these problems. Anyway, spinning this forward, if our organizations exist to solve problems and solve them collaboratively, we really got to worry about relationships because if collaboration is who works with whom about what, in what way, when?

We're in the business of working on problem-solving relationships. So how do we do that? All right. So now let's think about this. The assertion here is yes, eventually we make planes, trains, and automobiles. But before we can make a plane, a train, or an automobile, even the first one, what we have to do is take inputs into outputs. The inputs are ignorance and the outputs are understanding. Questions become answers. Problems become solutions. Confusion becomes insight, understanding. All right. Now, here's the thing. You go into most organizations.

And I'm hoping at this point, at least you're entertaining the assertion that any organization exists to solve problems. You go into most organizations, say, "Hey, what do you guys do here? What do you guys do here? Or gals, what do you all do here?" Say, "Well, we make planes, trains, and automobiles, and we actually can show you how all the pieces fit together to get a plane, to get a train, to get an automobile, to get a microprocessor." They have these beautiful pictures of how all the pieces come together. "That's great. Okay."

And then now in the back of your head, you're thinking, "Yeah, but how does the problem become a solution?" Say, "Hey, guess what? We have even more pictures. Not only do we have pictures of how the pieces come together into the plane, the train, the automobile, the frosting for the cake, and the microprocessor, we have pictures which show how the pieces take form on their way to fitting together. And we got all sorts of pictures of how the pieces take form."

And then you're sitting there, and you've looked at all these beautiful pictures, and they're so excited about their pictures, about how the pieces come together, how the pieces take form. And you say to them, "Yeah, but here's the thing. Until you got all that stuff, you have all the problems that you got to solve. Tell me, how do your ideas take form? Where do they come from?" And they're like, "What you talking about, Gene? It just happens. People come into work, they know what they're supposed to do, and this guy does this thing, that gal does that thing, and it all comes together."

Now, you might be thinking at this point, "Whoa, hold on a second. You've got all these intricate drawings for the thing you make. You've got all these intricate drawings for how those parts take form. And where's the intricate drawing for how the ideas take form?" And they don't exist. Now, why is that? Because Gene, here's what happened. Back in the day, when folks like you and Aaron and Jess and Anne were sitting around thinking, "Kind of tired of horses. We can invent the car here." And there was a lot of conversation about, "Yeah, but what's a car going to be? Three wheels versus four wheels.

What's our metaphor for a car? Is it going to be a boat? Is it going to be a carriage? If it's going to be a carriage, how are we going to power that thing instead of the horse? Internal combustion, that's obviously the one that won out. Maybe a steam engine. Maybe an electric motor." But anyway, back in the day, no one actually knew what the car would look like, and I guess the plane, the train, and the automobile too. Well, that was the automobile. But the plane and the train, along with the car.

But eventually, what came out of all that wrestling amongst you all was the emergence of a dominant architecture, an agreement about what the car would look like. And there were dominant architectures emerging on how to provide healthcare, how to make a plane, how to make a train, how to make frosting, how to make a product. A dominant architecture of the product or service. Now, here's the thing about dominant architecture. As the architecture for the product starts to take shape, as the architecture for the service starts to take shape, the architecture for the organization also starts to emerge to match.

So the organization is now, in some regards, a map of the problems that have to be solved for this thing. And so what comes out of that, as you get this organizational form to emerge to match the dominant architecture, you actually get work done. But how do you get work done? Through all these tacit processes which emerged and grew as the organization emerged and grew. Now, that's all well and good. Work gets done and work gets done, and it gets done. And it works just fine if nothing changes.

But here's the thing, stuff changes all the time, and when you have little problems or big problems, now you're kind of stuck. I'll give you an example. We were doing work a bunch of years ago with trying to get the right medication to the right patient at the right time and the right dose and the right volume, et cetera. And discovered was that pharmacy working in their silo over there, they were doing their best. Right? And they were delivering the medication in a certain way, at a certain time, certain place for nursing to pick it up.

And the nurses raised their hand and said, "You know, where you're leaving that medication, how you're leaving that medication, when you're leaving that medication, it makes our work a lot harder than it otherwise might be." Said, "Hey, let's get together and we'll solve this through formal channels." But it turned out that there was no formal channel through this emergence of a dominant architecture organizational form. There was no formal channel for moving where you put Advil or whatever the medication was.

And when they started to map through the formal channel, what turned out that the pharmacist had to go to the head of pharmacy, who had to go to the head of pharmacy in the hospital, had to go to the head of the pharmacy in the system. And on this nursing side, the nurse had to go to her unit manager, who had to go to her nurse supervisor, who had to go to the head of nursing in the hospital, who had to go to vice president of nursing for the entire system. The only place where pharmacy and nursing actually connected was at the president of the entire healthcare system.

And let me tell you what, the president of that entire system didn't really actually care where the Advil went. All right? That was part of the problem with the tacit processes. Now, here's another example. I've had some chance to do some work with shipyards. Now, here's the thing. You start building a family of ships, those ships have to be in production for decades. Decades. I mean, the Nimitz-class of carriers got started, I think, in the 1960s or something, and here we are in the 2020s, and they're just moving over to the Ford. Now, you start thinking about carrying over tacit knowledge over 20, 30...

Gene, I can't remember today what I did yesterday, and the knowledge I acquired yesterday, not only can't I carry it from myself into today, good luck conveying it to my kids. Now, to start thinking about when you have workforces of thousands of people, and you're trying to convey understanding through tacit processes over decades. Yeah, come on. Really? All right. Now we're starting to get into some of the problems here with our tacit processes. One, you have problems for which the routine processes are in tune to solve. So, pshh, all right. They go all the way up.

Or we have processes which have to tacitly be conveyed over generations and decades. Good luck with that. And here's the other thing. What if we have no routine? So, when I was writing my book, I made a contrast in terms of the growth and complexity on the one hand with the growth and competency and capability on the other, for all sorts of processes. And what I looked at was the process by which people are diagnosed and treated for breast cancer. Now, in the 1950s, the example in the book, I think chapter two, if you want to take a look.

The example in the book is that in the 1950s, the treatment of breast cancer, it actually wasn't very effective. It was brutal, it was painful, but it wasn't very effective in actually providing cure. The thing was, if you're managing that process, good news, you didn't have great competency and capability, but you had a very simple process. And the reason for that is the science and technology in the '50s wasn't very advanced. There wasn't much you could actually do.

So every patient who came through, regardless of what her condition was, the stage of the cancer, genetic predisposition, environmental triggers, et cetera. They all got the same treatment. Very, very simple process. And in the book, when we gave this example, we spun it forward 40, 50 years and said, the thing about breast cancer treatment now is the science has expanded and exploded. And while the term breast cancer is used to describe a presentation of malignancy in a particular tissue, the reality is there are many, many different types of breast cancers.

And not only are there many different types of breast cancers, depending on the patient, even if two patients have the same cancer, depending on their genetic predisposition, the environmental exposures they've had, they may get a different treatment of different radiation, different cocktails of chemistry, different timings, and severity of surgery. And so now, when you start thinking about breast cancer, great news. The survival rate is fantastic compared to the 1950s.

The problem as a process manager is now you're responsible for supervising, coordinating, getting to collaborate harmoniously, dozens and dozens of people. And whatever routine you built up for patient one, it's a different routine for patient two, and a different routine for patient three, and you may never actually use the same routine again. Now, that is a headache. All right. Now, when you have a few dozen people and they've got line of sight and they've got relationships built into it, all right, so maybe you can work it out.

But then let's think about some of the really big processes of our time and age, right? So you start thinking about things like pharmaceuticals. You think about things like electronics. We're talking processes, hundreds of people, thousands of steps, taking years to accomplish from start to finish, to turn a problem into a solution, a question into an answer. And not only that, you run that process one time as a program manager, you run that process one time as a project, and you get the next assignment, guess what? It's a different flow of work. Now, why is this a difficulty? Why is this a problem?

Well, for the person responsible for the program and the person responsible for the project-- Remember we were talking about our pictures. We got these intricate pictures of how the pieces get together. We have these intricate pictures of how the pieces take form, but we don't have an intricate picture of how the ideas take form, how we go from problem to solution, from confusion to understanding. Well, if we don't have an intricate picture of that, then the actual work is hidden. It's hidden from the person who's actually responsible for managing that whole set of collaborations. They don't know what's going on.

And when something does go wrong, when do they find out? Not when it's containable, not when it's manageable. It's, boom, when it hits them in the face. And so you start thinking about this irony, right? Who gets to manage a big industrial, high-tech, engineering, scientific, intensive process? Someone who's really smart and accomplished. And what do you ask them to do when they get to that point? Firefight, expedite. "Hey, oh, we got a problem here. Let me grab you from doing this and let me put you over there. Let me grab you from over here. Oh, go take care of this.

Oh, let me make a couple of phone calls on your behalf." So the compliment for being so accomplished is this freaking nightmare of Whac-A-Mole on a process which spans out over many years, thousands of steps, and dozens, if not hundreds, of people. All right, that's the person who's looking down and can't see. What about the person who's inside looking up? They can't see either. They can't see either because no one's bothered to tell them and help map out where they fit. So what are they doing every day? They have arbitrary inputs becoming arbitrary outputs subject to arbitrary metrics of performance.

And they do their best, right? Because they don't know exactly where the stuff is coming from, so they have to do some rework when it arrives. And they don't know where the stuff goes, so they hand it off as best as they can. And then someone comes and yells at them, "Oh, you did the wrong thing in the wrong way." And it's like, well, how the heck was I even supposed to know? All right. So anyway. Take a deep breath. All right. There is a solution to this situation. So what's the solution? All right.

With the same sort of scientific, technological, engineering discipline by which we go through and try to map out the architecture and the relationship, the technological relationships within the products we make. And just as we go through trying to map out the architecture and the relationships, the technological relationships of the processes by which the things we make take form, what we really need to do is start thinking about the connectivity, the relationships. Who does what work on behalf of whom within our organizations? Now, why would we do that?

Well, if we do that, Anne, you do something on behalf of Erin. Erin, you do something on behalf of Jess. Jess, you do something on behalf of Gene. Gene, on behalf of Steve. Steve, on behalf of Anne, right? If we start mapping it out, we can actually have this intricate representation of the process so the individual knows where they fit and the person, the program, the project manager can see the whole thing. And not only see the whole thing, but understand when it starts to misbehave. Now, that is a huge advantage. All right? Now let's think about this. All right. We can see problems, no hidden factory.

So how do we summarize this point? Is that the structures we create drive the dynamics of the thing we've created. And certainly, you can appreciate, you connect two things in a physical system, two things in an informational system. In one way, the system will behave in one fashion. Connect them in a different way, the system will behave in a different fashion. Well, same thing true is when you start talking about making these relationship connections amongst people. And so, what ends up happening if we connect the wrong people in the wrong way, what do we get? More problems.

And look, don't just take my word for it, right? Because David and Jess talked about the wisdom inside "Team of Teams." And if you start thinking about the basic problem that they're describing, the problem in the beginning of the book, you've got all these wildly skilled people. Wildly skilled people, highly motivated, incredibly well equipped with the best science, best technology, best equipment. And they're getting beaten by people who have horrible motivations, horrible incentives. They're way less well-equipped, less well-trained. And what did David and Jess explain to us?

Which is the problem wasn't the equipment, the problem wasn't the people, it was the connectivity. That the wrong people were talking to the wrong other people about the wrong things at the wrong time. And what's the point about the "Team of Teams" thing? It's trying to help these things mesh and get the relationships right so the right people are talking to the right people in the right way. And anyway, if we can do that, if we can deliberately go out of our way to create that mapping of who should be talking to whom, one, we way increase our chance of succeeding on the first pass.

And the other thing is we make it way easier to see problems when and where they're occurring, so we can actually make the system for which we're responsible a better system. So anyway, what's the suggestion here? Is take kind of that scientific, technological, engineering discipline that we are so enthusiastic, energetic, committed to for the design of stuff and apply it to our own organizations. So our own organizations are subject to or allowing of the same sort of creative problem-solving on improving the organizational enterprise processes as the thing we're trying to construct. Gene?

One final thought before we say goodbye. That was a lot of material. Went through it very fast, and it was highly compact. And so what message do we want to leave folks with? Well, the big one, that enterprises exist to solve problems, because in the solving of problems, they discover ways to deliver value to society that's more and more appreciated. The key is speed, right? Because the faster they solve problems, the more value they can create and deliver earlier.

And look, ordinarily, under normal circumstances, we'd say, "Oh, look at this industry, look at that industry, da da, look here and look there," as to the added value of the millions of dollars per day to get a drug into the market earlier. The millions or tens of millions of dollars to be first versus second into a marketplace. But think of the environment we're living in right now, where what would be the societal value of a vaccine or a test that's reliable and fast a day early, a week early, a month early? It's staggering. Anyway, let's leave this key point.

Speed is of the essence, and what is the value we're creating by making explicit these enterprise processes, making explicit where there is difficulty? What we're trying to do is give time back to people so they can be productive in creating value. And it could be that program manager, could be that project manager sitting way up there trying to fight through the haze of the hidden factory, trying to figure out what they can do that's useful for someone else. Well, this will make it clear what's useful to someone else. They can remove obstacles. They can remove logjams.

They can remove impediments and barriers and all that sort of thing. And for the person who's embedded in the system, think about the clarity this gives them so they're not just processing things coming into an inbox and putting things into an outbox and wondering where it goes and who cares, but actually having clarity about who they're dependent on and building that relationship and who depends on them so they can build that relationship, too. So gee, after all this punching through all these different slides, it's about problem-solving at speed, so people can do things more valuable for others.

And man, think about the era we're living in right now, just how important achieving that would be. All right. Thank you. Sorry, let me just end with a thanks and take advantage of an offer the IT Revolution folks always make, which is to say, look, thanks for having me on and being able to share what I've learned. But more important than sharing what I've learned is to ask for feedback.

So if you've got any questions about what I've been talking about, any objections, any corrections, any things you want to insert or say take out, look, we got the Slack, we got the email, we got the Ask Me form during the conference, so pop into that. And the other one is that I just want to make a selfish request, is that some of the stuff we've been talking about in creating tools so that if you've got this huge, sprawling enterprise process, you can visualize it to increase the chance of success, so you can see problems real time, so you can contain problems before they spread.

We're working on some tools which we've been testing out in practice, some pilots, some beta tests, with some really exciting results. And what we're looking for is for other folks who want to partner with us around creating and deploying tools that help change behavior in this very, very favorable direction. So anyway, thanks for the opportunity to speak to you in this fashion, and I hope this was useful in some fashion to you. I certainly look forward to hearing back from you what you liked, what you disliked, what we need to change for the next try.

But until we have that next conversation, for now, it's over and out, and thank you very much.