The Leadership Exchange
Discussions on Real-World Leadership for professionals. We explore several topics about leadership and getting the best from your team to deliver amazing results while creating a great environment for them.
You can contact and follow us on Instagram @LEADERSHIPEXCHANGEPODCAST
The Leadership Exchange
S3E9: From Symptoms To Root Cause - A Leader’s Guide To Problem Solving
Ever feel like your team is playing whack-a-mole with issues that keep coming back? We dive into a practical, leader-ready system for turning chaos into continuous improvement by defining problems clearly, separating facts from opinions, and focusing on prevention instead of blame or endless reminders. Along the way, we unpack Taiichi Ohno’s challenge, “Having no problems is the biggest problem” and show how that mindset shift fuels better safety, quality, and performance.
We walk through Toyota’s seven-step approach, a simple five-question problem matrix that aligns stakeholders fast, and the essentials of Five Whys without getting lost in analysis. You’ll learn why containment is only a first step, how to design the right cross-functional team with a clear champion, and how to keep scope creep at bay with a disciplined parking lot. One story brings it home: daily inspections felt responsible, but a small preventive change delivered a real fix—proof that the right problem statement can reveal an elegant solution.
If you lead people, run projects, or care about operational excellence, this conversation is a playbook for smarter decisions and fewer repeat failures. You’ll leave with tools to clarify the problem, find the true point of cause, test countermeasures, and standardize what works—so improvements stick and your team stops fighting the same fires. Subscribe for more leadership tactics, share this with a teammate who loves root cause work, and leave a review telling us your best Five Whys win.
Follow us on Instagram or on Threads @LEADERSHIPEXCHANGEPODCAST. We'd love to hear from you! What topics you'd like us to explore with you? What questions on our topics do you have? Say hello and start the dialogue!
Hello everyone, this is Lupe Munoz. And I'm Steve McKeon and welcome to the Leadership Exchange. This morning we're gonna talk about a skill set as a leader that's not associated usually to leadership, and that is problem solving.
SPEAKER_00:Yeah, Lupe, I think that's such a critical skill for leaders to not only have the ability to do good problem solving, but to teach others in organization that either are peers or that you know are part of their direct support group how to do excellent problem solving. And it's you know, it sounds like it's kind of an intuitive, easy thing. No way. But yeah, you can really get off the rails quick. One of the things you and I see a lot is people go in thinking they're doing problem solving and they're just kind of playing whack-a-mole, throwing solutions at things without really having started what we know is the important first step. So you want to walk us through that, um, Lupe, or maybe start off with a little bit of a story about problem solving?
SPEAKER_01:Uh unfortunately, I don't know that I can start off with the with the story because I think if if someone doesn't really understand the the elements that we're gonna talk about, then the story may not have the right context. So I'm gonna save the story till maybe a few minutes into this podcast episode because uh I think then it'll be more valuable to our listeners. But for this discussion, we're really gonna talk about some key things when it comes to problem solving. What one of the most important things, which would be hey, how do you identify the problem? Because there's a lot of people that identify the symptom, or yeah, I'll say the symptom, but they don't really drive to what the root cause is, what's the true root problem. And so we'll talk a little bit about that. The importance of picking the right team, and and there is definitely a critical element to that, and then making sure everyone's aligned to the problem is is super critical. Otherwise, you get people going in all different directions, or there's just not that, I guess, that synergy that can happen if you get people aligned. We we also talk about when you're doing your investigations, you gotta sift through the the minutiae of information and understand what's actual facts and what are actual opinions. I think that's that's just a highlight of some of the things we're gonna talk about. But let's talk about problems. First of all, most of us counter problems, right, Steve? You you and I see that often. There's problems that are very obvious. Someone gets hurt, we have a big product issue because of something that happened. But then one of the things that's missed a lot is okay, everything seems to be going well, but we don't have any problems. And that is to me uh one of the traps that can happen. And I we're both a fan of Taiichiono from Toyota, Steve. You've got the quote, I think, for that particular reference that I'm talking about. Would do you want you want to share it with people and kind of explain to people what that's all about?
SPEAKER_00:Yeah, one of Taichiono's practices was to go into different uh facilities and ask the leadership team in those facilities what problems or what issues are they facing? And the response a lot of times was uh everything's okay, there's there's nothing really out there. And you know, his response to that was having no problems is the biggest problem at all because he knew that wasn't accurate. He knew there were things that were causing the teams that he was overseeing at Toyota to be less than optimal. He would challenge that statement every time uh with that quote, having no problems is the biggest problem of all.
SPEAKER_01:The interpretation of that too is that hey, you can always get better. So for you to say you don't have a problem means that you don't feel you can get better. And I think that is for me, was one of the biggest sort of drivers for having our team continuously improve.
SPEAKER_00:Yeah, look, let's talk about that for a minute too, because we title a course problem solving, but you could also title it continuous improvement, right? Because I think one of the the misnomers out there as people go into a continuous improvement opportunity, they're not recognizing it as we got to define the opportunity that we're going after, same as you have to define the problem. And many times when they don't, you have such ginormous scope creep in what you're trying to do with the team that you never get anywhere. People get frustrated because either they're what they think they're working on isn't they don't see any real progress, or other folks know that hey, we're really off track. And so I think that's really critical, you know, and we'll talk about that in a couple minutes. I think the next thing to really go into a little bit is some of the classic steps with problem solving, continuous improvement that companies take and where maybe they fall short. You want to cover that?
SPEAKER_01:Okay, so usually they they see something that's a problem to them, they see it. They immediately take, like I'll I'll say containment, though they'll try to contain the problem. Like, for example, a pallet falls on its side, let's say. Well, there's a mess I got to clean up, right? So I'm gonna contain that the the spill, I'm gonna I'm gonna contain the situation. But then then usually, at least in in the past with some of the teams that I've joined, the the first thing that they they'll say is like, well, we've got to tailgate or we've got to do a toolbox talk on on this incident. And I'm like, okay, that's good, you know, trying to get people aware. And I'm like, okay, what else do what else do we need to do? And they're like, well, we'll just make sure that they know that they got to do a better job. And I'm like, wait, what, what? They're like, yeah, you know, make sure to remind them, hey, you guys gotta make sure uh to be safer on on the forklift when you're moving a pallet. And I'm like, okay, what what do we think that's gonna do for us, right? And what a lot of people are not understanding is when you say that, when you say that, hey, my fix is telling people they need to do a better job, or hey, you need to be more careful, or hey, just a reminder, that is not doing an iota of improvement for you, right? That's that's really the message you're saying is like, hey, you the people are the problem versus saying, hey, you know what, we we need to take a look at our process. Like, what are what is our process? Do we have standards? Do we have a requirement? Should people be only moving pallets at a certain rate? Should we be using straps? Why is that pallet tipping over? Like, is it top heavy? Should we be limiting the size of the pallet, you know, as far as the height of the pallet load? So there's so many things that we could be doing, but a lot of times the teams default to, hey, we're gonna tailgate or we're gonna have a toolbox talk with the team, which is really that vicious cycle of we we don't address the root cause and and we just put a band-aid on it and we just move on. And then surprise, surprise, we have another incident in a few months, in a few weeks, or in a year, but but it's like this repetitive pattern. And part of what we're gonna talk about today, Steve, you can really take us there is you got to break that cycle. There, there's something super critical missing in in my explanation of the pallet incident that you're gonna shed some light on, Steve.
SPEAKER_00:Yeah, and I think the cycle that you're talking about, Lupe, is we all want to get to that immediate containment of the problem because we we feel like we've got to do something. And a lot of times sharing the information, as you mentioned, through some form of uh tailgate or just in general uh communication makes us think we're done. Everything's okay now, everybody's aware. We put some short-term corrections in that location, right size the pallet or whatever, whatever it is for that one time, and that's where the cycle really is gonna come back and get you again of not having gone through enough detail to understand what that root cause is. So, by all means, you got to contain situations when when problems happen. Um, if you're if you're really in a true continuous improvement cycle and you there's not anything to contain, you have a little bit more luxury to look at things deeper. And then that's kind of the next step, Lupe, that we're talking about is how we go in and really understand what that root cause was of that situation, but really back in front of that is to define the problem. What problem are we trying to solve and really get you know that alignment? And part of that really comes in uh through the process. Lupe, you want to walk through this next step? It's the uh seven-cycle process that we both learned, you know, from uh from Toyota that uh we continue to practice this day.
SPEAKER_01:Yeah, the the credit goes to the Toyota production system. They Toyota developed this process and refined it, and now it's kind of like one of those, I I'll call it best practices when it comes to problem solving. And the steps are you know, you get the initial uh identification of the problem, but then you clarify the problem, like what is truly the problem? Um, then you you really start to focus on doing your five Y, you you get the point of cause, then you do your your investigation, a causal uh chain with five Y's. You could do other things too, but that's kind of the main tool that's being used. Then after that, you're putting in your countermeasures, which a lot of people see as call solutions. You're gonna evaluate the effectiveness of those things, that whatever countermeasure you put in place, and then once you find something that's working the way you need it to work, then you standardize. So you you make it permanent. And you know, there's a lot of other tools that you can use in conjunction with this, right? There's a PDCA cycle, plan to check act, or plan to check adjust, and then there's the wheel of sustainability, which is a book that I we highly recommend when it comes to sustaining improvements in in the work area. But we're not gonna go into those two tools, we're just gonna talk about problem solving. So, first step of problem solving before you like, okay, you identify the problem, you're gonna have to get a team together, right, Steve? What are the keys there?
SPEAKER_00:Yeah, I think the most important thing, it should be the the senior most leader uh working by themselves, looking at the problem and coming up with their thoughts and corrective action, and then telling the team what to do next. Um, is that typical, Lupe? Is that the the path that you would recommend?
SPEAKER_01:Um Steve, Steve, I I said what would you recommend, not what is the worst thing someone can do. I know I know you're trying to set me up there. I you it was kind of one of those aha moments you were trying to, or gotcha moments or something. But no, that's absolutely not what you and I know you're joking, but describe what really should happen versus what should happen is you've got to get the people that are most knowledgeable about what situation has just occurred or what improvement barrier you're gonna try and work through.
SPEAKER_00:And and typically, you know, that's gonna be a team of uh anywhere from three to ten people. And notice it's not one or not two, it's you know, getting to that magic number of three really helps look at the situation from a couple different angles. You got to have someone designated a champion, someone's got to be the leader of that group, and then at that point you start looking at okay, what are the subject matter experts we need to really understand this? So let's say it's an incident or an accident in an uh organization. Well, for sure you need to have the supervisor from that area, but you also need to have the person that went through that event and a and maybe a team member or two that are familiar with what happened, and then you're gonna want to maybe look at uh depending on the type of event, you know, some other subject matter expertise from maybe your facility maintenance team, maybe some folks from your quality team. So you can really put together a smart team of folks that are gonna be able to go in and look at this uh event with a critical eye. Same thing on continuous improvement. If it's an opportunity to improve something, you're you're doing that same exercise. And this is where you know people rush in, they get they do the containment thing, and then they don't come back and make sure that they've put this team together to really look at uh the problem and and get the team starting to put together root cause analysis. Um the the other thing I would say, Lupe, and and we get asked this a lot um as you pick the team, is it the same team forever? And the the answer is no, or could be, but can have people come and go on the team that are subject matter experts because you just need a little bit of knowledge from them in a certain part. The the core though is that person that initially gets assigned as the champion, that person should probably not be changed out. And you need to make sure that they're the ones that are empowered to bring this thing to closure. And then, you know, at least two other folks typically that are at the early uh start of that process are are probably gonna write it through. But let's say your team is eight people, you may flex in and out that number could expand up to ten because you decided through your root cause investigation there's some additional information you need in the team that you've got assembled as not the subject matter experts. So you're gonna look to bring in one or two other resources potentially, and when you start getting down to finalizing, you may get back to that core of you know those five people uh to really kind of land on agreed to root cause analysis and uh you know the different causal chains that uh were identified, maybe some additional work that needs to be done, separate that from what you're trying to solve, and get back to additional things that typically come up in, especially on a larger problem.
SPEAKER_01:I'm gonna I'm gonna reiterate that a lot of times like problem solving tends to get uh only done by a management team, right? There's this perception that the higher you are with the title, the better problem solver you are, and the more valuable you are to a problem solving process. What you said was was the key, and that's that you know, subject matter experts doesn't mean like you have to get the vendor in that that made the machine. It means the people that are actually working with the equipment or working to do that process or task, those are the most valuable people, especially the person that was actually there when it happened. A lot of times that does not happen, and it's it blows me away that we're people are leaving so much um because then they leave things to assumption, and that's that's the next step is like, okay, you have your team assembled, Steve's advice about that, and then you want to really talk about the problem. And before you talk about the problem, you you gotta start with I I I like to ask the team, hey, okay, what do we know? What do we not know? Right. And someone will say, Well, I think this happened. And I'm like, Okay, why do you think that? Because think is an opinion, but it doesn't tell me that it's a fact. So I want to know why you're saying that. And a lot of times the this way of questioning can come across as like you're grilling somebody, so you gotta make sure that you let people know up front. Hey, I'm gonna ask a lot of follow-up questions, I'm gonna I'm gonna challenge some of the things, and this is why, because I want to get to I want us to get to the facts, because only facts will be able to get us the right problem solving results, not opinions. Now, if if you end up where you don't know what what happened, like there aren't enough facts, then yeah, then you're gonna have to go with, okay, everyone give their opinion on what's the most likely thing that happened. And then let's go and try and fix that. But you only do that when you you're like absolutely at a loss. You there's nothing that's gonna give you the facts to determine what actually truly did happen, then okay, I could see that. But a lot of times there's a lot of people that will state things as facts. Like I was in a situation where a pump had failed and there was a diaphragm inside that pump. So if you can think of like a rubber disc inside there that basically flexes, and that that does the pumping inside this particular pump for this machine. And the first thing that I heard when I asked the question, hey, what do we know? What do we don't know? was one one of the mechanics that was there was like, oh, the operator broke the pump. I'm like, okay, why do you say that? Well, because they've done that before. I'm like, okay, how do they do that? Well, they overpressure the machine. Okay. Then I'm asking people, hey, do we know if we overpressure the machine? Well, no, we don't we don't know whether the the machine overpressured or not. I'm like, okay, so that's an example of, hey, that's something we don't know. And I I bring that up because in the end, we we said, hey, if that's what we think happened, then we need to demonstrate that to ourselves. We need to prove that to ourselves. So my question was like, okay, do we have a way to measure it? Can we implement something that would help us measure it? They're like, yeah, we could put a pressure transducer and then we can start monitoring and see what happens, and then we can see if the machine actually overpressurizes. Excellent, beautiful. But you know, the mechanic initially started with an opinion, and we ended up going to it's still an opinion, that doesn't mean that's what happened, but now we have a mechanism to to separate whether that's a correct opinion or just an opinion that in this case was not correct.
SPEAKER_00:Yeah, Lupe, and I think as a leader, as you're you know, let's say you're the the leader that's so that's working on solving that problem. It's really important to, as you mentioned, separate the fact from opinion and and to do it in a respectful way because the the challenge is when you disagree with someone's opinion, that can also shut them down from participating anymore. So you definitely have to do it with some some grace and some skill, but it's so critical uh to do because if you let just the opinions uh run the meeting, you're gonna come up with a lot of corrective actions that may or may not be relevant to your point. Let's talk a little bit about one of the tools that you and I started using several years back that help teams define a problem. And it's a real simple tool. It's got uh five steps in it. It's think of it as a problem matrix. We're gonna go through this uh real quick verbally, give you a sense of how it works. The first thing is to say to the team, what is the problem? And what happens when you do that, you'll find that, and you have everybody write it down, or verbally state it, and someone writes it down, is that there's a bunch of different opinions about the problem. Good example is uh one that I like to use is you know, someone is walking and fell down, hurt their knee. And in a problem solving statement, people are going to really expand on why the person fell down. Well, they they probably tripped on something. Oh no, maybe they had a medical condition. Perhaps they were reading their their phone, and so we're not even getting to the first step, which is what is the problem? The problem is a person fell down, hurt their knee. And it's that simple, and that's just I think a good example of what we were just talking about is is when you don't know, you it's a human tendency to fill in some gaps just based on your own experiences, that now suddenly start to bias the first the start of the process. So as a leader, you gotta be really good at saying, okay, wait, what happened exactly? That is what we want to get to. And then the next part of the matrix that we look at is you know, who does the problem affect? And now we're looking at others that the same problem could impact. Uh, when does it occur? Is typically good morning, noon, night, inside a facility, outside a facility. And why is it important to fix? Because at some point there's a lot of these things you got to go address. And you might decide as a group that, hey, we've got other ones we need to fix first. Um, so maybe we're not gonna be able to get to this one right away. Most of the time, though, I think teams lined on, yeah, it's important to fix because it's got an impact. That's why we even pull the team together on the organization, and then describe in the last part how is it creating an issue? And so so through those five steps of what is the problem, very clear, concise, who does it affect, when does the problem occur? Why is it important to fix, and how is it creating an issue? You're able to build a problem statement that the team can get by, and that's going to help center the team continuously through this cycle of root cause assessment.
SPEAKER_01:You I know it's you we call it a matrix, but for those people that are like trying to picture a matrix, it's uh basically like a table. So think of a form where you answer those five questions that Steve, you know, and then you answer them to the right. Let's say it's like a table. And then then once you've got those, then as as he as you stated, Steve, you're able to really come up with the quality because it has all the key elements that you need to have in a problem statement. So and then after that, then obviously you got to get everybody aligned. It's like, hey, does everyone feel that this is a good problem statement? Uh, do we all agree that that represents the problem correctly? Then I think the the next step is you've gathered all your information, you've got the right team, you've got a great problem statement, you're really gonna start to go, and we're not gonna go deep into this because you know that that is that could be a course or a podcast episode on its own, is you know, you use the five Y method of asking questions. And it that is how you get to the root cause. You can also use fish bone diagram to get ideas out on the on on the on the table. It's a brainstorming tool. But in the end, you're really trying to identify the root cause. I I think this is the good time for me to tell the story. I think we've given it enough to be able to understand the context. So the the story was uh this different piece of equipment part of uh a wash system. There was there it has a wash system that travels back and forth. Think of it like it's got chains, it's on a rail, it moves, it moves the length of the machine to clean it. And uh part of the drive system for this, there's a sprocket that fell and damaged a bunch of other things when it fell. But the in the end, the team determined, and they did a good job. They saw that the the there's a threaded uh screw that the purpose of it is to keep the sprocket on the shaft that it's driving. So it can prevent it from slipping off. And that set screw is what it's called, is what retains it's like a wedge that keeps and it's referred to as a key, and that retains the sprocket in place. What happened was the set screw worked its way out through vibration, it worked its way out, and that's what caused this whole event to happen. I was talking to one of the maintenance leaders. I was responsible for the maintenance team at that time. I was leading the team, and so they they told me about this incident, which cost like, I don't know, like four or five hours of downtime with all the damage it caused. The root cause had been identified well, but the the corrective action was where the opportunity was. The person said, Well, we found what happened. The set screw had come off. I said, Okay, so what are we going to do to prevent that? And he goes, Well, we're going to have a mechanic walk around and inspect all the set screws every day on their on their rounds. They called them rounds. And I'm like, Okay, that's one way of of being able to take care of that. I said, That that's a lot of invested time to really detect that there's a uh the problem is going to start to come back. I said, Can we prevent the set screw from coming out? Because that really is the the root cause. And he goes, Well, you know what? Yeah, we can put Loctite. And so for those that don't know what Loctite is, it's basically meant it's it's like this uh liquid paste that you put on on screws and bolts to ensure that they don't vibrate and work themselves out. So it's it's almost like a glue that keeps it in place and and there's different versions of it, but that was it. And mechanics are familiar with it. And I'm like, hey, that would be probably a way to not have to have someone inspecting all the set screws, which is a lot of set screws, by the way. He goes, Yeah, you know what? Yeah, we should do that. And that's just one simple example of where the corrective action was going to be let's inspect to ensure that we don't do it, versus really focusing on the prevention of the set screw coming up.
SPEAKER_00:Yeah, and getting to that next level. You're you're absolutely right. Okay.
SPEAKER_01:Because, yeah, because they they their uh I guess you could say their problem statement was that, hey, the set screw, no one saw the set screw come out. If you if I had to go back in time and say what was their problem statement, their problem statement said would probably was, or at least their their solution indicated that their problem statement was more like how do we make sure that we see when the set screw comes out versus the problem statement saying the set screw came out. How do we prevent that? Small differences but powerful impact that you can have if you're really focusing on the right problem.
SPEAKER_00:Yeah, so critical to have the right problem statement. And I think also as a leader, it's important to recognize if you're you start the problem solving process and you you identify at some point that you do have the wrong problem statement, that you you're not afraid to say, okay, time out, I think we got the wrong problem statement. Let's go back upstream and and reset on this problem statement. So again, it really takes some good awareness and knowledge, and I think questioning. And you know, one of the quotes that uh we also uh share in some other training we do, Lupe, in this space is the one by uh Albert Einstein, where he talks about, hey, if only had an hour to solve a problem, he'd spend 55 minutes thinking about the problem, trying to understand its root cause, and then only five minutes thinking about solutions. And so as if as we've seen on these teams, and I think as your story alludes to as well, there was a lot of solutions that got thrown out without really getting to the root cause of the problem. And then and yeah, they may have caught, you know, sending somebody around looking for all those set screws, they they may have caught it a couple of different times, but it also throws a lot of cost at it, right? Now we got labor engaged when we can do something much more simple, cost effective, probably even more impactful than someone trying to catch or inspect to correct, right? So anyway, yeah, great story. Thanks for sharing that.
SPEAKER_01:To reiterate what you stated, I love that quote by Einstein also, is that it becomes very evident. If you've done a great job understanding the problem, the solution or the the countermeasure becomes very evident. And that's why I think he says, hey, I'd rather spend 55 minutes in the five minutes. People say, Well, I that's not enough time because human nature, at least most humans that I've worked with, they immediately start to brainstorm. Like there's a problem, the brainstorming happens, right? They like we need to come up with solutions. So, like instead of saying, hey, we really need to understand this problem, they immediately go to brainstorming solutions. And so it's it's it's crazy. It's crazy that we do that, but it's part of human nature, I think, for some reason.
SPEAKER_00:Yeah. And and a lot of times you can manage that, as you mentioned, Lupe, by respectfully talking about okay, well, let's let's make sure we understand the problem first, and you can park in lot solutions, you know, you don't Want to disregard them for sure, but uh don't spend time on them. That the last thing I want to talk about here, Lu Bay, is leaders are looking at you know how to improve their problem solving skills and teams, is to um to make sure even when you've identified a good problem statement, you've got the right team together, you start bringing people in and out, there's a tendency for some people to say, hey, well, we're looking at this anyway, let's look at these four other things. And and they start to kind of ride on the the issue, um, but with a second agenda of items that can can really slow down what you need to get done and in the initial steps. You know, one of the the suggestions I would make is just to call that out as soon as you see it happening and simply statement of, hey, what problem are we trying to solve? Okay, well, that's a separate problem. That's probably something worth looking at, but we're gonna we're gonna put it off over here for this time. We'll get back to it. And so it gives them, hey, you're acknowledging that they've got another thing, idea or improvement that they want to bring up. Uh you're not dismissing it, but you're you're also not letting it water down what you need to go after on the original problem statement. And and that it happens a lot, and it sometimes falls out of the ideation process, or just people like, hey, they're looking at such and such a process. I should also bring up these other things, and that that can really water stuff down. Or as a leader, you may stop and say, you know what, that is a bigger problem. Okay, we're gonna stop and reset and we're gonna write the problem statement for that activity now. I don't encourage that often. I I think solve the problem you're working on and then get back to it. But I've seen that happen, and I've seen the need for that to happen as well.
SPEAKER_01:Not to get too deep in the weeds here with the five Y, or yeah, the five Y. And when I say Y, it's W H Y, not the letter Y, the five Y's. There's a really great video for those of you interested in going through that process. It's a really great video that's done by the Lean Enterprise Institute. So if you go five Y L E I, the letters L E I, you should be able to find this on YouTube. And it it goes to an example and you're it helps you understand the five Y process. But the the the watch out I would have is that sometimes you may not go deep enough on the five Y. You may stop at a few steps. And I think if the example in the video really helps you identify the different spots where they the mechanics that were dealing with this problem could have stopped and dealt with that only, but they wouldn't have been able to get to the true root cause. So that would mean that eventually they would have to deal with another symptom of the problem. And then sometimes you just go too deep. The moment you go somewhere, and then the next step after that, you're like, okay, that next step didn't really find give me a lot of value. It's not progressing my path to the root cause. Then you probably you've probably hit the the maximum as far as whys, how many whys you need to do. Even though it's called five whys, it could be three whys, it could be eight whys, it could be ten whys. So don't don't get set that, oh well, you know, this is the fifth one, so we're gonna go with this. That's not how the tool works.
SPEAKER_00:Yeah, and then the last parting comment there is don't try and boil the ocean. You could get crazy on people offering additional whys. So it takes practice. Highly recommend, you know, some great videos, as Lupe mentioned. Uh, we'll put information how to either get to the books or the uh videos that uh you know we recommend folks take a look at. But you know, Lupe, I think we're at a good stopping point and uh just want to uh thank you for taking some time today uh to walk through this with me. For our listeners, this is typically a four or eight-hour course that we just covered in about 36 minutes. So a lot more to it and happy to uh have conversations if you want to reach out to us at uh Instagram or just request additional details for elements of problem solving, but we could spend a lot of time on this and uh hopefully it's just wets your appetite on some things that you might want to do differently as a leader as you start to look at just improving your problem solving capabilities for yourself and for your team.
SPEAKER_01:Yeah. One of the biggest roles that we play as a leader is to help our team solve their problems. Definitely a skill set that I encourage everyone to be good at if you're in the leadership role. Even if you're not, but if you aspire to be a leader or you want to contribute to a team, that's a fantastic skill set to have. And you can get better as you do it. And learning some of these things, reading books, all of those activities will definitely sharpen your skill set. So with that said, this is Lupe Munoz, and I'm Steve McKeon. And this is the leadership exchange. Everyone have a great day.