 Welcome everybody to yet another OpenShift Commons briefing. This time, as we do every Friday, we have one of the many members of the Global Transformation Office. This time Kevin Behr is going to talk about continuous improvement for senior leadership. So I'm going to let Kevin introduce himself, talk his good talk here, and then at the end we'll have live Q&A. So if you're watching on Twitch or Facebook or live streaming on YouTube, we'll aggregate the questions from there and bring them into this conversation. So with that, Kevin, take it away. Hi, I'm Kevin Behr and I am with the Global Transformation Office. And basically I have written some books that you might have heard of, The Phoenix Project and I've also written Visible Ops. And I'm here today to talk to you about continuous improvement for senior leadership. This is a topic that I'm very, very passionate about and I want to get going right away. So first, we're going to talk a little bit about what doesn't work, look at some of the proof that it doesn't work, and then I want to talk a little bit about how scaling these efforts happens and doesn't happen. And also just some kind of understanding about the kind of economies and costs and capacities that organizations have in terms of constraints. And then I want to talk to you about what Akata is and then I want to talk to you about the Toyota Improvement Akata. But really, this talk is really to talk to you about focusing on the kind of adoption of these techniques at the senior management layer. They have not been really adopted in mass there outside of manufacturing organizations and some kind of knowledge work organizations that are really ahead of a lot of folks. So what doesn't work around improvement, I think all of us know, is that meetings don't work. A lot of us have regular scheduled meetings to talk about things that we need to fix, things that we need to move, even retrospectives. And one of the things that I think is really important to understand is that if we are talking about making improvements, we're talking about making improvements to our organization or the processes that we use, or even the communications that we use to talk to each other, it needs to be a systemic thing. Because otherwise what we get is inconsistent results in our organizations and it becomes hard to actually teach people about things. So meetings are one of the worst places to kind of create this notion of lists of things or telling people to use a suggestion box for their improvements. And I can talk to you a little bit about why that is. It literally has to do with the notion of multivariable experiments. When a lot of people make lists and a lot of people then actually start working on those lists, what we find is that people tend to engage in work that while they're working on their own doesn't seem like it affects others. As a manager you start to see that it does because you hear from multiple people. So sometimes things that we intend to go the right direction can actually go the wrong direction when we're doing them too many at a time and also in a very unfocused or unsystematic way or non-systematic way. So I've even seen people come up with these lists and then try and prioritize these lists and then try and execute on these lists. And they don't ever seem to get much further than four or five items down the list before the list is kind of inventory and it doesn't really get worked. Or people just put new things on the list and skip ahead of the old ones. So I think these kind of notions of lists and by the way, if you ever take an hour with a team and say let's list all of the things that we can improve, you're going to quickly run into the problem. So we don't have enough time, money, staff or budget to do all of those things. You're also going to find that the list of things to improve are often the outcomes or the things that people want but really not the underlying systems or steps or people or processes that deliver those results. So many times we're addressing symptoms rather than causes. One of the things I think organizations have done really to try and get people to improve because people don't like to systemically improve. What we've found is that they'll bring these awards into this conversation. Like you're going to get some sort of honorable mention. I've even seen plaques. I've seen team awards. And those can be effective tools for recognition but not as a sole strategy for getting people to improve. Matter of fact what that leads to is often vanity improvements where you'll get the mission accomplished style meetings where people will declare victory but for anything has actually been delivered. So the other thing that we think of when we look through these lists is how many of these changes are things that we could do without additional budget staff or even clearing or kind of traffic control from our leadership to buy a space. And when we look at the list of improvements they wind up becoming incredibly large like project oriented improvements. And when we think about improving an org, a lot of times we're talking about improving around things that are in limited supply, constrained things, either items, time, resources. And so we're looking to get those things. Many times the improvements themselves because of their scope actually require use of those same constrained items, people, resources and things. So sometimes our improvements can cause things to go the wrong direction if we're not careful. The worst thing ever I think is creating lists, big suggestion boxes and the notion that we want to improve without actually having any way to do it. And so the big thing that people always want to do and when I even talked last week about ITIL and DevOps the last time I talked, a lot of people said, hey, when we're doing our DevOps work, we have a better way to test changes. We have a better way to do things. We just want to completely replace this process. And that is a big bang improvement that somebody wants to make. And when that happens, that actually causes a lot of problems. First of all, it actually can cause an immune reaction for the people that, you know, job is to run said process. And then secondly, it can really, really, really cause friction because maybe the people that are proposing that improvement don't have the whole frame. When our improvements that we propose involve others or affect others in a dramatic way, we need to be very, very careful that those improvements are lined up with strategy. They're lined up with our constraints and they're lined up with our capabilities to actually carry them through. So when I say lists and suggestion boxes and things don't work as effectively as a systemic way of improving, I can tell you just a little history and I think, you know, I'm going to paraphrase a little bit. So look this up and research this on your own. But in the late 80s, a book was published called The Machine That Changed the World. And it was basically about the automobile and it was about the fact that we had discovered, this came out of MIT, that there were a certain group of manufacturers in the world that were actually making a very, very radically different economy out of auto manufacturing and there are other manufacturers subsequently. They were making more cars than we were in less space, like half the space. And on its own, that doesn't seem like a big deal. They were making cars than us, more cars than us, with half the inventory, which kind of actually befuddles the mind a little bit. How can you make more when you're constantly running out of things? Third, they were able to make more cars than the US auto manufacturers in all cases in half the time. So half the cycle time. They were delivering cars faster. And then the scarier part about all this is they were delivering all of the cars with less inventory, less space, less cycle time, but they were doing it with half the defects. And so I think you start to say, wow, that is a very, very big difference. And then the first question is we ought to ask is, how are they doing that? What are they doing? And in fact, that's what this book was about. The book was about, hey, there's Japanese auto manufacturers, in this case Toyota. And Toyota and some of these other manufacturers are doing things completely different to where when American auto manufacturers toured some of these early rebuilt factories in Japan after the war, they didn't actually believe they were real. Because they didn't think there was enough inventory on the floor. They didn't think that there was enough of the kinds of activities that you would see in a large-scale manufacturing operation. So they thought they were being hoodwinked, but they weren't. And I think what's important to understand is that from like 1950 to around 1983, the car manufacturers in 1950, GM, Ford, Toyota, were all making around the same cars per person per day, somewhere in the neighborhood between three and three and a half, I believe. But double check my math on that. By 1983 or so, that number had gone up to 17 and a half cars per person per day at Toyota. GM and Ford were still around that three and a half cars per day per person number. What happened? Nothing. Toyota, very, very sure and steady. 1950 was bankrupt. And Ono focused on basically putting an organization together that was not allowed to have more inventory than it had orders, which was one at a time. The kind of genesis of one by one flow, which is actually a new goal for many organizations, right? And they weren't allowed to have much space. And the reason they were bankrupt is they had built a bunch of inventory that nobody had wanted. So they weren't going to get much inventory. So the problem that we started to see is that this was a limitation to their ability to scale. So from 1950 to 1960, Taichi Ono and several of the other principles at Toyota, and Shigiyoshinko worked on building a new approach to using what little resources they had to scale and make a lot of cars by generating a lot of orders. One problem was they didn't have a lot of order capability because the marketing organization had been split off from them. So what they had to focus on was the system itself. How do we make and deliver cars? So they won by doing these continuous small improvements. And the Toyota Cata was something that we missed initially in the first lean efforts. Many of the folks that were doing the research on why there's such a difference between the manufacturing capabilities of Japanese audio manufacturers and ours, were looking at what was being done with the hands because we wanted to understand what they were doing. And for many, many years after 1988, until I believe actually Mike Rother wrote the Toyota Cata book, many folks did not understand that the word Kaizen was referring to the continuous small improvements embedded in the Cata. And Mike Rother goes at length to tell you why this is. It's because we couldn't see what they were thinking. We could see what they were doing with their hands. But what they were thinking was a simple method or Cata that was allowing them to all work in kind of a synchronized harmony towards a goal. So the other thing that I think is important to say to a lot of folks, because a lot of folks then start to talk about automation saying, well, hey, automation is a huge improvement in our organization. And we actually are leaning on automation to drive improvements moving forward. And I always answer them with a question that says, really? And I said, have you ever heard of GM in the 1980s, early 1980s? And I often will repeat the story of how GM during the largest kind of tumultuous period it had in its manufacturing history in terms of labor relations, global economy. A lot of you remember there were riots, there were hostages taken. It was a pretty tumultuous time. Interest rates got really, really high. And GM decided that one of the things it was going to do to kind of combat the rising labor costs and the difficulties they were having with strikes and labor was to invest in robots. And they made a big deal of fanfare investing in very, very expensive robots. And several years later, there really wasn't much of a benefit from them. And there was an interview done with the CEO of Ford that time, asking why Ford hadn't kind of joined in that arms race of investing in robots the way GM had at the same time. And I'm paraphrasing, but the CEO of Ford said something to the effect of our largest problem wasn't speed, it was consistency of practice. And until we improved our consistency of practice, we were just going to speed up our rate of failure. So then when Ford bought the robots later on, they bought them at less money, because they were not buying as an early mover, and they knew exactly what they were buying them to do. And they understood where they would put them. And I think that is a very, very important lesson for all of us is big bang improvements in the site of a big opportunity can often fail to deliver and also distract us from the real improvements we need to be making in the long term. So again, kind of coming back to the systemic nature of how we improved, how will it be taught if it's not something we can repeat. Now, we can do artisanal guilds, and we can actually have people work together and mentor and mentee relationships, which actually is really, really important. But still, there needs to be a body of knowledge that we can all pass to each other. It makes it much easier to point people to other resources. And also, if you're not available, it's for somebody else to step in. And then the big thing is how will we measure our improvements. And the most important thing I think is without some sort of former system, how are we going to make consistent progress and advance that progress with a common language. One of the largest problems I have seen in corporate America is a very simple problem called learned helplessness. The enterprise at large is designed, regardless of what we say, to actually mitigate the effects of change at the personnel level. It goes along with the basic notion of the corporation providing enterprise goodwill, being greater than any one person. It also has the intonation that any one person cannot mess this up. In other words, it also means it's really hard for any one person or group of people to change the system in an enterprise. It is designed to sustain value in a footprint. And I think this is one of the things that is most kind of troublesome about enterprise transformation as a notion. It often fails to take in the account, the fact that there's a system designed to prevent things from changing. And also that the entire organization has a disposition of doing things the same way. So if we can't develop a common language, if we can't develop some sort of regular systemic process that's built into the daily understanding of what important is, we are basically not going to be able to scale this. And if we cannot take it part of the system to change the system, we will in fact be continual laggards. The other big thing about improvements that I think a lot of people haven't thought of, and this is a conversation that I'm also having with folks in the continuous delivery committees, communities as well. And that is about capacity of the work or uptake. One of the things I've seen a lot of is a lot of really large sweeping improvements made as large projects and even programs and enterprises. And they require almost as an assumption at the end that everybody will just consume it. Whatever the new feature is, whatever the new platform is or whatever the new capability is, there's an assumption that the hard part is the rollout. The easy part is just using it or uptake. Well, I can tell you that we all know that this is not true. There's been a lot of platforms bought in many companies that nobody adopts. There's been a lot of tools that nobody uses. Jelfware is common. And so one of the things that we need to understand is the reasons those things happen are also the reasons that it makes things hard to improve. That makes things hard to improve. So we don't have a lot of time. We certainly don't have a lot of mental bandwidth and we're being distracted at kind of an unprecedented pace. Years ago, there was research done in University of California back when blackberries were a thing, the tech workers were getting interrupted by their devices about once every 15 minutes. I think we all know that that's a luxury that we would all love to have today. 15 minutes of solid thinking without a device going off. All of these fragmented attention, fragmented time, overdriven with meetings, getting more deliverables in many cases than we can deliver. All of these things are the things that make it hard to improve. But they're also the things that make it hard to assimilate all of the improvements that are available for us to use. So if we're improving things and nobody uses them, it's inventory that nobody bought. And that means we've wasted. So one of the most important things that we've learned in software over the last 40 years, right, is that small changes better than big, huge ones. And so metabolizing small batch sizes in, you know, code and in inventory and in just about every application where we make things seems to improve flow. And so one of the big things that we've noticed with improvement is it basically benefits from the same thing. Making the improvements smaller, atomizing and micronizing the targets to make them achievable in small time periods means that we can sustain these efforts for long periods of time. The other thing is, is that as you change in a smaller amount, those changes can scale out to a larger group of people because they're easy to assimilate. It's kind of like the metaphor of chelation. Chelation allows you to embed things like vitamins or minerals inside of things like sugars so that your cells will take them in. Sugars have a certain size. They're very small and they're very easy to fit into cells. So it's nice to take those big rocks that you want to get in you like magnesium and calcium and reduce them to the size that they can actually fit inside sugar. And when they do, your cells will take them in both at the same time. So this is the kind of thing that we need to think about with improvements, which is how do we make these improvements small enough, attractive enough and absorbable enough to become adopted? And so this is a big reason why I like a systemic approach to improvement. It's less herky jerky. It's less about funding. And the other thing is, is it improves morale. One of the things that I think really decreases morale in an organization is that huge list of things we need to fix on the wall and nothing gets crossed off. In other words, things don't change for the better. The other piece is mastery of changes that are smaller obviously are more manageable. So I want to talk to you a little bit about Kata. I did let the word slip out in the conversation a little bit earlier, and I want to talk about what just a Kata is. In a generic sense, a Kata is like a move or a dance move. If you think about martial arts such as Kung Fu or Taekwondo, there are a series of motions that are learned and these motions when put together can become Kata's. So just like certain dances like the merengue or salsa, all have styles of movement and steps, even line dancing does, right? So these things are actually small Kata's. One of the most important things to understand is is they coordinate motion, thinking and experience. And that is a really, really important thing to think about. It's not just rote doing. There's an awareness to the Kata. So when Mike Rother found that what they were doing at Toyota wasn't just lean, that there was something behind their eyes, there was something in their heads, the folks that they were watching. What were they thinking? So through observing Kata's, he was able to start to understand the thinking and talking to people. And that led him to write the Toyota Kata. And I think one of the things I thought has been really interesting is that lean has literally missed this part for decades. Which was the thinking part of this. We have all of the techniques, you know, how to shine and make everything pretty and how to do value stream mapping and all those things. But we missed the most basic motion or execution of improvement that was happening that literally had the largest impact. And I think some of us wondered why 70 to 80% of lean adoptions were failing. Other than the fact that 70 to 80% of adoption of most things seems to fail. It seems to be a Pareto shape in the nature somehow. But one of the reasons had to do with the fact that we were really adopting what they were doing. We adopted what we thought the folks that we were learning from were doing. And I think that that was an important discovery that Mike made. Mike was at the University of Michigan. And matter of fact, to this day, he still offers the Toyota Kata training. I can't tell you enough about the resources that he's put up for free on his website, including videos, the templates, the questions and everything you need to do to get started with this. And I think the most powerful thing about this is you don't need to hire consultants to do this. But if you do, make sure that you have a defined small scale set of experiments and an outcome that you want to achieve. So when Mike wrote this book, it really changed everything. I remember picking it up and being like, oh my word, this is absolutely amazing. And it made so much sense. And it made the A3, which is a technique from Toyota in terms of problem solving a way of problem solving a structured way of gathering all the information to solve a problem. It made the A3 just make sense to me. Before I was like, yeah, I get putting your problem on a piece of paper in a structured way with a lot of the same questions answered. That is powerful. But when the Toyota Kata got revealed to me, I understood that it was the basis or kind of the entry point for making an improvement. The other thing is, as I mentioned before, learned helplessness. This notion, and there's a lot of psychological experiments that have been done around learned helplessness over the years. But the notion that you can take somebody that knows how to find the cheese, literally the experiments were done with rats. And they allowed the rats to find cheese, to learn how to find the cheese. But then one strange thing happened. It's like we put the rat or the rats in the enterprise. But no, literally what they did is they changed the stimulus. So every time the rat would actually try and find the cheese the way it learned, it wouldn't work. Instead, the cheese would just randomly come into the cage at a place where the rat didn't expect it, but could never figure out how to activate. So then the result was the rat just sat still, because it basically knew that it didn't know what to do, and that cheese was just going to show up. And I think that this is a pattern that many of us have learned in the enterprise. We try to make improvements. We have a great idea. We want to do a thing. We want to make something better. We're tired of banging our head against the wall. Whatever it is, it could be a group of us. And we try and make a difference. We go get approvals. We do the things that you would do in a normal situation to make improvement happen logically. But then what I call the enterprise effect happens. There's all of this resistance. Nobody wants to help. People don't see it. Management doesn't find the value in it. There are just more reasons that something will not happen than you could ever imagine. And after a while, a lot of us give up trying to improve outside of a certain circle that we've determined that we have control and influence in. And in an enterprise, that's pretty small. So again, that also leads to morale issues over time, kind of like a hopelessness that can develop. If we can't even address the most basic things in our daily work life, then what is it that we're doing that's supposed to be bigger than that? So the other big thing about Toyota Cata that I thought was really brilliant, and I think a lot of people have talked about this over time, is it allows folks, since the Cata is practiced, and I'll get into the details in a minute of what the Cata actually entails. But since the Cata is a practitioners tool, in other words, the people that do it are folks at the edge largely. I'm talking about you to actually bring this into management as a discipline before you bring it out to the edge. Because if you can model this internally, and I'll talk about that in a little bit, you have a lot higher chance of getting folks to actually execute this where they work. But again, this method and the series of steps really focuses on moving decision making to the edge around improvements. It provides a very lightweight framework for making the improvements. By the way, it's scientific thinking and an adaptation of the scientific method. The Toyota Cata is surprisingly stealthy this way. It will actually, as it's practiced among your management and your folks on the line, will actually increase your scientific thinking capabilities dramatically. To the point where you'll actually develop a language among your team about talking about problems, opportunities, and improvements, that sounds like science in a very, very good and crisp way. So one of the reasons that this can move that decision making is inside of this framework, the folks that are doing improvement have agency to make small decisions about what to do next, how to design experiments, and how to overcome their obstacles with goals and very, very solid metrics in mind. And so what this actually teaches is that folks are more likely in this construct to solve real problems where they work every day that improve both their productivity and their satisfaction with the job, but also the quality of the products and the things that you make. So what's really important is these decisions are now made without your involvement. What you would be focusing on as managers would be focusing on the coaching of these things. So the thinking behind the work that they are doing is what you're coaching, you're not telling them what to do or how to solve the problem. And this is very powerful because what you're building is people that are capable of teaching other people and mentoring other people through this process. If you guys don't, as managers and leaders, especially senior leaders, model this effectively before you ask people to do this. In other words, if you kind of do the babysitter routine where you say, hey, we're going out and somebody's going to come over and teach you some stuff while we're out and they're going to buy a pizza. We want you to do everything they tell you to. That's less influential than actually something that your team sees you model and actually use yourself. And I think that that's obvious. But I have to say it because apparently it's not. I've had so many folks that have told me, hey, great, we're going to learn how to do Toyota Cata. And I'm like, awesome. How's that happening? Well, management thought improvement was a good idea. So they hired a consulting firm to come in and teach us how to do improvement. And I was like, interesting. Does anybody in your management team are they going? No, no, they're not going. This is for us. But it's a really, really strategic thing. And I'm often really kind of amazed to hear this and then to say, and you believed that because I know internally we know what our leaders value because we know what our leaders do and we know what they say. So when they say isn't what they do, then we're having trouble. And so we have that credibility gap. And so one of the best things I think that you can do with your team and for your organization is to actually figure out how to do this at home. So when I tell you the steps and I give you some resources as to where to look specifically go to Google right now and type in Mike Rother. His last name is spelled R O T H E R face Toyota Cata resources. And you'll see his a link to his personal web page at University of Michigan come up and the Cata website. On those links and on all those pages, there's just a variable court of copia of resources to use for both executing learning about teaching others the Cata and also all kinds of examples. So I would definitely give that a check out real quick before you start talking to your team about it, consume all the free resources there are. But all you need to get this going in management is a small nucleus. And I mean by nucleus, two of you. The reason why the Cata can be run personally and I think it is oftentimes best run personally, but I do believe that it is best learned in a group. That's how I learned it. I actually was with Mike and with Bill and I learned it from them. And it was one of the best experiences I've had. I've taken several people up to their training in Michigan and had a blast. It's a really, really good time. And I think it's a really, really great chance for you to show the rest of your team how excited you are about improving things. It's a really worthwhile journey. I highly recommend it. But again, if you can't find another person to learn this with and model it with and find something simple that two of you can focus on to improve. Or even, you know, as another step, even earlier as a genesis for yourself, take these materials off the web and find something in your life that you want to like improve that's been kind of nagging you that has some obstacles. And I think what you'll notice is as you begin to apply the basic steps of Cata, you're going to find one thing really quick. You need a coach. And I think that that is why having somebody else learn it with you and somebody else who sees what you don't see is powerful, but it is also powerful to get some training to watch some videos. And like I said, Mike has a ton of plethora of videos up there for you to watch. And I think you can get a lot of great insight. And if you still have questions, go to a class, but do it on your own at first or take a buddy at work, but don't don't throw an organization into doing Cata without you having some idea and being able to model how it works. Otherwise, it'll just be another thing that you try to get people to do that they'll pretend that they want to do and that'll fade away over time. So I think it's pretty clear that your team knows what you understand, and that modeling this is important. So let me get into what the Cata is. I flashed a screen here that's got three books on it, both the original book to the left, which is the Toyota Cata, and then the Toyota Practice Guide, the Toyota Cata Practice Guide, which is in the middle. And this is actually really effective, although some of these resources, again, like I said, are available on the web. And then Learning to See is a really great book that is not listed on here that Mike also wrote, which is about value stream mapping. But I really like this book, The Toyota Cata Culture, and I think that one of the most important things that we can understand about the Cata is that culture is changed by doing something different. A lot of times we think that culture is changed by embracing a new mindset or having, learning a new way of doing things or all getting on the same page. These are kind of Western ideas that we have heard all through the years and say without even thinking sometimes. But I really believe, and I think that a lot of people believe that the way you change something is by doing something different. So the way we change culture, if we think about culture like a rear view mirror or maybe even the disposition that our organization has to things, it's basically things that we have done that maybe we are more likely to do. So the way to change that culture is not to steer and drive in the rear view mirror, it is simply to intend to do a new thing and to do it. And the doing changes culture. The doing also changes our minds. We also tend to believe in Western culture that we set our mind, then we do it. Or we agree with it, then we do it. There's a powerful, powerful understanding that sometimes the best understandings come from deliberately suspending our disbelief. It's hard, but deliberately suspending your disbelief allows you to try something as if it's something you would try normally. And when you do that, you may get a different result than you expected. And when you get a different result than you've expected you've learned. And that's why it's really, really important to learn how to suspend disbelief to take a new action and see how it affects the way actions happen around you. And also another reason why distributed or systemic application of this is important. And it allows you to reap those rewards organization-wide. So I'm going to talk to you really quickly here about just what the basic steps of the improvement Cata are at Toyota and Mike discovered. Again, you can see all this stuff on Mike's site. There's a link down here at the bottom of the page. But I think Google is the easiest way to find it. So basically, this is a little bit about a list, but basically there's four steps of the Cata that we use. We actually want to understand the direction of the challenge. And one of the things that I'm not going to spend a lot of time on with you today, because at the beginning of this, we're really trying to understand how to apply this in a small scale in our own life or in leadership. Again, I really encourage you to get the details from the materials. But when we understand a challenge, and I'll briefly cover what a challenge looks like and how that works. But basically, one of the problems we have when improving things at our particular safe or in a plant, and we're going to improve something at our workstation in the plant, it really comes from understanding how do we get, you know, we all hear these strategies from executives or even a goal from an executive, right? And to many of us, these things, they sound great and we can kind of almost develop an abstract picture of what they are. But we don't know what that means about what we have to do different at our workstation today or our work center. And there's nothing wrong with that. We all kind of think in different frames and we think along different time horizons. So depending on our level in the organization and the kind of decisions that we're asked to make, we may or may not be able to reconcile a strategy that has a year or multi-year part of it and what we need to do now in order to achieve it. And I think one of the great things that the COTA does is it breaks those things down so that people can actually figure out what must I do today to actually get the goal or the challenge accomplished that we wanted. So we think of strategies as like far off cities. And if we think about a challenge in the kind of COTA mindset, a challenge is going to be somewhere in between or somewhere on the way to the larger strategy or goal. And so what we actually want to do is develop a series of challenges, breaking that larger goal down into smaller pieces. We're going to break those down into challenges. So if we achieve enough challenges as a team, we're going to achieve the goal. But challenges are still, let's say the goal is a year long, that challenge could be four months long. That could be a lot to achieve. So I still may not know, and we still maybe as a group will not be able to break down the things that we need to do on a daily basis to meet that challenge. So I think this is why the COTA approach here is so brilliant. We not only have challenges to break down the larger goals, but we actually have a really, really nice, crisp unit that's at the daily level or at the experience level of your work every day called the target condition. A lot of people will mistake the target condition or the challenge or for the goal. Some people will use the word goal instead of target condition. I suggest that you actually stick with the term target condition because this reflects the changing nature of the fact that you are always shooting for something that you do not have. And that is important. The target condition allows us to focus on what's next, what needs to be next, what is success for this next day or for these series of experiments that I'm doing. So again, we have kind of a continuum of goal at the end, target conditions in between. If we achieve the target conditions, we'll achieve the goal. And then way back to the left, we have what am I going to do today to achieve a target condition at my particular workstation, workstream or experience that's going to allow me to fulfill a challenge. So if I fulfill enough target conditions, I'll fulfill a challenge. If I fulfill challenges, I will fulfill the goal. It allows us to orient and focus on the step by step things that matter. So this is why we want to focus our improvement to be in the size of those target conditions or happening daily. Small improvements allow for easy to assimilate change. And that means broader adoption of the improvements that we make. So we're going to get the direction or challenge. We're going to say, okay, I'm going to understand that in this case, let's say the challenge is going to be that I need to be able to complete all of the work that's put in front of me every day. That's a pretty good challenge. So then the next question becomes, what's my actual situation right now? Like, I can't get all of that stuff done. So then we have to say, this is a pretty big challenge. In other words, all the stuff done has several probably steps inside of it. It's probably not just one thing. So what we need to figure out is what is the rate of improvement that we need to have at the beginning of the day so that we can start to conduct an experiment against it to see if we can make progress towards hitting that target condition. So target condition being what is the thing I must achieve today at my workstation that will allow me if I succeed and lock enough target conditions, I will achieve a challenge. And when I knock enough challenges, I will achieve or help to achieve a larger goal for the team. So what happens is we get this, we define this target condition after we've understood what we can't do. We say that we need to be able to do it. So my target condition at a high level could be here, hey, I need to be able to get all this work done every day. So zero inbox would be my target condition. Then I would say, all right, I need to get some experiments because right now my current condition is not zero inbox. It's 1000 messages over every day. So the first thing we have to think about is the obstacles that stand in our way between us. And in this case, a zero inbox. And once we define those lists, we don't need to remember how I talked about lists. Let's not come up with more than two or three obstacles here. And what you're going to want to do is pick one of those obstacles and you're going to design an experiment for that day to run against it. Experiments need to be small, like very small. If you need to get other people involved, I don't know that it's going to be done in time for the day. And you're going to kind of violate the rule of having big experiments. So the biggest thing to focus on with the experiments is small within a day and not involving other people. That is very critical. So the next thing that we want to focus on is that when we do these experiments, we're only doing one at a time. We're going to do an experiment and we're going to come back and talk about it. So here's what it looks like actually from a coaching cycle where there are kind of like five questions that you would ask as a coach to step up to somebody who's doing improvement. And you would come up to them and you'd say as a coach, hey, what's today's target condition? Okay, well, I want zero inbox. Okay, so where are you at right now? Well, I'm at a thousand messages. Interesting. So what obstacle you think are in the way kind of of getting to that zero inbox that you talked about? And which one are you working on? So you'll list off your short list and you'll say, well, right now I'm working on the fact that I'm getting a lot of spam. Oh, okay. That's interesting. So what's your experiment? Well, I'm going to install a spam filter and see how many messages go away. Great. I'm going to come back tomorrow and I'm going to see what you learned from that. So then tomorrow when you come back is just like, you know, we can reflect on what you learned, what you planned, you know, what you learned, kind of like basically a synopsis of the scientific method, right? We make a hypothesis, we test the hypothesis, right? And then we record our observations and then we can decide whether that hypothesis was true or not. Or maybe, like most science, we'll need to actually take another step and develop another hypothesis or do another experiment. In other words, it's a process. But the great thing about this process is that there are two people involved in it. There is the person doing the improvements, the improver, and you are also in this case now talking about a coach or a mentor that comes in. And this is what I propose that we do with mental management in many cases right now, which has moved to a style that is more about thinking about the way our folks are thinking how they solve problems rather than the specific problems themselves. We don't want to micromanage our people. We want to develop their ability to think, solve problems and develop scientific language that they can share with each other. This literally undoes learned helplessness over time in people. And I think that what we find in the work environment is, is it creates a morale situation where people are like, I have the ability to affect my environment in a positive way. And it's encouraged by my management. And every day somebody shows up to see how I'm doing, doing that. And one of the large things I think at Toyota that maybe people missed at that time was their slogans were different. There was a big emphasis on putting improvement before the work. One of my favorite examples of that was a slogan Toyota had for a while, which was better cars for more people. You can see where they put the improvement. It's at the beginning, right? And it's an important thing to understand and it's very counterintuitive to us, but actually allowing your team to make time to do these experiments every day and then taking time to come review these experiments with them every day in a short period of time. We're talking about 15, 20 minute pops here. This is really powerful. And it also brings a level of engagement and understanding of where your people are at that I've not seen other things do. So very, very important. Again, link on the bottom of the resources. I really suggest that you go out and get these and I will do some more in depth kind of training for managers as we move along. So again, I want to talk a little bit about the way to roll with this. You've got to do this with your peers first management. Do not try and do experiments on your teams without understanding the moral hazards and understanding the basic boundaries of what you want to teach them and how it feels to do it. It's really important to say things like when I do this, this is what I struggle with. It really helps people to see that you're a real human being. And then the other big thing I want to talk about is try this at home. Essentially, you know, you actually can do these things at home yourself. You do not need an entire IT enterprise to actually learn how to improve systemically yourself. If you do not do this, people can tell. I see this in works all the time. I've heard managers preach about we've got to get better. We've got to apply these techniques. We have to hit these target conditions. And then one person raises their hand and asks the most feeble meek question that portrays the fact that this guy has no idea what he's doing. So all of those words about importance, urgency and all of that stuff just mean nothing to people. So what's important in all of this is that you internalize this, not that you externalize it. So not enough to direct a team to do it. Basically, your leaders watch you and they know what you know. That's the thing maybe a lot of people don't understand and they know what's important to you. So coaching is leading in this scenario, not telling people what to do, but working with them on their thinking. And I think you really, really have to evaluate how much focus is there really on improvement in your organization. It is largely free. The book is true. Quality is free. And it is a thing that we can actually embrace. But I can tell you this enterprise not free. Diane, did you survive my lecture? I did and I loved it. And it's wonderful. I'm going to, we had a couple of questions. I'm going to unmute Carl here. And I'm just going to say it's wonderful because we are going back and forth a little bit in the chat about Eric Reeves and the lean startup. And that maybe we should try and ask Eric to come and talk. I went to a couple of workshops of his and read the book a while ago. So that was really good. And I love the, when you were on the capacity to absorb the idea that, you know, with a blackberry, I think it was, you had 15 solid minutes without that. And I was clicked into my head of going that I don't want Andy Warhol's 15 minutes of fame. I want 15 minutes of undistracted time. So I didn't even think about that. That's great. I mean, the notion that you get your 15 minutes in the sun and you're looking at your phone. So Carl had a whole bunch of questions and rather than try and rattle them off, I thought I might let them just ask them directly. Hi, good morning and great discussion there I really appreciated that. And I'm also wondering if you can hear me as well. Yes, I can. That's kind of my sound check. I get I work in an enterprise environment. That's my background. I do software development. We use open shift. And as I was telling Diane a lot of the work in the enterprise is especially these days, moving old systems to. You know, that's that's what management wants, but always there's that discussion we want to embrace lead embrace. Agile. You know, and and we want we want why do they want that because they want to take advantage of the lead and the agile and the fast, you know, start up kind of mentality. Some day in the future, when it becomes important, they don't know. The problem is, of course, you're moving a very well defined system, these are just apps written in Cobalt. So that tells you how old it is, you know, how entrenched the business processes that enterprise. And it's kind of a contradiction. And how do we apply these kind of lean things in that situation. Right. So, I think what's what's interesting to me about that is is I it's often that, you know, quite frankly, it's often that I hear people say that they want to apply lean and that they want to, you know, they essentially want to get the value of lean which in a lot of to be frank. I think management here's lean and they think costs, they think the opposite of fat, and they, when they're saying agile, they don't actually mean what we think they do. Many times they mean they just want it faster. And so what has happened is management has jumped on these words. And again, to my point about how we have to internalize the understanding of these things before we start saying the words in public. And there's a lot of leaders that would be really surprised to find how much people actually understand about your, your understanding of these things themselves right. And so I think it's pretty potent that folks that that really really think about how do I do this when when people are too, you know, kind of overloading my time, they're saying these words, they don't know what they mean. That's why I really like an atom, like an atomized process like the cata, because I don't actually need permission from my manager to do this. I don't actually need to create a bunch of time. Like, one of the things I showed a network team a long time ago was, hey, listen, how about we, we make some improvements, and we don't get any permission from anybody. And they thought, oh my gosh, we're rogue. You know, we're crazy. This is going to be terrible. We're going to get in trouble. And I said, no, actually, you're probably going to get recognized. And what they did was in about a half hour day, 15 minutes at the morning and 15 minutes at night, this network team started to figure out, hey, first of all, we have a problem. We can't think straight. You know, like Diane was saying, the 15 minute interruption problem, right? Network people, it's, it's, you know, that stuff takes runways of concentration, right? Just like developing and a lot of other things we do. So one of the things they found was a real problem for them, because they didn't have any guidance from management was we're interrupted too much. Well, what's too much? Right, so then they had to come up with metrics, they had to figure out, what do I actually need, right, to be able to work effectively. And one of the things that they figured out was they actually developed a system like a goalie system where once there was like, I think there was five or 10 of them. And one day a week, one person would take all the interruptions for everybody else. And literally they would work with long runways as much as they could and only answer when they had to. Well, that had, you know, that was a series of experiments, long story short, over time, this team got an effective goalie system put in place to where team members could disappear for days and effectively work on things. And management didn't even understand that it was happening until people tried to hyper escalate around policy and go directly to people and they weren't there. Which was an awesome burn, right? Not only did they break process, right, and go direct to a person, that person was busy and everybody else knew it doing an improvement. And it was like, that was crucial. And so, again, they can grow organically, but the problem is this management can stomp it up by not giving it time, right? So I think one of the most important things is, is if we can get management to understand, it's not time wasted. This is not extra. If people feel like they're doing extra work to do improvement, it will never happen. And the benefits are small. They're not going to be like, we're not going to have a big, huge mission accomplished ceremony the next day. It literally could be, I figured out how to get 300 messages out of my inbox every week without having to do something, right? But on a line, and here's where it gets really powerful, and I'm going to actually do another presentation at some point and I'll have an interview about this with Mike. I'm hoping, I'm talking to him, I'm going to convince him to do this. But I think what's really powerful is how you can line this up with strategy in a sense that those goals and visions all have obstacles that are in our operational environment. And none of our strategies seem to really take, call them out because they're emergent. Like we don't always know they're there. And so what we need is a specific playbook to point at those things as a capability internally. And I always said to a CIO, imagine you had a strategic capability that you could point at a freaking wall and it would eat that wall down into sand over time. And by the way, they do all the other work that they're already doing. Would you use that? And they would be like, oh my gosh, you could do that? So if people start to see this kind of to your point as a way that strategy can be achieved more likely, and also that it greases kind of the rails of things to being done. I think it becomes a much more innate capability, but it has to be seen as strategic. I think that that's the problem is that in a lot of orgs, it's just seen as a tactical, why don't you lean that out? Why don't you get faster? Why don't you improve something? And it's a lot more than just a, why don't you? No, I think it's, I'm really glad that we stepped through the Toyota Cata to stuff today, because like I had done, I've done some of the lean stuff. I heard something. I've never actually seen it all broken down. And I really liked the emphasis on small, discreet things like and tasks there because I wait, and this is a red hat thing. But like our OKR is this year and our big things like last year, they were little things and they were there were too many of them or that's how we felt. And now this year we went big and grand and and it's it's kind of like we always, I always think of in the, especially in the automotive industry and the Cata coming out of that and it being a manufacturing process, manufacturing or automotive manufacturing or something. But really applying it to business practices and our OKRs for those people don't know. Those are like our yearly goals and things, metrics, things that were met. When they're really, really broad, it's really difficult to not just to achieve them and stand on the deck of a ship saying mission accomplished. It's also hard to see those even little improvements over the long the length of the time that you're doing the work. And that's that's kind of that's hard. And then you don't. So you don't you see yourself arriving at the big goal. Yes, yes along the way. So there's some really interesting concepts of the Cata stuff. I love to use Cata's at the end of retrospectives. I actually come up away with several people have to do directed retrospectives where you integrate the Cata into the retrospective so that something actually gets done and actually measured and actually broken down. So, but I think your point about the large goals, you know, achieving them can be subjective. There's a lot of room inside those goals. Right. You can say, Well, I did all these things. Yeah, I couldn't do those other things, but it was because this was so big, right. And I think I think that that it really is hard. I understand what you're saying and how do you know you're making the right efforts and right doing the right things. And so something simple is great. And I do think that your point about recognizing all of the achievements that you've made over the year are really important. I have, you know, I've told teams in this case, you know, the network team that I talked to you about, you know, they actually started to schedule just like a monthly drive by for their executive to go, Hey, we're just partying because we got these things done that you didn't know about. And here's how it helps you. And, you know, sometimes the things are more exciting to the executive than others, but he knows that they're going to come by about every 30 days because they're going to have a party because they are going to go this do this right because they have proof that they made things better for themselves and for other people. The one thing that's actually really cool is I often tell people to start focusing on their work environments because that's where all the work happens. And a lot of times there's crap there that keeps us from getting work done. So I think one of the things that's fun is when you throw some of those projects in, you can actually feel them. You feel the stress go away. And so but even then you need to remember because it just gets replaced with something else. So I think that's a really good point. So it's interesting. I mean, I've also been, we have a lot of automotive end users who are using open shift. So there's a lot of that Toyota Honda portion from Attica, Domler, getting a few because I don't know a lot about cars, but we have a lot of those folks that are in the Open Shift Commons already. So I'd love to get some of them because a lot because this is a very automotive and GM and all that was part of that and gather them together maybe and have an automotive day on. That would be amazing. And just, you know, have a bunch of like how they're leveraging the technology, plus the cultural shifts, because a lot of this and get maybe get my cup to come and I'll try we'll see what we can do. And that would be that would be a great outcome I think because, you know, and, you know, like Eric Rees I had never even thought about asking him he would be he'd be great on this and this whole transformation stuff so I'm. I think there's a lot more there and we could probably talk all day. Exactly. We could. We've hit our allotted stream time here. I'm going to do this. I'm going to share this. Actually, I'm going to ask you to share the screen if you put the link in, I think to the. The Mike's homepage here. And just. Let me let me actually bring the page up in my browser for you. I think that would be great to end on. So after you've you watched this whole thing, and I'm going to edit this down a little bit, but after you've watched this whole thing, please do go to that page. And takes me a second to bring it up here, but I will do it. Great. And I will, let's see here, let me go back and share this with you all. Because I think it is really a great site and. I think it's a great way to end too is like, you know, we do a lot of this stuff and a lot of. What we're doing with the global transformation is trying to bring all of these different practices to enterprises to all the way down. And up and down the ladder to get people to understand, you know, the languages that we're using to talk about changing cultures and shifting business practices and this is, you know. I always I jokingly go is like, it's no longer the art of community development. It's the science of community development. I just, I look at that and I go, yeah, right. You know, it is a continuous series of experiments to figure out what works right. We'll figure out so can you can you see the page here on the screen. Absolutely. This is Mike's actual personal page at University of Michigan. You can see his books here, but look at this at the bottom. It's great. He's got all these kind of videos on YouTube. He's got slide shares of all kinds of people that have, you know, he's done this if you go up on look on slide share and other places you'll see other people's internal presentations, which can be awesome. There's an online course. It's for three hours. I think that's amazing work actually being used in education pretty cool teaching problem solving or actually not problem solving scientific thinking at a young age. So yeah, there's also a whole thing for educators and that they do have a conference practice, you know, the practitioner days are real things. So yeah, I just think it's a wonderful community and I love the fact that it spans application across industry. It's just fun and I've used this quite a bit of my own life for my own health. And and that's kind of how I found some of the power of it myself personally so it's a very, very, very powerful set of thoughts that will encourage everybody to binge watch. And Toyota Cata videos over the weekend and come back and tell us what they think. So, again, Kevin, as always, thank you very much for your time. And we're really thrilled that you know, you guys from the GTO are part of the red hat team and sharing the wealth of knowledge that you bring to the to the table here. So, with everybody in the community. So, thank you very much. And with that, we're going to sign off. I believe if I tell Chris go bumper it. And that should be it. So, all of those freaking notifications flying across my screen. I have no idea what they were. Don't worry about it. I can either. I can figure it out in the edit. Half of them are probably my girlfriend screaming about something she's pissed at. I saw some f bombs fly by so I'm not sure what that was. I apologize.