Las Vegas 2020
Why Do Organizations Exist and Struggle To Do What They Need To Do?
Join Dr. Steve Spear, author of, "The High Velocity Edge."
DS
Dr. Steve Spear
DBA MS MS, Author, The High Velocity Edge, Senior Lecturer, MIT, Principal, See to Solve LLC, Author,
Transcript
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 and Whitney to the building of the safety culture at Alcoa and how 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? Uh, or is there no feedback at all? I've asked Steve to teach us what we learned together and I trust you will find it as riveting as I do. Here's Steve
Jean. 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. Jean, why don't organizations exist? And you're probably gone, 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. It's like 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 don't organizations exist because someone's got to make planes, trains, and automobiles. And yet, yes, that's true gene, but a little bit of foreshadowing on this. Let me tell you what's important in an organization, Jane it's relationships, relationships are what are so important in an organization.
And then I talk in any kind of that hanky panky stuff. We're going to win and get into what I really mean by relationships here. All right. But let, let let's come back to what you said was a planes, trains and automobiles. That's fine. Right? Someone's got to make a plane, train automobile, a frosting for your cake, et cetera, et cetera. But let me ask you, where does that stuff come from? It's like, you just go, boom, boom, boom, 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 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. You know, what do you actually 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 gonna make and deliver that 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, Hey, all right, fine, fine, fine. Yeah, you got to solve problems. But then, you know, you're really in the business of delivering planes, trains and automobiles, not so fast, Mr.
Because here's the thing. Once you solve one problem, you got new problems coming back. It's just problem after problem after problem. And you want proof of this, Mr. Walt Disney. So thinking about Mr. Wall Disney, right? What's the first problem he's trying to solve for it. He's trying to get people the happiest place on earth. And it wasn't like he pulled the reach into his pocket, pulled out, said, oh, here's the happiest place on earth that took a lot of creativity to figure out what Disneyland would work look like. And, um, you could argue, he actually solved that problem because people started showing up and guess what? They showed up with their kids and they're getting and going, I'm hungry, I'm hungry. I want something to eat. All right. Boom, new problem. You gotta solve. Now you got to figure out how you're going to feed all those people showing up at the happiest place on earth.
Cause not exactly fully happy if they're all hungry. But then you think about the Disney folks. They did a pretty good job, happiest place on earth to feed in your well and have people say, Hey honey, you know, you know, this is really a very happy place, but you know, 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 gotta be solved. You got to figure out the hospitality so people can have the happiest place on earth for more than more than a few hours. Now you get the happiest place on earth with the food is good and 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. When our buddies at Disney, what have they done?
They came up with his magic bracelet. So wherever you go, boom, exactly what you want when you want it, when you need it. Is there no waiting? It's fantastic. It's fantastic. All right. So anyway, why do organizations exist to solve problems so they can deliver their planes, trains and automobiles and hope hive a way Jane. It never ends. It's just prom after problem after problem after problem. All right, now let's take this a step further if you want thing. All right. So Jean's got to solve a problem and has got to solve a problem. Jess and Aaron have to solve their problems, but it's not so simple, right? Cause what's the deal with the problems, the prompts, a hard problems, right? And so it's not just solving problems. We gotta be solving problems, collaboratively, big problems, big problems with people working on it together. Anyway, let's step back.
Tina, if you think about, um, my presentations, the last couple of, uh, gatherings we've had, right? I talked about couple of times ago, the United States Navy having this, uh, come from behind victory against the Japanese Navy had midway in June, 1942. And we say, well, where did that come from? We say, well, you know, the Navy is in the business of, uh, beating Japan in, in 1942. We said, well, yeah, but the root, the root and I guess the root cause 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 meeting Japan, but figuring out actually how to do it. If it ever came to that. And you know, the conversation we had back then was that in the twenties, in the thirties, the United States Navy actually ran exercises, which they called problems.
Not rehearsals, not practice, not preparation problems, because if they're got all these problems, we've got to solve with thousands. And tens of thousands of people got to, we got to be in the business of solving problems, very aggressively through the twenties, through the thirties, how did defend the Panama canal? How to do island hopping, how to root fuel. Let's see. How did the defendant's support army garrisons withdrawn Island's threat all the how to do a beach landing. Didn't know how to do that in 1920, he had to figure it out, right? All these prompts anyway, spinning this forward. If our organizations exist to solve problems and solve them collaboratively. Yeah, 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. 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, all 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. Here's the thing you go into most organizations. All right. And I'm hoping at this point, it let you 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? Gals? What do you guys all do here? Say, well, you know, we made 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 them on microprocessor, beautiful pictures, beautiful pictures of how all the pieces come together.
And that's great. That's great. Uh, okay. And then now in the back of your head, you're thinking, yeah, but how does the, uh, the problem become a solution? Hey, guess what? We have more pictures, 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 of these beautiful patient. They're so excited about their pictures, about how the pieces come together, how the piece of steak form is saying to them. Yeah. But here's the thing until you got all that stuff, you have all the problems that you gotta solve.
Tell me how do your ideas take form? Where do they come from? And they're like, oh, what are you talking about? What'd you talking about Jean? Is it, is it, it just happens. It just happens. You know, people come into work, they know what they're supposed to do. And you know, this guy does this thing, that guy gal does that thing. And it all comes together that 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 things, those parts take form. 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, back in the day, when folks like you and Aaron and Jess and Dan were sitting around thinking, you know, kind of tired of horses, we can invent the car here.
And there's a lot of conversations about it. Yeah. But what's the car going to be, you know, three wheels versus four wheels. What's our metaphor for our cars is going to be a boat. It's going to be a carriage. 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 one out, maybe a steam engine, uh, 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 to right. Well, that was the automobile, but you know, the plane and the train along with the car, but eventually, eventually what came out of all that wrestling amongst you all was the emergence of a dominant architecture and agreement about what the car would look like.
And then with 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 merge 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 tool emerge to match the dominant architecture, you actually get work done, but how do you get work done through all these tasks and processes, which emerged and grew as the organization immersion and grew now, um, that's all well and good, you know, work gets done and work gets done and it gets done.
And, uh, you know, it works just fine if nothing changes, if nothing changes, but, uh, here's the thing, stuff changes all the time. And when you have little problems or big problems, now you kind of stuck, okay, I'll give you an example. We were doing work a bunch of years ago, uh, with, um, trying to get the right medication to the right patient at the right time and the right dose and the right volume, et cetera, et cetera, et cetera. And, uh, discovered was that pharmacy working in their silo over there, um, was, and 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 said, you know, where are you 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.
So, Hey, let's get together and we'll solve this through formal channels, but 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 out a pill or whatever the medication was. And when they started to map through the formal channel, well, it turned out that the pharmacist had to go to the head of pharmacy who had to go to the head of pharmacy. And the hospital had to go to the head of the pharmacy in the hub, in the system. And on this nursing side, the nurse had to go to her unit manager, had to go to our nurse. Supervisor, had to go to the head of nursing in the hospital, had to go to vice-president of nursing for the entire system. The only place where pharmacy and nursing actually connected, was it the president of the entire health care system.
And let me tell you what the pressure of that entire system didn't really actually care where the Advil went. All right. That, that was part of the problem with the tasks and processes. Then here's another example, another example, um, I've had some chance to do some work with, uh, you know, shipyards. Now here's the thing you started building a, a family of ships. Those ships have to be in production for decades, decades. I mean, the Nimitz of Carrie's got started, I think in the 1960s or something. And here we are in the 2020s and they just move it over to the Ford. Then you start thinking about carrying over tacit knowledge over, you know, 20, 30 gene. I can't remember it today. What I did yesterday and the knowledge I acquired yesterday, not only can I carry it from myself into today, good luck conveying it to my kids.
Now start thinking about when you have workforces that thousands of people you're trying to convey, understanding, um, through tacit processes over decades yet. Come on. Really? All right now. All right. So now, now we're starting to get into some of the problems here with our tacit processes. One, you have prompts for which the routine processes aren't tuned to solve. So, you know, all right, they go all the way up, or we have a processes which have to tacitly be conveyed over, um, uh, generations and decades. Good luck with that. And here's the other thing. What if we have no routine, what if we have no routine? So, you know, I was, uh, when I was writing my book, I made a contrast in terms of the growth and complexity on the one hand with the growth in competency and capability on the other for all sorts of processes.
And when 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 and the chapter two, if you want to take a look, the example in the book is that in the 1950s, uh, the treatment breast cancer, it actually wasn't very effective. I mean, I mean, it was brutal. It was painful. Um, but it wasn't very effective and actually providing cure. Um, the thing was, if you're managing that process, good news, uh, you didn't have great competency and capability, but you had a very simple process. And the reason for that is the reason for that is the science and technology in the fifties was, um, such wasn't very advanced. There wasn't much you can 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, et cetera, they all got the same treatment, very, very simple process, you know, and in the book when we gave this example, we, you know, we spun it forward, uh, you know, 40, 50 years and said, um, the thing about breast cancer treatment now is the sciences is expanded and exploded.
And while the term breast cancer is used to describe, uh, uh, presentation of malignancy in a particular tissue, the, uh, the reality is there are many, many different types of breast cancers and not only are many different types of breast cancers, um, 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, great news, the survival rates, fantastic. Compared to the 1950s, the problem as a process manager promise 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 to and different routine for patient three.
Or you may never actually use the same routine. Again. 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 there, all right. So maybe co-work it out. Right. And then let's think about some of the, the really big processes are a time and age, right? So you start thinking about things like pharmaceuticals. You think about things like, uh, uh, electronics, um, we're, we're talking processes, we're talking to processes, hundreds people, thousands of steps, taking years to accomplish from start to finish, to turn of promise through a solution, a question into an answer. Um, and, uh, 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, w w why is this a diff 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 pic 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, 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 collaboration. 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 mad, let's boom, when it hits them in the face. And so you start thinking about this irony, right? Who gets to manage, who gets to manage a big industrial high tech, engineering, scientific, intensive process.
Someone who's really smart and accomplished and what he asked them to do when they get to that point. Firefight expedite, Hey, oh, we got a problem on here. Let me grab you from doing this. And let me put you over there. Let me grab you from OVO. Go deal, 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 whack-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 is looking down and can see what about the person is 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.
I'll put subject to arbitrary metrics of performance and, you know, and they do their best, right? Because they don't know exactly where this stuff is coming from. So they have to do some rework when it arrives and they know where this stuff goes. So they hand it off as best as they can. And then someone comes in yelling, oh, you did the wrong thing in the wrong way. It's like, well, how the heck was I even supposed to know? All right. So anyway, anyway, hope again. Take a deep breath, take a deep breath. All right. There is a solution to the situation. So what's the solution. 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, uh, relationships, the technological relationships of the processes, by which things we make, take form, we really need to do is start thinking about the connectivity, the relationships, the relationships who does, what work on behalf of whom within our organizations.
Now, why would we do that? Well, you know, if we do that, you know, and you do something on behalf of Aaron, Aaron, you do something on behalf of Jeff jet, Jess, Jess, you do something on behalf of Jean, Jean on behalf of Steve, Steve, on behalf of that, right? If we start mapping it out, we can actually have this intricate representation of the process. So the individual knows where they fit in the person, the program, the project manager can see the whole thing and not only see the whole thing, but understand when to start in the misbehave. Now that is a huge, huge advantage. All right, now let's think about this. Let's think about this. All right. We can see problems, no hidden in factoring. Um, 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 to things in a physical system, to 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? Cause, uh, David, and just talked about the wisdom inside a team of teams. And we start thinking about the basic problem that they're describing it, the, the, 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 way less well-trained. And you know, what did David and Jessica explained to us, which is the problem? Wasn't the equipment, the problem wasn't the people was the connectivity that the wrong people were talking to the wrong people, wrong other people about the wrong things at the wrong time. And what's the point about the team of teams. Thing is trying to help these things mesh and get the relationships, right? So the right people talking to the right people in the right way. And anyway, if we can do that, if we can, um, deliberately go out of our way to create that mapping of who should be talking to him, one, 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 is the, what's the, uh, suggestion here is take kind of that scientific technological engineering discipline that we are so enthusiastic, energetic, committed to design a stuff and apply it to our own organization. So our own organizations are subject to are allowing up the same sort of creative problem solving. I mean, on improving the organizationally enterprise processes as the thing we're trying to construct Jean one final thought before we, 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, 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, um, the faster they solve problems, the more value they can create, they can create and deliver earlier and look ordinarily under normal circumstances, we would say, oh, look at this industry. Look at that industry that I look here and look there, um, as to the added value of, you know, the millions of dollars per day to get a drug into the market earlier, uh, the, uh, the millions or tens of millions of dollars to be first versus second to marketplace, but then in the environment we're living in right now, where what would be the societal value of a, of a vaccine or a test that's reliable and fast a day early, a week, early, a month early it's it's like, 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's 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 factor, 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. Um, they can remove obstacles. They can move logjams, it can remove impediments and barriers and all that sort of thing. And for the person who is 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 Gina, after all is punching through all these different slides, it's about problem solving at speed. So people didn't do things more valuable for others. And man, you know, think about the era we're living in right now. Just how important achieving that would be. All right. Thank you. Sorry, let me, let, let me just end with a thanks and take advantage of an offer. Um, the it revolution folks always make, which is to say, look, thanks for having me on and be able to, uh, share what I've learned, but more, more important than sharing. What I've learned, um, is to ask for feedback. So if you've got any questions about what I've been talking about, any objections, any corrections, any, um, any things you want to insert to say, take out, well, we got the slack, we got the email, we got the ask me form during the conference.
So a pop into that. And the other one is I just want to make a selfish request, is that, um, 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 prawns before they spread. Um, we're working on some tools, which you've been testing out in practice, some pilots and beta tests with some really exciting results. And what we're looking for is, uh, for, uh, 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, uh, thanks for the opportunity to speak to you, uh, in this fashion. And, um, you know, I hope this was useful in some fashion to you. I certainly look forward to hearing back from you, uh, what you liked, what you disliked, what we need to change for the next try, but, uh, until we have that next conversation for now, it's over and out and thank you very much.