#317 How to Reengineer Your Business Processes with Nelson Repenning, Distinguished Professor at MIT Sloan & Don Kieffer, Senior Lecturer in Operations Management at MIT Sloan

Generative AI is transforming industries at an unprecedented pace. But as AI changes how you or your team work, one thing is clear. Your skills also need to evolve. At datacamp, we offer everything you or your team need to adapt and thrive with AI. Whether it's business users looking to get the Most out of ChatGPT and Copilot, or developers and data scientists looking to fine tune models, you can learn the entire AI skills spectrum on Datacamp. Power your AI transformation today. Start learning@datacamp.com.

So all those little problems just keep getting bigger and louder until someone says, okay, stop. Let's actually fix one. We want work to be satisfying. Work is hard. This is not about hand holding and smiling faces. This is about I worked hard, it was tough. But when I go home I feel like I got something done, I contributed, I learned something.

The system is managing you rather than you're managing it right. You walk in with big plans and then immediately you get sort of sucked into the day to day firefighting and whack a mole and so on and so forth. Typically what happens is when people try to confront that, they try to put in more rules, more control, more oversight, more forms to fill out. But actually at least our view is that when you make those interventions, it actually tends to make the problem worse rather than better.

Welcome to Data Framed. This is Richie. In 2018 I produced a course on process analytics in R. It's one of my favorite courses that nobody took a critically acclaimed flop. The problem is that most organizations don't pay as much attention to optimizing their processes as they ought to. Much of the benefit of trying to become AI first is less about the tech and more about paying attention to what your processes are. Process re engineering is a rich discipline and there are a few frameworks for it. Today we'll learn about dynamic work design. A set of principles was born from the frustrations of existing frameworks like the Toyota way. Not working well when you have a changing work environment. Our guests are the co creators of Dynamic Work Design. Donald Kiefer was VP of Operational Excellence at Harley Davidson back in the 90s where he was tasked with solving manufacturing and shipping delays. He teamed up with Nelson Reppening, a professor of Management science and Organizational Studies at MIT Sloan. Together they devised a new system. Thirty years later, Donald also works at MIT Sloan. Their dynamic Work Design system has been put into practice at countless organizations and they also have a book on the subject called There's Got to Be a Better Way. So let's find out how to improve our Processes. Hi, Nelson. Hi, Don. Welcome to the show.

Hi, Rich. Thanks for having us.

Yeah, thanks for having us. Glad to be here.

Cool.

So, to be honest, I've got a problem that I'd like you to help me with. So quite often on the way to work, I've got a plan of things I want to do and as soon as I get in, I check my messages, everything goes sideways and I spend the whole day trying to put out fires. So can you just tell me why do I spend so much of my day firefighting?

Yeah, so I could start with that. Adan will, I'm sure, chime in. That's a very common problem. That's the reason we really wrote the book. It's exactly that issue, I think, motivates most of the work that we do. And the kind of catchphrase we use to describe it is the system is managing you rather than you're managing it, right? You walk in with big plans and then immediately you get sort of sucked into the day to day firefighting and whack a mole and so on and so forth. And I think the reason it happens ultimately, to sort of use the jargon a little bit from our book, is typically what happens is when people try to confront that, they try to put in more rules, more control, more oversight, more forms to fill out because it feels like they're out of control. So it's a very natural instinct. But actually, at least our view is that when you make those interventions, it actually tends to make the problem worse rather than better. And the reason is the root of that problem is that your organization and your life is probably very dynamic, but you're trying to solve it with static interventions, right? So you're trying to control a system that's moving very quickly by making it move slowly, which just creates more of that chaos and more of those little need for workarounds. And so the way to go after that with dynamic tools basically boils down to both what we call the approach and the principles of dynamic work design, which our framework can probably go into the principles, but the approach basically is look at your calendar or look at all the things that get in the way during the day and start picking off what is the biggest thing that interrupts your day, right? What's the biggest problem that causes you to get distracted from your plans and dig into why that happens and understand the real work and see if you can make that problem work better. And incrementally. What you will find is as you start solving the problems in your organization, the chaos will start to calm, and you'll start to experience more stability. And that really is the essence of kind of our approach to solving these problems.

Yeah. If you're ever in a meeting, Richie, and, like, everyone starts talking at once because it's, I don't know, some kind of big problem. And, like, so no one knows. Everyone's talking to one. So there's no real movement in the conversation. And finally someone says, hey, hold on a minute. What do we try to do here? Let's go one at a time. And essentially, that's what's happening to you at work is like, everyone talking is like, all these issues are just like pecking at your ankles and you can't concentrate. And the trick is, as Nelson says, the reason is, of course, as he said, you're using the wrong type of solutions to fix things. But those issues just keep getting worse and worse. And so you have to stop. Like, okay, let's fix one thing and get it out of the way while you're fighting off all the demons. But that's the cause of it. So all those little problems just keep getting bigger and louder until someone says, okay, stop. Let's actually fix one.

It sounds so simple. Just, like, find out what your problems are and fix them. So I'm sure, actually it's not.

The idea is pretty easy. Actually, doing it is very hard.

I find it very interesting, the idea that when things are chaotic, the instinct is often to create more processes, make things more rigid. But actually, that might be counterproductive. All right, so I need some motivation. Do you have any examples from businesses that you've worked with where they've managed to turn things around and gone from a chaotic atmosphere to something where people are happy and productive? Maybe. Don, do you want to go first this time?

Yeah, I'm not sure happy is the right word. We want work to be satisfying. Work is hard. So this is not about hand holding and smiling faces. This is about, I worked hard, it was tough. But when I go home, I feel like I got something done, I contributed, I learned something. So. So that's what it's about. I think the. The big example in the book is the Broad Institute, where they're taking tens of thousands of little DNA samples and turning it into data for research purposes. And the lab is flooded with. It's just flooded with samples. And because it's flooded, it takes a long, longer time for one sample to get done. So when it takes longer, the customers start complaining. And when the customers start complaining, they call the bosses and say, hey, what about mine? So now we get top down priorities. So they spend half their day looking for the one the boss wants to run and then everything slows down more. So once they did some of the tricks that we have, not only did they catch up, but they started asking the researchers who were previously beating the hell out of them to like, where's my data? They turned around and said to the researchers, hey, can you send us some more data? Because we're caught up and we're were now looking for more. So they totally turned the thing around. When I got there was people running around material all over the place. Two years later you walk in, it doesn't even look like anyone's working yet. They're doing 10 times more work and they're out pressing the market to pull work in. So we've got several examples like that. Nelson's got one from the oil industry about maintenance orders. But it's so typical for that turnaround to happen where we get work flowing and all of a sudden the backlog is gone and now we're out like looking for new work.

Yeah. And just to compliment that, Richie, to give you a very sort of micro example, one of the things that I think makes Don and I chuckle a little bit is I don't think we could tell you how many times when we dig into the work and why your day is chaotic. Somewhere in there we find a bulky printer that doesn't work very well. That is the root cause of the problems. And you know, an extreme example, as Dom was alluding to, when you do work offshore, like on a big oil platform, everything is 10 times more expensive than onshore because you got helicopters and boats and so on and so forth. And in many companies they have enormously complicated processes to try to make sure that the work is scheduled. And you do it exactly the minute that you're supposed to do it. And they put in all these rules and oversight and they create this really constraining system. And yet when you dig into the work, it turns out that some poor technician is trying to print work orders off every day on a 20 year old dot matrix printer that they gotta bang on the side to make it work and jiggle the plug and so on and so forth. And yet I think because senior executives are often so disconnected from the work, in this case literally because it's hundreds of miles out in the ocean and so on and so forth. Right. They tend to assume that, well, it must be those guys out on their rig or screwing up rather than, you know, someone didn't feel empowered to spend $600 on a new laser printer or something like that. And it's an extreme example. I think, you know, that's why it's a lesser. But we see that happen over and over and over again, that people are just disconnected from how the work is really done in their organization. And then all the problems kind of bloom out of that in some sense.

And the unbelievable change in morale of the people at whatever level who are finally able to just do the work they're trained to do, be it maintenance or research or finance, whatever, without all this kind of crushing bureaucracy and stop this, start this. They can just like actually do their work and see the numbers posted to be successful. That's what gets people engaged. They're actually part of it and they feel like they're doing something.

I like the idea that as well as improving productivity, you're also going to improve morale as well, because people don't feel crushed. They feel more empowered and just have a better time at work. Okay. And I also like, Nelson, your idea that quite often it's not a big problem that's causing things. It's like it's a knackered old printer that's just slowing everything down and that turns out to be the bottleneck. I'd love to try and quantify like what the benefits are. So, Don, I think you mentioned that at the Broad Institute they got like a 10 times productivity improvement from sorting out their processes. Is that typical or is that just like a freak?

Best case, theirs is on the high end because the technology was moving so fast, you know, faster than the computing, Moore's Law, they, they were order of magnitude faster than that. But it was a combination of the technology changing and then all the human systems inside. So that is kind of a, a freak thing. But we tell people when they first start, if you scope this right and approach it right, you should get 30% improvement right away. Now, usually the scope is small, but when they can see what's happening and fix it in that 30%, then it's a matter of like, hey, I boiled water 30% faster. Now I need to boil the river. So now just have to think about, I know how it works. Now I have to think about how do I take it to scale. But the learning is really fast and we typically see at least 30%. It's not infrequent to see double and triple output when we get these systems unclogged and the work moving.

I would just add to that. Richie, as the academic member of this team in our early interventions, when I would see some of the gains, I'd be kind of scratching my head like, this just can't be real. But I a think it's real because we've now seen it enough times. And so two and three fold, particularly for kind of complicated R and D processes, is not unusual. And I've really thought hard about why. And I think it goes back to the question you asked us in the opener, which is, you know, when you live in the world where, you know, the system is managing you, I think we've become sort of so accustomed to that that we don't really appreciate how costly working that way actually is. There was a paper I read recently that said, you know, we spend a couple hours a week switching between apps on our ph, just switching, not using them. And, you know, I don't know if it's two hours or three hours or whatever, but, you know, imagine that environment that you describe where every 30 minutes you're switching from one task to the next because the boss calls you and I need something done. I think we just burn many more resources than we think. And as Don said, when you say, like, okay, here's a project, just get it done and you, you know, Mr. Or Mrs. Professional could work on it uninterrupted. People are happier and the productivity goes up dramatically because you don't have all those kind of random interruptions. So the gains tend to be quite big, actually.

And the thing about in the office area, knowledge work, it's so easy to interrupt people and do things you think you're helping because you're getting stuff done faster. But imagine if you asked a pilot to like, oh, can you go serve the coffee in the back of the plane while he's landing the plane? Or stop a surgeon in the middle of surgery, say, oh, can you go down here and fix my cousin's little broken leg? You would never do that because you understand that deep problems and not only quality problems, but the productivity is lost when you ask people to switch like that. But we do that to intellectual workers all the time. Hey, Richie, did you mind going to this meeting from here? Can you give me this report and then, oh, can you work on this instead of that? We do that all the time. And that loss of productivity is hidden. It's the hidden thing when we say to people, well, don't start so much work. Focus on one thing at a time. They go, well, that's going to make us go slower. But they don't realize the increased productivity. They're going to get in the entire system by getting stuff moving, by focusing on it.

I do kind of like this idea that if I just ignore a lot of my colleagues requests, I'm going to be more productive. It sounds like the dream there. All right, so one of the reasons I feel like this conversation is so timely is just over the last few months we've had a lot of CEOs declaring their company to be AI first. And they're trying to like, stuff AI into every single process. And I keep going backwards and forwards on whether this is a good idea or not. If you say, okay, we're going to automate all our process, we're going to stuff AI into everything, is that a good idea? Is that, where should we start? Or should you be doing something else?

So I would say to that, you know, and I work at mit, so you know, you can't walk two feet in any building on campus without seeing machine learning and AI. I mean, obviously it's, and there's no question it's going to change our lives very radically. I think my view of this is we're going to have an AI backlash precisely because some people are doing this. The strategy you described, which is we're just going to do everything with AI, we're going to get rid of all the people in the manufacturing world. We've been through this before. You know, in the late 80s and early 90s there was a big move towards automation and robots and so on and so forth. And I think the people who did it poorly tried to create in one step a kind of lights out factory.

Right.

We're going to kind of redesign everything from scratch. And there's some famous cases where people basically never got the factory turned on, let alone get it to sort of to work. Whereas I think the smarter people, you know, and I put Toyota in this category, they understood the work and they started putting automation in where it made sense. Like, you know, maybe this job is dangerous or we just can't get the level of precision from a human operator. Now today there are lights out factories that I think run very well, but they've been built incrementally over time from really understanding the work. And I think that's a much more sustainable strategy. And so, you know, the guidance I give people here is understand the work and then put AI in the places where it really makes a difference and proceed incrementally. Because I think the reason the kind of one shot strategy, strategy probably doesn't work is that for most complex processes there's no single person that really understands everything about how that works and all the little accommodations people to make that do. And so to try to design it from scratch on a whiteboard, I just think is beyond our cognitive capabilities at this moment. And so proceeding incrementally, you know, when you make the little interventions, you learn a little, oh, it works here, it doesn't work there. I think that's going to be a much more sustainable strategy. So I predict a little bit of a pendulum swing back. But of course, you know, in the long run, AI will have a big role. The question is, what's the most successful way to implement it with the fewest. There's sort of pain and suffering that goes with it.

Okay, I do like that. Focus on, just understand what you're trying to achieve first and have a good think about is a actually a good idea or not and do things incrementally. Don, you wanted to add to that?

Yeah, I think from a dynamic work design point of view, we see there are two kinds of work people do, two ways they work together. One is a handoff, which is the input and output. If I'm giving work to you, it's well known, you know what to expect. We don't need to talk about it like you getting a paycheck. You know, you work and you get a paycheck. We don't need to have a meeting to talk about your paycheck. It's a regular thing. But if there's a problem, we do need to talk. So that's called a handoff and a huddle. So if you think about when you call an automated helpline and, or even a person who's reading off a script on a customer service line and they're reading off a script, but your problem doesn't fit the script, you just get totally frustrated. And this is the problem about getting ahead of, of the work with the automation. Even on assembly lines, people think they know the work, they know what's supposed to happen. But there's been some little problems and the person that's been doing that work makes these little tiny tweaks all the time because of the variation. The automation doesn't know that. So when they put in the automation without solving that variation first, automation crashes. So it's not just know the work, but you have to know the details. Be so routine, AI only knows what you feed it. It's much better than other automation. It's going to move much faster and be more helpful. But when people cross the line and get ahead of knowing what's going on and venturing into like when there's a problem or a decision to be made and we need actual people to talk when they get into that space, there's going to be trouble.

Okay. Yeah. It's interesting how I guess it's so common to have an official written process and then the actual process is completely different to that.

Yeah.

Okay. All right, so in terms of how you go about improving your processes, I know your book contains, it's a five step framework. Can you give us a quick overview of what the five steps are and then maybe we'll get into more detail.

Well, it's not really five steps, it's five principles and we use it more of a diagnostic. The steps are really in the approach which is start small, blah, blah, blah. But the five ideas are one, solve the right problem and solve it the right way. Two, just don't just do the work, structure the work for discovery. So as we do the work, we're actually solving problems and learning more and more and we're combining intervention innovation with doing the work. The third one is make sure the work is designed well. Move. And the idea of dynamic work design is that people are the nodes. Work moves from person to person to person, even intellectual work. So it's not computer system or departments. It moves from Richie to Don to Nelson. So we want to make sure those links are clear and then also the links for the management chain to intervene when there's a problem at those equipment. Who do I call when there's help? The fourth idea is regulate for flow, which is this idea of you put too many cars on the highway, the highway is going to stop. So most systems are just overloaded for work with work which just slows everything down. And the, and the fifth one is especially with the intellectual work, if we can visualize the work itself instead of just tell stories about it, then we can see where it's backed up or see where there's a problem. And we're much more likely to work together to solve that problem quickly rather than sit around our meeting talk about these wild theories. Nelson, you want to add to that.

Just the one thing I would add to that is we very deliberately chose the label principles rather than practices. And the reason for that is in my early academic research, one of the things I studied a lot was when organizations failed when they tried to implement a new tool set. So when I was a PhD student, it was the quality related tools from the Asian manufacturers were a big deal and I've studied ever since. But I think one of the Reasons that people struggled so much is they would focus on the practices like, okay, Toyota has lines on the floor, or they do calisthenics before they start the line in the morning. And so we should have lines on the floor in calisthenics. But it would lead to this kind of symbolic, ritual version of it without really understanding the why. And it turns out that you have to often modify these practices. Much of the energy industry in the US Is on one highway in Houston. And so you have companies that are across the street from each other. And yet if you take a practice from one company and try to put it down in another without modification, they're going to reject it like a foreign organ. So what's the trick? How do I learn from another organization? And the trick, of course, is to understand why that practice works, to get to the essence. And so that's why we use the label principles. And so, as Don said, we have lots of tips and tricks throughout the book to make this stuff work. But I always tell our students, you're going to have to make some modifications so that it fits your organization, and as long as it respects the underlying principle, you know, you're going to be in good shape. And, you know, and I learned this lesson very early from Don. When they were doing lean production at Harley, one of the things they did is they took all the Japanese words and they replaced it with sort of plain spoken American words, which, for their unionized environment and competitive context at the time, was a really good move in order to, you know, make sure that the tools got adopted successfully. A lot of times the modifications are more sophisticated, but understanding the why, at least we believe, is really critical to bringing new stuff into your organization successfully.

For example, it's so funny when you talk to people so steeped in lean in these kind of rituals that they just want to say kaizen. And then you ask them, what does that word kaizen mean? They don't know. It just means improvement, you know, or kanban, you know, kanban board. Actually, what does kanban mean? Do you even know? Like, no. It means order. I'm making an order. Hi, Junkachar. It just means a line bound. So at Harley was really hard to approach people and ask them to speak Japanese, as Honda was our biggest competitor. So we just. And part of my thing was always like, let's just make this approach. Well, let's just turn it into plain English and regular concepts that people can understand. I'm not making a religion.

I have to say, I've used a lot of, like, different project management tools and they all have Kanban boards. And I have no idea what Kanban meant, so, yeah, good to know. It means order. Also, I like the idea of like just adopting things like calisthenics in your workplace without really understanding why. That is kind of like the cargo cult, Toyota way sort of thing. So let's dive into some of these principles in more detail. So the first one was solving the right problem. I guess the big question then is, how do you figure out what the right problem you need to solve is?

We could talk about this all day. In fact, it was the first article we published because we think it's just such a big, big hole in the skill set of managers. The main thing we do is we start with a small piece of a big problem. Don't like, start moving, putting flower pots in the plan or moving drinking fountains. Like, what is it cost, Quality delivery. What's your biggest problem that you have that you can put a number on and then go find, take a small piece of that, work on something important. That's where we start with the paper.

That Don referenced, which we can put a link in your show notes, is called the most underrated skill in management. And we really believe that problem formulation is the key. And it's really interesting when you ask an executive, well, what's the problem you're trying to solve? The first thing you get is not the problem. You get a kind of mix of diagnosis and solutions. It's, well, the IT guys don't know what they're doing and we need a new system. We need to hire this consultant. Like, they'll go on for minutes if you let them. And of course, none of those are the problem. Right. The problem is that we're not delivering to the customer. We're not making enough money or whatever. But once you dig into the underlying psychology, you see that we have this strong tendency to kind of jump to diagnoses and solutions and just blow past the problem when we get to kind of the more automatic versions of our brain. But what it means when you do that is you're not using the sort of full power of our cognitive capacities. And so when we get people to slow down and get clear on, okay, the problem is that our customers are irritated with us or whatever it might be. It opens up a whole new set of interventions because the instincts that we have from past experience, they're right probably 90% of the time, but sometimes they're not. And if you don't take the time to see those, you end up putting in more of the solution that didn't work the last time, which, you know, then just leads to a big. To a big mess. So that one question, what problem you're trying to solve often opens up really powerful conversations about what are we doing? What are the biggest impediments? And when you think about it that way, then we discover the printers and all the other kind of really easy to access changes and we don't have to hire the big expensive consultant right away, which I think is often the instinct of senior executives.

And to link this, Richie, to something you said before about the tools and not understanding why all the different. For all the people that work in continuous improvement and lean, who understand the A3 or the DMAIC chart or all these kind of one page problem solving tools, the reason they work is because they actually slow you down and make you look at the data instead of jumping to conclusions. So any number of them will work. You don't have to use a certain one with a certain name and a certain word. The idea, just like writing down the problem and looking at the day and thinking about am I focused on the right thing and can I measure it? Is hugely powerful in all those disciplines. And that's why we say it's the principle, not the specific practice. Don't memorize all the steps, the nine steps of the 15 steps. If you get the idea, if I got to write it down and think about it, get to the data. I've got the basic idea of all those tools.

Okay, Yeah, I like the idea of just really like thinking, maybe taking a few attempts at trying to figure out what the real problem is you're trying to solve. So actually I got a confession debate while I was preparing for this podcast episode. I did solve the wrong problem. So I figured, okay, the problem I have is that reading books takes a long time. I can use AI to just summarize the book for me, create some questions. So I create. I made this like, say I agent I was doing one more kind of best practice, prompting, breaking it down into chapters, talking about, like, who the audience is getting it to come up with like interesting spicy questions for each chapter. So, you know, the, the AI does an okay job at this, but now it's got like 10 pages of like questions to read and try and figure out how to turn this into a conversation. And actually the problem I'm trying to solve is like, do I understand what the concepts are in the book? And just reading like a load of questions that the AI spat out, that's not very Helpful at all. Coming up with questions is the easy part. Understanding the concept is the hard part. So I abandoned that and I read the book, which I have to say was a much more enjoyable experience than just reading the AI summary. So, yeah, solving the right problem is very important here in terms of coming up with the right problem. It seems like the hard part is coming up with a good description of the problem. So are there any principles or advice around, like what forms a good problem description?

Yeah, we talk about this pretty extensively in the book, but it basically boils down to a really simple formula. And you know, and I say this on the first day of the class that Don and I teach and all students now their head. I got it. And then when they come back with their own problem statements, they don't match this at all. And the formulas are really straightforward, which is, you have a target, you know, we want this much revenue or we want this percentage of satisfied customers. You have an actual which is presumably less than that, and then you can see the gap between them. That's it, right? It's just a simple equation, simple formulation. But the reason it's hard this is the really important part of this is you are fighting the underlying psychology. Because what the automatic parts of our brain do is they go straight from situation to solution and they don't formulate the problem or do a sort of explicit diagnosis. And for 90% of what we do during the day, that's great, right? You know, so the example I always give in class, you know, I'm driving and I see the brake lights in front of me light up, right? I just put my foot on the brake and I slow down, right? I don't have to do any sort of higher order cognitive processing. But when we have processes that don't work in our organization and we haven't succeeded with the conventional solution, now I think it's worth the time to slow down. As Don said, we're going to use a little bit more of that conscious processing. What's the target? What's the actual? What's the gap between them? And once you formulate it that way, then I think people can bring a lot more sort of cognitive resources to bear in that context. The other thing I would say about finding the problems is this is also a place where you often just have to listen to the people who do the work in your organization and they will tell you the operational things like the printer doesn't work or whatever. I think it's very easy for senior executives to get isolated. They sit in the corner office people tell them what they want to hear. I had a friend who used to say that his jokes were never funnier than when he was chief executive officer. You know, there's a lot of filtering that goes on, and so it's hard because you're very busy. But making the time to connect with the actual flow of work, you know, will reveal a career's worth of problems to solve. If you can just listen to what's actually happening.

Okay, yeah, I like the idea just listening to what's happening and then also just like, the simple idea of, like, seeing which targets are you missing. That's going to give you a really good indicator of, like, what. Where you. Where you're messing up, what the real problem is. Okay, cool. Let's move on to the second topic, which is about structuring for discovery. So I feel like a lot of the examples in your book, it sounds like an episode of, like, the Undercover Boss TV show. So it's like the boss going on the factory floor and then finding out what the workers are actually doing. So is this the best approach then, of finding out, like, how you go about figuring out the solutions to your problems?

Well, it doesn't have to be Undercover Boss, but it does have a certain aspect to that, Richie. So the way we do it is we do it on a visual board, which is the boss usually sets the target and people say, okay, we agree with those targets, and then in most cases, they just go off and try and deliver the targets. But in our case, we say, okay, what are you going to do? Take some post it notes, Take some little post it notes and write down the activities that you think will deliver those targets. And that drives people crazy, even experienced people. Well, don't worry. I know how to do it. Okay, if you know how to do it, it's just going to take 30 seconds to write down what you're going to do. So we can see, to see if we believe that those activities will deliver the targets. And once you do that, and then you start giving the feedback and say, you did the activities, did they deliver the targets or not? Now you, you're in a discovery mode because you're. You've actually got a hypothesis of instead of just doing the work, you're saying, well, here's what I think is the best thing. Did it work? If so, why can we do more of it? If not, what's the problem? What can I learn? Now it's a learning and discovery thing, and that opens the door to innovation in new ways. But Mostly we just say, Richie, I want 30% improvement, and you go away. And if you don't deliver, then you get dinged in your performance review. But we never really look at the work and what you were thinking about how you see the work. So that's the thing about discovery, in my experience is when I get a. I had some. When I left Harley, went to Intermatic, I inherited a staff that hated me. They didn't want me there. They had all been there 25 years, and they were all fighting for 25, 30 years, the same people. Once we put the activity sets on the board, it was like human resources put a drug in the coffee, a collaboration drug. Now instead of fighting, they're all looking at the activities and they're going, well, I don't think that will work. We used that before. Why don't you try this? And they start, like, making a collaborative plan about the whole thing, because they can see it. So that's what we mean by discovery, structure for discovery. We want people to not only just go do what they think they know, but, like, treat it like an experiment and try to innovate and discover new ways while they're. While they're doing the task.

Ooh, I like that idea of just experimenting on your workflow because, you know, you change stuff, see if it works. If it doesn't work, you abandon it. And if it does, then great. Okay. So it seems like a lot of the key to success here is you're going to have targets that you're trying to work towards and you're going to track them. So this involves data somewhere. So tell me, like, what sort of data are you going to be collecting? Like, what sort of metrics are you going to be tracking in order to change things to hit your goals? Like, how do you know whether these experiments are working or not?

I would say two things, Richard. I think first, the real key is, you know, Don and I worked with a client that should remain nameless for many years that, you know, whenever you would ask a question of, how am I supposed to do this? The running gag in the company was, what's part of 17%? Don't you understand?

Right.

You know, and it was an extreme version of, like, richie, I pay you to meet these targets. Don't ask me how to do it. That's your job. But what happens, I think, in that case is people are not explicit about the activities that they're going to do, and that leads to all sorts of kind of surreptitious, kind of subterranean duct tape. And safety pins and things like that. And we did an exercise with one of our groups at MIT and asked them to line up the activities that would help them raise money for a particular thing. And it turned out once they saw the activity set, there were post its up there that no one thought was a good thing to do.

Right.

There was a particular newsletter that they'd been doing for years and everyone thought that someone else thought it was important and nobody thought that this was a good activity. So I think the number one thing is don't just put the targets down. As Don said, line up the activities. Let's be conscious about that because that will lead to a powerful discussion about how to do that. And then I think the other big takeaway here, and this kind of goes back to the 17% thing, is setting targets and deciding what data to collect should be a two way social process, right? Because what part of 17% you don't understand? It's very top down. Like I give you the targets and you go get them. But Don invented this technique that we use all the time called Barbecue the boss, where you have the boss get up and give a 10 minute presentation of here's the targets, here's what I think we need to do, and then have everyone else sort of write questions. And what you find is that when it's a two way process of going back and forth, the people who work for you do not understand those targets nearly as well as you think you do. And often they'll suggest things that need to be measured that weren't on your radar because you don't know what actually happens on the ground. And so I don't think I can tell you exactly the metrics to go after in a specific situation. But I can tell you that it really is something that kind of boss and subordinates or team have to agree on together. And if you do it right, there'll be a lot of back and forth before you really settle on that. I think that kind of pure top down approach, which has become kind of very popular in management, has a bunch of problems sort of embedded in it that haven't really been fully surfaced. So I suggest you be a little wary of that.

There's a lot in this, this one, Richie. For example, if I say, okay, Rich, you want to grow the business by 10%, go figure out how. And you go, well, like, does the boss mean by organic growth or by acquisition? It's two very different ways to do it. So the barbecue the boss thing hinges on we force people to write questions While the boss is one, we force the boss to be very concise and short. And then we force people, I don't care. You have to write three questions. So we put them on the board. So that takes away to like the softball questions that look, you can ask a tough question, we don't care, as long as it's respectful. You can't believe the number of clarifying questions and information that comes out. And the result of that back and forth social process, as Nelson says, is that people understand the intent behind the numbers the boss is meeting, they understand what he means. And the bigger picture, because we're going to go through the day making decisions all day is it acquisition, organic growth? Now I know which one to pick because I know what the boss means. So that deepening the intent and that social conversation helps both sides because the people on the receiving end will explain what the barriers are. And the boss can decide to either change or give resources or give some advice how to get around those barriers. But now at least the boss knows the barriers. The people know how to do the work. But now they get the right resources and they get coaching and counseling. So it really gets the conversation going for the best parts of the people that know how to do the work and the person that's leading the business and has the most knowledge and resources to give.

Okay, so I love this idea of just focusing on like tracking. What do you actually do and are these tasks that you're doing, are they any use or not? Does everyone agree on that? So a lot of this stuff about like writing down ideas and then having people vote on them, it sounds very close to the idea of design thinking. So I don't know whether that's been an inspiration in your work or not.

I don't. Nelson, you might know, I've read a little bit about it. I think it's a subset of kind of what we do, but I can't really say much about it.

I think design thinking is a really powerful set of techniques and I think again, it often works because we create a space where people can use a little bit more of that conscious processing rather than just having it kind of mixed in with all the other chaos that happens during the day. One thing that I hope we do in the dynamic work design that Don and I have tried to do is to sort of, we sometimes call it a Rosetta Stone. Right. I think you'll see elements of lots of different popular initiatives. There's lean in there, there's agile, there's some design thinking, probably a few Other ones. What we hope we do is kind of take away the ritual and get down to, you know, here's why this works and here's a kind of hopefully simple statement of what's going on there that takes away some of the different sort of pieces. I mean, I'm still. My head is spinning around from something you said earlier, which is all the times you've used project management software that said kanban, and you had no idea, you know, what it actually meant. It just like that makes my blood boil because I feel like it's kind of professional malpractice of the people that taught you the technique, because you know that Kanban, done correctly, can be a really powerful technique. And we'll probably get to the relevant principle in a moment. But if you just go through the motions and you don't know why you're doing it, it's just going to be a huge distraction to your day. And it's going to make things worse rather than better, which is really a crime, because used properly could probably make your life and the work better. And we see that with tons of different techniques. So there's definitely elements of design thinking in there, but we want to know why it works and where it appropriately fits, you know, in the constellation of other, other techniques.

I have a great story about that. I was working in the uk, in London actually, and a guy relayed a story about a building manager. He said it was from the 60s, and he said he took over the management of the building. And there was a form that maintenance people had to fill out every day. And in the top corner it had a box and it had arw. And the guy said, just put a zero in that box every day. And the guy says, why do I do that? He says, I don't know, but we just got to put a zero in that box every day. The guy gets intrigued with this, like, where'd this come from? And he. He, like, calls retired people and, you know, he's just tracing down it needs air raid warnings from the Second World War. But still this. They're still writing the zero in there because someone said, you got to do this for the form to work.

Yeah, I'm hoping they don't ever have to make that number greater than zero. So let's move on to the third principle, which is about connecting the human chain. Do you want to explain what this means?

I think there are two. Well, the big idea with dynamic work design is we see organizations are made up of humans wired together in complex ways to deliver work. So Whenever we draw a diagram, the nodes are always individual people because we'll trace a piece of work along a chain of people. So there are actually two human chains here involved. One is tracing a piece of work along that chain. So it's like a horizontal chain, like a process map, except that people are the nodes and they're linked by their inputs and outputs. And this could be anything from an assembly line to making a decision, to doing research, any kind of intellectual, physical work. And it could be quite complex. So that's called the work chain and the other chain is called the management chain. This is a vertical chain. So this is how the management system connects to that work chain. Just like the old story of the andon cord in Toyota. When assembly line worker sees a problem, they pull that cord, the line stops and the team leader comes right over to say, what's the problem? What can I do to help and what's going on? So that's really the first link of the management system to the work. And then it goes up that chain and that chain. Like, who do I call for help and where do I get those resources? Depending on the size of the problem to get resources and decision making, that's the management chain. Also, both of these have a specific ways that we design them so they function kind of in real time. So when there's a problem in the work, people know about it. When there's a problem that we need management for, they're notified right away and they respond right away. Just kind of the way the human body would respond to a cut or bruise is the management change. And the way in the work chain the body responds to like different blood pressure and temperature and stuff is a normal day. So those are the two chains. But it's when we map it out, it's all specific people in a specific area and we can, we can actually design the work in with those two chains.

Okay.

I like the idea of thinking about, like, how you've got this sort of, I guess, network of people involved in, in a process and then someone goes on holy. And the whole chain breaks and. Yeah, what happens then? If you try and optimize for an individual's like, productivity in the process versus, like optimizing for the whole system. I mean, how are the two things related?

So this, I think goes to our next princip, which is regulate for flow. And I think, you know, one of the. Probably the single most counterintuitive idea that runs throughout the book is that often by trying to do less stuff, you actually get more done and that's just very hard for managers to wrap their heads around. It was hard for me to wrap my head around Madonna. And I first started talking about this, and I think what's going on there is most people believe exactly what you said, Richie, which is that if I want to maximize the productivity of my organization, I just need to keep everybody busy. Right. And, you know, anyone who's spent time in a big company for more than 10 minutes, you know, could see a million different ways that we try to keep everybody busy. But you've got phones and slack and you're connected to the organization all the time, and you have to report out and so on and so forth. But interestingly, everybody knows that that's not true. At least everyone who's ever driven a car on Friday afternoon. Right. Because when you leave the big city on Friday afternoon in the summertime, right, and the car and the highway is fully loaded with cars, what happens to the throughput? It goes to zero. Right. And there's a lot of reasons for that. But basically, overload creates gridlock. And so often by getting people to do less stuff, the flow rate goes up so much that you actually get more done. And yeah. Does it mean that once in a while you got someone that gets to go home at 3:30 rather than 5? Yeah, but it doesn't really matter because you're getting so much more work done. But that's a tough one for people to get their heads around. And so the thing that we've really started to focus people on is what we call regulate for flow, which is think of the loading as kind of a feedback process where as long as the work is moving, okay, maybe we can safely add another project. But the moment you start to see gridlock, like, okay, we need to back off. And Don talked about the broad earlier. They had this problem pretty heavily in their technology development portfolio for a long time and for a good reason. They're really smart people who had tons of good ideas for how to make the technology work better. They just had no method to decide what ideas were going to be let in. So someone would have a new idea, they'd start working on it, I would think. I don't know, Don. For probably two years, every time we would go over and visit them, we were like, you guys have to take 50% of these projects out of your portfolio because you're never going to get them done. And that was a tough one. But when they finally kind of got that discipline, the throughput of their tech development just went up very, very Dramatically. So this is a place where there's really big gains to be had. But it's really counterintuitive to kind of make the hard decisions upfront about what you're going to do and what you're not going to do.

And not only does the volume of work increase, but the time it takes to get done drops. So delivery times actually start to decrease. Because once you start working on something, you work on it till it's done. Basically this organization, so it just keeps moving. So now response times, the customers drop and we become more agile because we can respond to different customer demands or different markets conditions more quickly. And one other thing I'd just like to add to this, Richie, about the individual versus system productivity. This is a big difference in our approach of principles versus practices. So if you're in the practices, you're going to start a program and you get everyone to improve and do their whatever improvement. We don't do that. We go like, where's your biggest problem? Because we know if we go to the choke point in the organization and fix that, then we're going to get more flow through the entire system just from that one thing. And objectively, everyone's going to be more productive because you've got more work coming from with the same people. So we always start with the principle where's the problem? And we always go after system productivity first because that kind of raises all boats. And then you can see the imbalances where you need to go in and say, we need more people here. Or we can make this job a little more effective and more productive to supply the increased flow. But it's always system productivity first which really pulls along the individual productivity.

Okay, I like that. So just really, it seems like we've had a few recurring themes here. So figure out like where the, where the choke points are, solve those, and also I guess try and avoid context switching wherever possible. So just focus on one thing, tune out all the noise and just get something done and that's going to help you out.

And if I could just add to that, you said earlier, you know, boy, this sounds good. I just tell my boss never to meddle in my work so that I can do what I want. That's not exactly the message. The real trick here is, and I think we alluded to Agile software development, the world does change. So you do sometimes need to change the portfolio of activities that you're working on. The real trick here is to make sure you have a clear, what we call cadence, which is basically, I have periods where I work without interruption. And then we have periods where we revisit and redirect. And that cadence of check ins will vary by industry. I always give the example. In the early days of COVID at mit, we had to meet twice a day because the world was changing so quickly. We would make decisions in the morning and then the mayor would issue some new regulation and we'd have to redo it in the afternoon. Even if we're meeting twice a day, I know from 9:30 to 12:30 I'm not going to get interrupted. Right. And so it's taking the randomness out of those interruptions that often makes a big difference and then tuning the check ins to the speed with which the world is moving. So I wouldn't say that you get to do what you want without any correction. You and your organization would have decided like, okay, we think we need to check in every day or every week or every month. And once you know, then it's so much easier for you to plan your day or your week. And then you get quite a bit of productivity just knowing, okay, my boss isn't going to redirect things, you know, for this, this period of time. So that cadence has proven to be a really important kind of design concept that we've had really good luck with.

Okay, so when you got things changing fast, regular check ins for stable day to day work, probably not. Not so many check ins.

There is one rule that we try to make the managers and bosses live by, which is you can change your mind as, as much as you want, but once we start working on something, you can't fuss with it, Let it flow through. Change the priorities all you want until the work starts, then let it go.

I like that. And is there a difference between regulating for the flow of like standard issue work where it's business as usual and the chaotic edge cases when things are going wrong. Do you need to deal with these differently or is it same principle for both, same idea?

I think it shows up differently. But think about a crisis. What happens in a big crisis like the big, like the oil spill that Nelson worked on with, with BP in the Gulf of Mexico. You get certain people get in a room, they put data on the board, everyone knows their role, they're running experiments, they're not taking on more work than they can do in a day because it would be stupid. It go do this and we'll find out what happens. So when things are in crisis, it's even more important to get a firm hold on who's doing what when let's do one thing at a time, learn quickly and move quickly as opposed to just give a whole bunch of work. In that sense, as Nelson said, the cadence of meeting is very fast. Things are running slowly. You could just kind of watch the entire system like product development. You're meeting once a month or once a quarter and just don't put more projects in enough. So many projects in that the whole thing slows down. But the concept is the same, shows up different.

Yeah, and I think there's a nice principles, practices connection here too Richie, because if you think about Agile software development, I know there's many incarnations but often the daily standup meeting is sort of what people preach. And I think that cadence works really well in software development. Right. I get about a day's worth of work done, we check in. I cannot tell you how many companies I go to that they have a daily standup meeting and I ask them why. And I said, well, we're an agile organization. And again it just kind of steam comes out of my ears because the work they're doing may be very different from software related work. And so a daily check in may not make sense with the speed of the work. Maybe they need to do every twice a day or maybe they need to do every week. And so we want people to focus on is the principle which is match the check in frequency the kind of the chaos in your environment rather than well, we're supposed to be agile. So it's to be daily which I think takes a lot of people in the wrong direction.

I have nothing to report because I've been going to stand up meetings all day to talk about what I've done. I mean this is stupid.

Exactly.

But that's the rule, you know, that's the right.

Definitely, I think. Yeah, I like this idea that you should just think about what you're doing. Is it sensible or not? And if not, then yeah, abandon the practice. The fifth principle is about visualizing your workflow. Can you talk through like what kind of visualization do you going to use for a workflow?

Let me start. And then Don could give you the practical side. You know, one of the big insights I think he and I had in our long collaboration was most of the major innovations in work design. Agile is probably the exception have come in factories and what we finally realize is physical work is just easier to design well because it naturally gives you signals when things are going well and when they're not going well. So when Don ran the engine plant at Harley, if a Machine broke. Suddenly it's not moving anymore. You get a very clear signal that something's gone wrong. Knowledge Work typically has none of that. Right. You know, so someone that works for me could be getting stuck right now. Right. That work has stopped, just like Don's assembly line. But when am I going to find out about it? Who knows, right? Maybe I'll get a text message. Maybe they'll tell me tomorrow. Right. Everything is kind of hidden. And so the basic idea behind the Visualize the Work principle is to use really simple techniques so that we can see when Knowledge Work is moving and when it's not. And, you know, and those fancy work management systems that you alluded to earlier should do that. But in most cases, at least in my experience, don't or don't do it well. And so, you know, we often start with as simple technology as you can imagine, which is just post its and whiteboards. You put each project on a post it, you draw a little picture of the process on the whiteboard, and then we just track it as it moves. And if we see that, you know, Richard, your post, it hasn't moved for three weeks. Oh, maybe there's a problem there. We should talk about it. Maybe there's another resource that we can bring to bear. But the core idea really is just, can we see how much work there is, which work is moving and which work is not? And if you can get the most rudimentary representation, the quality of the conversation you have tends to go up quickly and very dramatically.

Yeah. Just to add on a little bit to that, I think the trick is to represent the work, not just the metric. So if you just say, what's your status, Richie? And you go like, well, I'm 50% done and I'm going to be fine. You're giving a percentage and you're telling a story, but we really can't see the work. You might be 25%, you might be 90%. But I think everyone in industry, everyone in heavy industry that I worked in has experienced the project that a month before launch, all of a sudden is six months late. Up to then, it's been fine because of all this kind of hidden thing. Oh, it's just one more problem. I'm sure I'll get it. I don't want to tell the boss. And I think when you're forced to say, we have 16 contracts going through, here's the stages, or sales things or audits, and here's the stage they're in and it's ready to move, or it's not ready to move. All of a sudden the situation becomes very material, the conversation becomes very grounded and material and people are not afraid to ask for help because, oh, I need some help here. Because it's real time and they ask for help not reporting a problem, it's their fault. It's not about bad or good, it's about the work and is it on time because it's about the customer. So representing, trying to find a way to represent the work, the pieces of work, at what stage they're in and if they're moving or not is really the idea and that makes people more collaborative and it's more objective, focused on the system and not on some kind of individual personal quality.

Okay, that's great. And I have to say I do like the low tech idea of using post its. I'm not sure how well it works in a remote environment, but certainly, I mean there's virtual post IT notes and I guess as was released, there's all these project management tools. You have Asana and Monday and ClickUp and whatever they all have of. Well, there's Kanban boards. I'm sure there's some other visualizations. Do those work as a sort of equivalent virtual post IT system?

Yeah, they're all helpful. I think the key is the way we do it with simple in person, where we can. Where people aren't remote and where they are remote, we use cameras and things like that. It's the conversation and the unified view of the work that's the key. If everyone's. You're just filling a block on your computer going away and someone's going to look at it on a screen, you've lost both of those. One, there's no human conversation and two, no one knows what you mean by putting in that little check in the box. So there are a lot and they're developing, getting better, better. Especially with all the audio visual stuff, this real time feel of where the work is, who's responsible and that a collective look at it and saying what do we know about it? What do we think about it? Who can help? Because then you're triggering all this kind of experience and background for people, real time to solve a problem together rather than just reporting and letting someone else be the judge of if it's going okay or not. Yeah.

One thing I would add, I think the one risk of the electronic tools which I think are necessity in the remote world that we ought to live in is the moment Don says, well, I don't have time to come to the meeting I'll check the board later when I get to my office. The magic is gone because it's that real time collaboration of, oh, I'm stuck on this, can you help me here? That I think really makes this work. And so that's just the one thing about the virtual tools that makes me a little nervous. I think as long as it's facilitating a meeting with a high quality conversation and we're making smart choices about how we allocate our scarce resources, then I think you're great. The moment that people just stay in their offices, then I think you're in deep trouble and it sort of doesn't matter how sophisticated the tools are. And I would say just linking back to the AI conversation we had earlier, I think this is a place where AI in some guises could be enormously helpful and in some places where it could be really dangerous. The helpful version is, is I would imagine as we start scraping email inboxes and project files and stuff like that, we're going to get much better metrics about where the work is and its sort of true state of affairs, which I think would be great. The more data, the better. On the flip side, right, if we start using the AI to solve the problems or allocate the resources without that human connection, that strikes me as very dangerous in that context, at least given the current state of the technology.

I said this before, Richie, but I'll just reiterate it when it's done properly. It's like HR put a collaboration drug in the coffee because people change their roles. It's no longer the boss calling me an idiot and I'm slow and what's wrong with you? If I put a post it note up on that board that says I'm going to do something next week in front of my colleagues to a collective goal, the last thing in the world I want to do is come back next week and say, oh yeah, I forgot about that. It makes me look like an idiot. So I'm instantly accountable and the. And I'm in collaboration with my peers. So I think people miss that. I'm now invested in because I said what I was going to do. I got feedback, maybe got a new suggestion, blah, blah, blah. But then I signed up to do it and it's in my handwriting on the board. It's not my boss. Oh, my boss. That's a dumb thing. I'm not going to do it. There's like, I put it up there and I don't want to walk in and disappoint people. It's a hugely powerful tool if done correctly. Oh yeah.

I do like the idea of just making sure you and Cobb shared understanding of where you're up to with any given project. So you're not just having differing point of view because the board wasn't up to date or people were just putting zeros in a box because that's what they've done since World War II. I guess the, the hard part of this is the change management. So when you're changing all your processes, the bound to be people saying, well, you know, I've been doing this for 30 years, why should I change things now? There's going to be some resistance. Do you have any advice for overcoming resistance to change?

Yeah, you know, so number one, don't make this initiative. One of the running gags and dons in my act is, you know, we talk about T shirts and coffee mugs and posters and off sites and you know, there is a kind of standard recipe for change where you have the two day training course and then the executives get the half day course because they don't have time for the two full days and you try to roll it out everywhere. And I could speak for the rest of the day about why I think that's broken. So don't make an initiative. I think the way to get people engaged is go to the work and find the points of frustration for the people who actually do the work on a day to day basis. Many years ago I was working with a local children's hospital and they were really struggling with some change initiative they were working on. And I remember I was watching a meeting and everybody was bitching and complaining. And I asked my host like, you know, can I have five minutes? And I just went to the whiteboard and I said, what got in the way of you getting your work done today? And the population was the nurses who were caring for, you know, some cases really sick kids. And in like five minutes we filled the whiteboard like, well, there's an air conditioner that leaks on the patient and the closet with the diapers in it is a quarter mile of the way. So I have to walk a half mile when we run out of supplies. And this doorknob doesn't work. You know, just, you know, a long list of kind of those small but really important things. And the energy in the room just like Don said came up because now we were talking about the real stuff. So I would say, you know, if you want to get started, find a place where the work isn't working, talk to the people that do that work and just engage with them and start solving some of those small problems. And the moment you can see progress and the people doing the work can see progress, you got them, then the engagement goes up. And that's why I think scoping down works really well. Because if you pick a smaller problem, you can usually get it solved quicker. Then I think you're kind of off to the races. But don't try to do it everywhere at once. The metaphor we use a lot in the book is this isn't like going on a crash diet, right? This is a lifestyle change. And you need to kind of make that lifestyle change sort of incrementally, get it embedded and move on to the next piece.

What was that? We used to have a word for the resistors. It was some kind of word, like the something. Resistor was like this category of person that was like naturally resistant. And that's total bs. Some of my best people started like that because they were just so angry at the bureaucracy unfairness and the humiliation that the system gave them in doing their work. And if you relieve them and give them a better way to do their work, they, they start working. I'll just tell one story from my first supervisory job in the factory on third shift in a union place after a seven month strike. When I was on strike and then I switched to management, we came back, he was like 6 inches taller than me, probably a hundred pounds bigger. He was a really an angry guy. And he's running piecework on a machine and using a big hammer. And I'm going up to, you know, and he's just really mad. He hates me because I'm now management and he was having a problem and so I said, well, what's the deal? And he said, I don't have the work, I don't have the tool, blah, blah, blah. So I, I ran around and I pulled the card over, I gave him the work, I got him the tool, I got him the gauge. And he could, because he's working on piecework, he could actually make money. He started working, he was still a big angry guy, scowled at me, but when he talked to me, just the corner of his lip turned up with a little bit of a smile. And he turned into my most productive guy because people just want to help the company, they want to get what the boss done. But there's so much BS and humiliation, all kinds of stuff that gets in the people way of people doing respectful work. So I think part of Nelson is, yeah, go talk to those people. And help them. If it's a better way, they'll be your best, your best PR people. If it's a stupid way, then they're going to hate you. And rightfully so.

All right. I love the idea that actually your angriest employees might turn out to be your most productive ones because they're the ones who care. They're just getting frustrated with, with what's going on. I'd actually like to stoke the long standing MIT Stanford rivalry. So a lot of the sort of the themes in your book are around, like making just incremental specific changes to workflows. Now last year we had Ilya Strabolaev on show, so he's a professor at Stanford. He does a lot of work with venture capitalists and he's talking about a lot of the success of ventured capitalists is about taking big bets on completely new ways of working, completely new initiatives. And that if you want to replicate that success in your own company, you just need to think about what are some radical changes you can make rather than doing these sort of incremental changes. So do you have a position on, like when you want to do these, these smaller changes, these smaller fixes to your processes, and when you just want to burn everything down, start again with something completely new?

Yeah.

So I could jump in and then Don could certainly. Because he's had this stuff inflicted on him, you know, over the course of his career. So first off, I think it's really incorrect to say that it's one or the other that you have to allocate. Organizations can be moving along just fine and say, hey, we're going to do a skunk works project, or we're going to investigate a piece of new technology or whatever. Like, I think that those two things can coexist where people really get sideways on this. And this speaks to a lifelong career long debate I've had with a faculty member at actually our other rival Harvard Business School, which is up the river from us, is many people believe, I think erroneously, that if you do a good job on these sort of incremental changes, that it has sort of the side effect of hardening the organizational arteries and it's going to make it harder to do these kind of big moonshot types of things. I see no evidence of this. And in fact, I think our experience is that when you do the small stuff well and you fix your existing processes, if you do it right, it's like a general purpose fitness program that will create sort of new muscles that you can then apply to the Big changes. And so I think the two things can coexist. And I think the reason people have kind of come to this erroneous conclusion is if your management style is, what part of 17% don't you understand? And you kind of react to, you know, with more forms and more meetings and so on and so forth, that I do think definitely precludes innovation. There's. There's no question there. But if you're building the ability to do all this small cycle stuff, then I think when you need a bigger, radical change, you are in a much better position to do it. And we have a fascinating test case, which is Don talked about Broad earlier. So we had worked with them for eight years. They'd made enormous improvements in their existing business, and then they were shutting down in the beginning of COVID because most of their clients were researchers in universities that were shutting down. And then, as we described in the book, they got this phone call that said, hey, do you guys know how to do COVID testing? And in six months, they went from never having done a diagnostic test to a patient to being one of the biggest COVID testing labs in the country. Right. You know, that's as big a switch or pivot or whatever metaphor you want to use as you could come up with. We can't run the counterfactual, but I'm very convinced that all those muscles that they built in the previous eight years allowed them to make that pivot faster, more successfully. So I think those two things can coexist, and I think the resources you build in one definitely will help the other. But I think it's easy to confuse the kind of incremental problem solving and the workforce engagement that Don and I have been talking about with the kind of, what part of 17% don't you understand? And I think those two have totally opposite effects on your ability to do the kind of bigger innovations.

I think the big innovation works sometimes, but to me, there's a relationship between quantity and quality. You make so many of these small things, and all of a sudden you've gotten all the little stuff out of the way, and now you see the opening for the big move. And if you look at the people who've been the most successful with big ideas, it's because they understood the existing market or the existing technology thoroughly, and they see the opening. It's not like, oh, I have a big idea, like, trees grow upside down. Look at the history of startups. And people just have a wild idea with no basis in science or reality. What's the hit rate on them, it's probably 10,000 to one that make it because they're lucky. But the guy who, for example, the guy. What was the name of the guy that invented the light bulb, just didn't sit down and like think, oh, let's use tungsten. He tried 10,000, ran 10,000 experiments. They were sleeping on benches at night, working 20 hours a day to finally figure it out. There's a lot of sweat, you know, 99% perspiration, 1% inspiration. So once in a while, people get lucky. This is really not my game. My game is making things work. But when someone comes up with a good idea, we've helped those people operationalize that and move fast. But I think there's definitely a correlation in the wild hare ideas. I just have no patience for, really. But the people deeply grounded in the situation and have a rationale for why it's an opening that no one else sees. Those I'll go with.

Yeah, okay. So, yeah, very little to politeness about those crazy California United States. So I like the idea that just making small changes, you're going to build an organizational sort of ability for making bigger changes in the future. So, yeah, it's like training to get fit in order that you can run the race at a high speed later on. I do like the idea that you really need to understand what work you're doing before you can start making radical changes. Otherwise, just a total disaster. Just to wrap up, do you have any final advice for people who want to change their processes? Like, what's your number one tip for getting started with process re engineering?

I would say don't think about process re engineering first of all. Start with the most important problem you have. Start, get a small piece of it, go find out what's really wrong, work with the people doing the work, get a 30% improvement, figure out what you learned, and then take it to scale.

The only thing I would add to that sort of, you know, done sort of the shop floor. I think for, particularly for senior executives, that if. If there was one thing I, you know, one skill I would want to sort of cultivate is it is the job of senior leaders to set priorities. And it's shocking to me how often people abdicate that. And when you don't set clear priorities, particularly for projects that almost immediately leads you into the overload and the sort of gridlock that we've talked about before. And I would say for years, Don and I, you know, used to tell people, do less stuff, do less stuff. And I'D say we had modest success at best. But I think when executives have the discipline to set priorities and really rank order them like, this is number one, this is number two, and this is number three. And then sort of cultivate the culture of, hey, Richie, if you're on the critical path for number one, I don't want to see you working on your pet project. I think that coupled with that kind of bottom up problem solving, you know, if there's one thing I could get people to do in the C suite, I think that would make a big, big difference because it would really help the organization focus and get out of the way so that they're not doing all this peripheral, peripheral stuff.

And don't make that priority list 50 and say, I want all 50. Like how many can we work on at once? Get those three, then I'll give you three more or something.

Yeah, and rank order them.

All right, nice. I like that. So if you're an individual contributor, figure out what your problems are. Articulate them to your boss and your colleagues. Everyone knows what they are. If you're a boss, then make sure that prioritization is important and clear to everyone. All right. And just very. Finally, I always want people to follow. So whose work are you most excited about? Who are you reading and looking at at the moment?

I'll leave that to Nelson. He's the.

Yeah, so I'll give you one relatively new one. Bob Sutton and Huggy Rao have a book called the Friction Project that I read recently that I think is very complementary to ours, you know, and just talks about the stuff that gets in the way of things getting done in the organization. I think we're a little bit more micro. They talk a little bit more sort of at the cultural and C suite level. And then it's not necessarily a new book, although it is a new version. But I'm a big fan of Zeynep Tan's work on the Good Job strategy, which I think is a really powerful compliment to our stuff because she talks a lot about investing in human capital and treating people well. I think our book basically is okay, once you've done that, what are the skills that those people need to do to leverage those investments that you're making in there? And she actually has a new book that sort of builds on that idea and I highly recommend both of those.

All right, wonderful. Yeah, Definitely sound like things to check out. Excellent. So thank you so much for your time, Dom. Thank you so much for your time, Nelson. It was a real pleasure chatting with you both.

Thank you.

That was great. Thanks for having us.

Thanks for reading the book instead of using AI.