Episode 16 - Operational Learning (part 6)

A HOP Podcast (With No Name)

We wrap up the operational learning mini-series by going over what happens after you define the problem statements.
(Transcript Start)
[00:00:00] spk_0: This is Andy and this is Matt and you're listening to
[00:00:03] spk_1: the Hop podcast with no name. What a dumb
[00:00:07] spk_0: name. So stupid.
[00:00:22] spk_1: And we're off, it starts episode 16. Welcome back. If this is your first episode may make sense to you. I think it should. I hope it does. But yeah, we're excited. I think this is gonna be the thrilling conclusion to our operationally learning operational learning miniseries. Is
[00:00:49] spk_0: it the conclusion part that we're curious about or the thrilling part?
[00:00:53] spk_1: I hope it's thrilling. It's definitely concluding. I hope it's thrilling. I've had enough of this personal learning talk. We're gonna switch it up, but we'll start where we always start,
[00:01:05] spk_0: which is homework
[00:01:07] spk_1: from reviewing the homework,
[00:01:09] spk_0: not giving
[00:01:10] spk_1: it, giving homework and hope it makes sense by the end. So last episode, we talked about being in a meeting and someone throwing out a solution to something and stopping and asking the statement or the question, I guess what problem are we solving for when we were given that solution? And so we talked about it. I think you have a really good example. Hopefully, I mean, it could be terrible. Well, I mean, we're going to
[00:01:41] spk_0: find out. Yeah, we'll find out. Well, we do it all the time in our work world. Right? I mean, in every single meeting that we have when people are saying, hey, I'd like to set up this type of engagement with our employees or leaders and we're always trying to find out what problem they're trying to solve with it. But that is kind of boring in comparison to other times that we use it. And the example that we came up with was actually, um, trying to get my oldest daughter to enter a gymnastics class that she was not willing to enter. So it is a class that is run. Yes.
[00:02:17] spk_1: But at this stage in case people aren't keeping a score at home. Two daughters, the oldest one is about 3.5. We're talking about the oldest one.
[00:02:27] spk_0: So we're talking about a 3.5 year old that doesn't want to go into a gymnastics class without her mommy or daddy and mommy and daddy are not allowed in the gymnastics class. We're allowed to watch from the window, but we're not allowed into the room.
[00:02:41] spk_1: Oh, that'd be great to see though. It was just a bunch of 3.5 year olds and you trying to do it, trying
[00:02:46] spk_0: to do a forward
[00:02:47] spk_1: role so much better than,
[00:02:54] spk_0: um, and she didn't want to go in. And so my husband and I were throwing out various ways that we could approach the problem? Like do we just tell her she has to go in? Do we just put her in the room? Do we just say, do we bribe? Do we threaten? Do we not go in at all? What do we do? And uh in that conversation, we realized that that was highly dependent upon what problem were we trying to solve? Were we trying to solve the fact that we had paid for a class? And our daughter was not participating in that class? Were we trying to solve for teaching a lot of following through and keeping your word about what you say you're going to do? Are we trying to solve for teaching a lesson about being brave and conquering your fears? Are we trying to teach her that when she is afraid of things and can articulate herself well, that people will listen to her? Are we trying to give her the peace of mind that she won't be forced into a situation that she's super uncomfortable with when she's with people that she loves? And we had to actually like sitting on the floor next to a window in a room full of other parents with a bunch of kids doing gymnastics. We actually had to talk through that together to figure out what we were trying to solve for. And then that changed our solution side of what we were doing
[00:04:24] spk_1: and in the spirit of thrilling conclusions, what what did you
[00:04:29] spk_0: solve? It was a combination of two things it was solving for the fact that we wanted to teach her that if she articulates herself well and can explain how she's feeling without crying and screaming that people will listen to her as well as uh having confidence that she can conquer her fear. So we actually spent a significant portion of the class sitting on the floor with her, having her explain what she was concerned about and why she was concerned about it. And then coming up with solutions together about how we could maybe make that better. And then explaining how good it feels when you do something that you were afraid of and you, you prove to yourself that you can do it. And so it took us 20 minutes of the class. But for like the last 10 or so minutes, she got in there and had a great time. It's a great
[00:05:18] spk_1: ratio for 20 minutes, talking 10 minutes doing gymnastics in the class you paid for.
[00:05:24] spk_0: But obviously, if our, if our problem statement was different, um then the solution would be different, right? If it felt like we needed to just solve for, hey, we paid for this class and you need to be there and you know, follow through say do ratio, then then the way that we would approach it would probably have been very different.
[00:05:38] spk_1: Yeah, and and it still could have worked out well. Doesn't mean, it would have been terrible if you would have just said, hey, Penelope, this is your, you're in, this is your class. You will be back in 30 minutes or so. We'll be just outside. But you are doing this class. It probably would have been five minutes of screaming and crying and then knowing Penelope, she would have jumped right in at minute six and enjoyed it. But it wouldn't have taught her much besides that. Sometimes you get abandoned and you have to do
[00:06:05] spk_0: things. Sometimes you got to do things. Yeah, which is fine if that's the lesson that you're trying to teach at that moment, we just had to get clear on what we were trying to accomplish.
[00:06:13] spk_1: You said something really interesting and now we're just talking about this situation in very great detail, which was uh she'll have plenty of chances to learn that life sometimes isn't what you want it to be. Yeah.
[00:06:24] spk_0: That's actually why we decided upon what we were trying to teach is that life teaches you the hard way that you have to do things that maybe you don't want to do and you have to follow through with them. And so we decided that that was not the lesson we were going to double down on in that moment in time. All right enough parenting advice, Andrew.
[00:06:44] spk_1: That's enough. I regret asking all these questions. All right. So we, we said we're going to wrap up operational learning the mini series. And, um, we, we settled on basically the, and now what, after we define problem statements, which I think is actually where we get a lot of our questions. Once an organization has started doing operation learning, like if they're doing it and they really lean into it, sometimes it's, hey, we've gotten so much feedback. We have so many problem statements, we don't even know what to do. We can't tackle them all. What do we do now? And sometimes it's just getting started and, and feeling like you have a lot of good ideas and no idea of how to action them. There's, this feels like a place, a lot of people get stuck and we hear about this quite often. So we're going to hopefully help some people get unstuck.
[00:07:36] spk_0: We're gonna try at least, um, if you do operational learning, well, it does feel like you're drinking through a fire hose and then you're taking all of that mess of information and trying to break it down into some amount of problem statements. And then even then it feels enormous because there's many, many problem statements. Um, and oftentimes we then get to a place of like, ok, well, what do we do with all of this? And in general, in any sort of operational learning that the thought process is that you want to work with those that are close to the work to brainstorm solution sets, which we talked a little bit about at the end of last episode of like ways to brainstorm solution sets. But sometimes I think that's where people get stuck. Um, meaning that if in that moment in time, that group of people that you're talking to don't have ideas, then people are like, well, what, what are we supposed to do next? There's usually some amount of ideas that are available, right? People are willing to throw around some solutions to some of the problems, but you usually can't address all of the problems that you have identified in the window of time that you have with the folks that are in the room. And so I think maybe it's important for us to, to just state that depending upon the problem, you might need to do a lot of different things. Like one problem statement actually might be the problem statement for a entire working team that needs to be put together to address it. One problem statement might be something that you've been wrestling with for like 30 years and it hasn't gone away yet. And just because, you know, five or six people in a room can't come up with a solution set immediately, doesn't, it doesn't mean that we shouldn't acknowledge that it's a problem, um, or that we give up on it, but it's ok if we can't come up with solution, that's immediately, those are some of the times where uh doing the crowdsourcing becomes really helpful. Other times you have problem statements that the folks in the room have really, really good ideas that you can just go try out. But there's going to be an absolute variety depending upon the problems that you come up with. And one way to help separate it out, which I used to use all the time. And I know a bunch of organizations use now um is as you're trying to brainstorm some ideas, one you get really specific with which of the problems it's trying to address, right? So that's important. But also that we start to label the ideas as to whether or not they fall into the team, whoever you're talking to the team sphere of control, their sphere of influence or their sphere of concern. So three spheres, if you will.
[00:10:21] spk_1: OK. All right. Uh Examples, please. What would be um a situation that would be in my sphere of
[00:10:31] spk_0: control? So sphere of control would just mean something you can actually affect change to yourself. Like you don't really need somebody else to uh prove it, you have all of the tools, decision rights, ability to change it. So if we're talking about like, hey, we need to make a small maintenance change to a piece of equipment and the maintenance person who would do that is sitting in the room that is gonna be within the sphere of control of the team to go do
[00:10:55] spk_1: it. Gotcha. And for me, I have the ability to write whatever I want on my calendar. For my own notes, I can do that myself.
[00:11:04] spk_0: You can, that is within
[00:11:06] spk_1: their notes about you and you can see my calendar, but that's irrelevant. So that's sphere of control, sphere of influence.
[00:11:14] spk_0: So sphere of influence is something that you probably don't know, have the decision rights to execute yourself or the resourcing to execute yourself. But somebody really close to you does um And they usually have their ear and all you have to do is go have a conversation with them. So same example of uh maintenance needing to be done on a piece of equipment. If that maintenance person is not there within your influence as one of the people on the team or even the facilitator, you can go talk to the maintenance leader and be like, hey, we really need this scheduled. This is the problem that we're facing. Can you please schedule it?
[00:11:51] spk_1: Got you ok. And then concern where it gets, this gets very broad.
[00:11:55] spk_0: Yeah. So sphere of concern, I'd say there's like a couple big categories of sphere of concern, one of which it is actually in the organization as a whole, it is in their sphere of control, meaning there is somebody that exists within the organization that could do something about this problem, but they are so far away from you that it's even hard to figure out how you would get there. Um In this case, like it, it could be, hey, we need to completely redesign, um, the staffing process that we have for how this work is being covered and that is controlled by somebody in a corporate function that you have no idea even who that person's name is. And it's tied to a bunch of other pieces of the organization that you're not exactly sure how all of that works. So that would be in your sphere of concern, but not something that you exactly know how to tackle or influence or it could be outside of the organization's control entirely. So like an environmental factor that the people within the company can't control, right? So um like COVID is something that would be in our sphere of concern. Um but not necessarily like the impacts of that on a supply chain. Um depending upon where you are in the organization, you might not have direct influence or control over that, but certainly it affects you and it's in your sphere of concern. And then there's like a this other large category of it's concerning to us, but, but maybe there's nothing we can do about it. Meaning sometimes the things that we identify are just wishes that we have about like humanity being better, meaning like we wish the way that people operated was different from the way that people operate. So like a simple example would be um we wish people were not risk normalized to things and like the problem is right that people were risk normalized. And then you could say, well, how do you address that problem? I I it's part of how humans operate. So as we talked about in episode two, you can design something to fail safely, but in terms of directly affecting whether or not somebody gets risk normalized, that's just wishful thinking about wishing humans would be different. So that would be in your sphere of concern, but certainly it's not in your sphere of control or influence to change the fact that humans become risk normalized to things over time with experience. That's just we take that as a given, that is a given input into our system and we're not going to be able to address it directly. We're gonna have to address it tangentially in this case by allowing something to fail safely when that does happen. And,
[00:14:36] spk_1: and anytime we're doing operation learning, each person has a different set of sphere of control, influence or concern, right? So if leaders in the room that's running the learning team, for example, they might have a different layer of control and influence than people who are directly tied to the work. And so we have to recognize that and I assume that everyone's is equal, that's correct.
[00:15:00] spk_0: And also that's a way of kind of navigating through this part of operational learning, like sometimes just using, you know, non fancy language within the the context of operational learning, the way that we would say, like, what ideas do you have? We would say, like, do you have any ideas that are in our control to do? Like, here's some of the problems we have. What ideas do you have that we could go do tomorrow? Um And that helps people start to think about things that are in, in their own sphere of control. Um And we spend less energy worrying about the things that we actually probably don't have a lot of control over.
[00:15:36] spk_1: It also changes one of the big narratives that we hear, which you have no idea where I'm going and I'm so happy about that. I love it. Um One of the constant pieces of feedback that we get when we're teaching operational learning is essentially I boil it down to, well, I don't have an unlimited budget or resources if they're typically we're talking to leaders and they're, and they're going to hear how their teams are doing operation learning. They, well, I don't have all the budget and resources
[00:16:02] spk_0: to make this. Can't redesign everything. We can't poke yoke the world.
[00:16:06] spk_1: You want me just to buy new maintenance vehicles once a year. That's impossible. And what happens is when you're asking like you just did the people close to the work, what they can go and try their solutions are typically not. Uh I can try and go get $5 million to go buy this new tool. It's almost always like, oh Yeah, I think I can make something and I can uh hey, actually, if, if we just simply redesign this one thing, it, it take like half an hour and we should try this first. Their solutions aren't typically multimillion dollar solutions. Sometimes the only way to make an improvement is something that needs to be done on a larger scale. You tell a story very often about needing to replace maintenance cars that can fail safely. Not much more you can do to get around that. But other parts of operational learning can be done by just small tweaks. And if you ask someone who's that close to work, what they can do to change it, it's typically not 50 100 a million dollars.
[00:16:59] spk_0: Yeah, because they're thinking about the solution sets that are within their own control to do, which depending upon the dynamic of the organization, oftentimes those of us who are closer to the work, we do not have access to $5 million right? So obviously, the way that we're brainstorming is going to be on a different level in terms of resourcing and also the people who are dealing with the problem day in and day out, they're thinking about the problem day in and day out, which means that they've had a lot of time to start to come up with ideas of a man. If we could just do X or Y or Z, all of this would be much better than it has been. Um So we want to tap into all that creativity that said, I think sometimes when we do operational learning or learning teams, people that are facilitating it, get stuck or frustrated because we can't solve every single problem that way. And so they'll say, yeah, well, I mean, the team was able to solve some of the stuff, but we still had really big things that were problems that nobody had any ideas for or nobody could fix. And in those circumstances, the nobody oftentimes is just referring to the people who were on the team at that moment in time. And what we want to remember is that those problems, they may have to be passed to other people in the organization who have a different sphere of control and a different sphere of influence than those that are on the team. Some organizations have really good methodologies to pass problem statements from like one level of an organization to others and others have no methodology. So if you're in a organization that doesn't do that very often with anything with any sort of problem, it becomes, uh it becomes difficult to figure out how to do that. Um But some organizations like that, um ascribe to lean practices, they have tiered meetings and those tiered meetings allow you to pass information from one part of the organization to the other on a fairly routine basis. Um And so it makes it a little bit easier to tie your operational learning problem statements into, into that so that you can get it to the right level of the organization who then can action something different. So
[00:19:05] spk_1: anyone who's listened to the prior episodes knows that I studied industry and I lived it for what, five decades or more. Um But why don't you just briefly explain what a tiered meeting structure looks like?
[00:19:21] spk_0: Yeah. So it's just different meeting levels based on different levels of the organization. So the folks that are closest to the work have one tiered meeting and then the people that are managing that work have another tiered meeting and the people are that are managing the rest of that organization have another tiered meeting. So in sort of a traditional organizational structure, um you have the ability to pass information from, from the folks that are tangibly touching product all the way to the people that are making resourcing decisions for a plant or sometimes higher. Um in order to make sure that you get the right information to the right people that have the decision rights to make a change.
[00:20:01] spk_1: Yeah. And the one thing that I'll echo that we hear so often from the people doing the work is just the need for feedback when a problem can't be solved by that group and it needs to go up those tiered levels. It's not just, hey, thanks for telling us, uh we're gonna fix it maybe in the next 12 to 70 months and you'll see it when it gets fixed. It's how do we make sure the communication gets back down to that group? And so that they're aware with it, we, every organization does it differently but the ones that do it well, tend to have the most buy in to operational learning because it's just, it feels impactful. You feel like, even though maybe you're not the one making the change, you had a direct impact on something that's going to be broadly changed.
[00:20:43] spk_0: And there's some organizations that they don't have any of that structure that already exists. And in, in that case, they've gotten really creative with how they pass problem statements to each other. So for example, you might have um a bunch of learning teams that are done across a bunch of different locations or, or service groups and they tackle whatever they can locally. And then once a month or once a quarter, a corporate team asks for problem statements from them that were never fixed. They said, hey, what are some of the things that you identified in your learning teams that you just don't have the resourcing to cover? And they pass that information to this corporate team and the corporate team sort of sorts through it and starts to see if, if there's any commonalities, but between these different groups so that they can then put some resourcing into doing some, some pilot studies of how how can they make a change? One company did that with, with their forklift design of they made small changes locally in terms of like where things physically were in a warehouse and how people were interacting with the forklift, meaning like were there people and machinery in the same place? But then in terms of the actual design itself, of the types of forklifts that were being brought in and the types of aftermarket availability of, you know, any sort of safety features that were add on to the forklift, all of that had to be passed to the corporate team who then could provide some amount of piloting and resourcing for those technology options. Ok.
[00:22:11] spk_1: So we, we've now wrapped up, I
[00:22:15] spk_0: don't think it was riveting enough or thrilling. Was that
[00:22:19] spk_1: well, we're gonna, we're gonna, we have one more place to go, but let's just quickly recap. So the uh problem statements are identified. We have ways that we're going to try TRM solutions that are within our control. We're going to talk about the people that have, we have influence or they have influence within the meetings to go and continue to make change. We have feedback loops. We recognize that every problem cannot be solved and that some things are just human nature, but we got to find ways to work with that, not against that. Um But we wrote one thing on the bottom of a note we wanted to cover before we end today, which was today's solutions, create tomorrow's need for learning. And so it's all about the idea that when we try something new, there's no way to recognize every impact it's going to have and that other things will then have a change that might create new problems. But I'll let you talk about that, the dancing landscape that is a complex adaptive system and we add solutions to that.
[00:23:13] spk_0: So we've talked about complexity on other episodes. And we probably mentioned this idea of a dancing landscape. But in a, in the complex world that we live in the solution sets for things are not stagnant. Meaning that if you were going to try to mathematically map a solution set, what it looks like is a, is a moving mountain range where a peak which would represent a really good solution can become a valley which would represent a really bad solution and a valley can become a peak because there's other variables that are constantly moving. And so what we want to keep in mind anytime we're operationally learning is because we're not in this ordered system, we're not trying to just fix something. And then if we fix it, everything is pristine and works like a well oiled machine all the time. We're trying to make improvements for the conditions that exist today and we're constantly learning and monitoring what is happening because things are going to be constantly changing. So the idea of creating resilience creating, you know, systems that can be resilient to humans, doing human things and not have catastrophic failure. A big piece of that is remembering that it's about the speed with which we can learn and improve, not trying to make something perfect and believing that that perfect is going to last for forever. So those feedback loops then become incredibly important, actually becomes the lifeblood of how you run an organization this way.
[00:24:35] spk_1: And we're talking about work and complex adaptive systems because you just said perfect is not going to last forever. And we don't want to ruin everyone's hope of a good life. We're just talking about when we make solutions at work, we hope you all are happy forever. Um Do we, do we have homework?
[00:24:52] spk_0: I mean, I think we should, we should absolutely suggest that when you're in some sort of meeting in which solutions are being thrown around or perhaps even in your personal life that you just take a moment and map out whether or not the solution sets are within your sphere of control, your sphere of influence or your sphere of concern. And if you find that all of the potential solutions you have for a problem are only within your sphere of concern, then the suggestion is just to go back to the drawing board, right? Because we want to make sure that we have some amount of actionable things that we can do. So we don't just get stuck saying, I wish this was different. I wish somebody, somebody else would solve this problem for me that we have something we can do within our own sphere of, of control or influence. And so we keep brainstorming until we can come up with something.
[00:25:44] spk_1: Awesome. Well, that's it. Thank you all for listening. Episode 16 in the books. All done. Operation learning miniseries in the books. All done. And we'll see you next time.
[00:26:02] spk_0: Well, that's
[00:26:04] spk_1: it. Yep. Another one in the books. We did it.
[00:26:09] spk_0: If you, uh, wanna send us any of your thoughts, actually fling us any of your thoughts you can do so at the website www dot hop podcast dot com.
[00:26:21] spk_1: That's Hoppo DC A ST dot com. It's still
[00:26:28] spk_0: such a stupid name. A stupid.
[00:26:29] spk_1: We look forward to hearing from you. Thanks for listening.