GA 389 | People Solve Problems with Jamie Flinchbaugh
26 Nov 2025 · 47 min
Interview (recorded Sept 16, 2021) with Jamie Flinchbaugh about his forthcoming book "People Solve Problems: The Power of Every Person, Every Day, Every Problem." Jamie argues problem-solving success depends less on specific tools and more on surrounding capabilities (problem framing, intuition, testing), a learning culture, active coaching, and leaders who architect systems and prioritize creative, low-capital solutions. The interview outlines the book's five sections and highlights practical concepts like the "25 problems" myth and coaching as high-leverage practice.
Questions this episode answers
September 16, 2021.
October 26th (scheduled release).
The myth: a manager with five direct reports and five problems each therefore 'has' 25 problems. Reality: those are the team's problems; the manager's role is to surface themes and own system-level issues, not each individual problem.
Chapters
Let's just imagine I have five direct reports. Each one of them has five problems. The myth is that I then have 25 problems. And my argument is, no, those aren't your problems, they're your team's problems. What are those 25 problems telling you?
Today, I'm excited to welcome my friend Jamie Flinchbaugh back to the show. Now, as many people know, Jamie is a really prolific lean thinker. He's a consultant and, and everything in between. But Jamie is also a fantastic author and he's written a hitchhiker guide to Lean, which many lean thinkers have read. If you've not, you need to pick that book up because it's really a must, must read for any, any lean practitioner. But Jamie's written a new book. It's called People Solve Problems. The Power of Every Person, Every Day, Every problem. It's going to be released in October and Jamie talks about that later in the episode. But what we did on today's episode is we sort of just walk some of the high level principles of the book. So there's five main sections of the book. And so what we did was we sort of just went through each one. And full disclosure, at the time of recording this, I have not read the book myself. I plan to read it, but I have not read it yet. And so I was really curious just about some of the titles and some of the sub bullets of each title. And so I just witnessed it with just general curiosity really more than anything. And Jamie really delivered a lot of value, I feel like. So it's one of those, one of those interviews to where, you know, even if you don't read the book, I think you're going to get a lot out of this podcast because Jamie shares a lot of, a lot of wisdom, a lot of tips, and Jamie is a fantastic, fantastic lean thinker. So. So show notes for this episode can be found over@gembapodcast.com just look for episode 389 again gembapodcast.com look for episode 389. There's gonna be a lot of links in this one, so be sure to check out those show notes. Okay, enough from me. Let's get to the show. Jamie, welcome back to the show. How's it going?
It's going great. I'm really glad to be back. Unfortunately, this time not in person like we did the last time, but very glad to be back.
Yeah, yeah, we were just looking before we hit record. So you were last in the studio here, April 13, 2020. We recorded the four Cs of Trust, episode 314. So that was a fun one. But yeah, yeah, yeah. It's always, always great to do them in person, but I do way more of them this way, so we'll. We make it work. So, so anyhow. Well, Jamie, you know how we like to begin all of our shows? We like to have our guests share a quote. So do you have one?
Yeah, so I'll, I'll share one from one of my former partners, Dennis Pauley, who, fantastic leader. He said, if you, if you cannot teach, you cannot lead. And I recently shared that on our, on our Instagram page. And it's always, always coming to mind and just got off a conversation talking about culture. And that's a large part of what a leader does, is to be a teacher. That's what I try to be, is be a teacher. And so it's something that's stuck with me a long time.
Yeah, no, I like it. I like it. That's a good one. So, Jamie, in case folks haven't listened, previous episodes with you on and they, they haven't heard of Jamie Flinchbaugh, which I find it hard to believe if you've been in the lean community, but, hey, I'm sure there's some fol there. Well, just tell us a little bit about your background, how you first got involved in all this continuous improvement stuff and then, and then what you're up to these days.
Yeah, so my Lean journey started when I was at Harley Davidson about 30 years ago. I wrote a chapter about that for Mark Rabin's compilation book Practicing Lean. And I fortunately got an experience where I kind of taught myself early on, although I didn't articulate it well, how much Lean is about the right culture and the right set of behaviors. Helped with the Chrysler transformation from inside the company through the 90s. And then DT Energy. I ran a company I co founded with Dennis and with Andy Carlino called the Lean Learning Center. For 15 years, served in the executive team at Qorvo Semiconductor, helping CEO and many other leaders with their transformation. And then basically the beginning of 2020, I kind of went back and started an advisory and coaching firm called Jay Flinch. Along the way, wrote the Hitchhiker's Guide to lean about 13 years ago.
Oh, my gosh, that's a lot. I didn't realize it's been that long.
Yeah, it's been out quite a long time, but still feel very fortunate to have lots of people still reading it and have another book coming out this year.
Yeah, well, so that's going to be the topic of our discussion today, Jamie, is your new book, so titled People Solve Problems. The power of Every Person, Every Day, Every Problem. So I guess what I like to do when I talk to folks who are right, who have written books or about to release a book is just kind of open up with like, why did you write it? Like, what problem are you trying to solve by publishing this book?
Yeah. So I'll start with why I write in general. My first rule of writing is I write to help myself clarify my thinking. And even for years, when I wrote the Lessons from the Road column for Industry Week, half the time the column was picked based on a problem a client was having. And I wanted to to come at that problem with some clarity of thought. And so I'd write a column and it would force me to think through the topic in a structured way. And so in a lot of cases, that's kind of why I wrote this book. Once I wrote it, I was kind of like, I don't care how well it sells. I mean, I do, but I wanted to clarify my thinking around things I'd been saying for a bunch of years. And it did. It helped me sharpen what I was saying, what I was coaching people through, what advice I was giving. The problem, though, that I was trying to solve is best presented as this is company after company trains their people in problem solving. And I don't say I don't care, but I do care. But all sorts of different problem solving tools and they sign up for Kemp Academy and there's a whole sorts of problem solving training that they can go through, but then they come back and they're like, oh, it's not sticking. It hasn't really germinated and it isn't really flowing through the organization. And we constantly have to push what's broken. And they tend to solve that with more problem solving training. And to me, that's not. The problem solving training is out there, very well done. And there's lots of tools that work really, really well. And if you go look at the training and the tools bring really good problem solving companies and really bad problem solving companies, they aren't that different. And so I'm trying to get at what is the difference between companies that do this well and don't do it well, regardless of what problem solving tools they've deployed.
Yeah. So one question I have just a general question. It just kind of pops in my mind. You're mentioning that you write for, you know, to help yourself and to clarify your own thinking. So one of the things that.
Is.
An issue for, for me and for pretty much anybody that's a human being, I believe is confirmation bias. You know, we all, we are all, all biased. We just, we just are. And I'm curious, as you know, you're a prolific author and you know, have written a lot of books and a lot of blog articles and all the rest of it. How do you battle or how do you defend against your own confirmation bias or seeking your own. You know what I'm saying? Like writing to yourself and trying to prove your point is right by researching it a certain way or whatever it might be. What do you think?
Yeah, well, yeah, I think the number one thing, and this is not tested against my own research, but tested against my own reality. Meaning that, you know, put ideas out there and test them against actual occurrences and with real coaching clients who try things out or push back or whatever that might be. Now, that doesn't mean you're completely avoiding confirmation bias. There's key point. In fact, you could probably argue every key point I've ever made could simply be true. Because by sheer force of willpower, I've convinced enough people I was right versus getting pushback and, or things failing in coaches hands and things like that. So to me it's really about is why I love to coach and love to work with clients is. It's there. You know, I have a very broad set of places where they still own my clients, my coaches, people I advise, they still own their own implementation. They are doing what I ask them to do, they're taking what I share, put it into use in their own way, combined with their own experiences, their own systems, their own leadership, whatever that might be. And it either makes that stuff better or it doesn't. Yeah, again, those are. That's not a very super science. It's still a subjective methodology of evaluation.
Yeah.
But it's not just, you know, do you know, copy and paste, do what I'm asking you to do.
Yeah.
And therefore, as long as you stick to it and put enough resources on it, it's going to be successful.
Yeah.
You know, they still, they're integrating my ideas into their stuff, which hopefully is a test of its resiliency, flexibility, which if you're going to write a book, it's got to be resilient and flexible across a broad range of conditions. So for sure.
For sure.
Hopefully that's enough.
Yeah, no good stuff. All right. So what I thought we would do for this, for this interview, Jamie, is, you know, from what I understand There's. I've not. Full disclosure, I've not actually read the book yet, which sometimes it's my favorite way to interview authors is by actually not having read it initially because I go into it without any bias. Right. But you have five sections in the book that you've written with multiple chapters obviously in each section. So I thought we would just sort of go through each section one by one and perhaps you could give us a little bit of, you know, some of the highlights and some of the key points or that you want to, that you want to share for that section. So section one is titled what is the problem with Problem Solving? So what's that all about?
Yeah, so this, this was originally probably just an introduction and just maybe a chapter. And after the first write and review, it really needed sort of more of a flushing out of this statement. And I have my favorite tools. And between I'll say version one of the book and version two of the book, version one still had me articulating, here's the tools I like and here's the tools I like less. The second version and the final version. This is tool agnostic. I've tried to write this book where, you know, I don't care which tool set you're using. I've tried to write the advice in the book to fit whatever tool set people are using. But fundamentally, you know, the best. If I go look at the best five companies that I've ever seen a problem solving and the worst five companies I've ever seen at problem solving, their tools and their templates. If you go say, show me your problem solving tools, the tools are the same. If I go look at the five best companies of problem solving that I've experienced, those five actually use some variation, maybe some consistency between them, but some variation of tools. They're not all using the same tools. And yet some of those best companies are using the same tools as other companies as they do very poor job. And so you go take a scientific look at that. You kind of go, well, the tool is not the differentiator yet. That's what we keep training people on. And so the other thing that I've said for years, and this goes back long time, is you go to most problem solving training and it basically assumes that you've already decided to pick up a problem solving tools and it says, okay, now frame the problem statement and put it in this box and do. But it assumes a lot, right? It assumes you've decided to solve a problem in a structured way using a tool that's a massive assumption. And so again, I think the problem with problem solving tools is not the tool. The tools, and there's a wide range of them are very, very good. You go see what people can do with them and they're fantastic outcomes. But in many times it's even their decision to pick them up in the first place. It's like I can go buy really good dumbbells or really good exercise equipment, but if I never decide to pick them up, it doesn't matter how good they are, it's never going to help me. It's sometimes the things wrapped around and weaved throughout the tools and wrapped around the tools that really make the difference between success and failure.
I love that analogy. Yeah, I love the analogy of the dumbbells and, you know, expensive workout gear when sometimes, perhaps there's an analogy here. Even with problem solving, sometimes you don't need dumbbells. You just need to eat more carrots and less, you know, candy. And you need to maybe go for a jog and do some push ups and setups. No equipment involved. Right. You know what I mean? So perhaps there's, there's something there. Almost. Keep it simple. Perhaps, you know, in the beginning, I don't know. Don't overcomplicate it.
Don't overcomplicate it. But, but also, and it, and you know, it's plenty complicated. I mean, problems, problems are messy, hairy things that need to be torn apart and put back together. But you know, the point is, is that, you know, using exercise, someone that has the right coach and the right mindset and the right behaviors, that has nothing, right, they have like an old pair of sneakers is still going to do better than someone that buys a boatload of equipment. And it's all really, really good equipment and they have a peloton membership and they spend a bunch of money, but they don't have any of the right behaviors. Nobody's coaching them. They have no orientation or goals or anything else. And so it's not that tools don't matter, it's just that there's other things that we don't talk about often or ever mostly just not often enough that matter just as much as the tools.
Yep, yep, got it. Okay, section two. People centered capabilities. And here you're, it looks like you're getting into things like problem statements, cause and effect, some really good stuff. Ideating and selecting solutions. That's a big word, Ideating.
Right.
I don't even know if I'm saying it right. Ideating. But talk about section two. A Little bit, yeah.
So section two and the rest of the section, the rest of the sections are, I'll say the original four sections, my first draft, but they are the things that I think matter just as much as the tools, but aren't talked about as much. And so this is really about the capabilities. And the point is that you know that the skills we apply isn't about how to fill out the template, but there's some common skills that, and capabilities that relate to problem solving regardless of what tool set you're picking up. And I, and I see the tool sets usually as much, I argue they're a job aid. Right? They don't, they don't provide the skill. If problem solving was, was a recipe, if it was really just about following the process, we could write softw that would produce solutions to problems, but we can't. Still requires a human being to bring them their full selves to the problem and all the spirit that they engage in it. And so what are those capabilities that quite frankly cut across all of the tools and that whether you use the problem solving job aid or not, these tools still matter. And so I would argue if you never even acknowledge that you were formally solving a problem, these capabilities still matter. And all but a very small percentage of even lean oriented companies pick up a problem solving tool for all of their problem solving. They're still problem solving in the wind, in the ether, in the white space, in between opening an A3 or starting a Six Sigma project or doing whatever they're going to do. And so those skills as it relates to sort of everyday problem solving in the air, in the wind, problem solving, those skills still matter. And if you cultivate the right skills, they will still make you more effective when you do decide to pick up a tool. And they might make you more effective when you don't decide to pick up a tool or just haven't gotten around to picking up a tool where still a lot of problem solving occurs.
So chapter four is all about problem statements. And I don't necessarily need to go to a deep, deep dive, but I feel like this is something that I've seen a lot of people struggle with. And you've got some interesting things in here as far as bullet points, if you will, for this chapter and breaking down the problem and then problem statement failure modes. I wonder if you could talk about, about that a little bit. Talk about, you know, breaking down the problem or the importance of breaking down the problem, not going after that so called vague issue.
Yeah, I, I think you know what's what's really interesting is that I think companies, organizations, teams that get this really, really right, start off with problem occurrence where it happened at the point of activity and almost real time, or actually real time, jump in and solve, learn from that and go after. Which means the problem's already broken down. You don't need to break down the problem. You're not saying I have a budget problem. You're starting with a very small problem that at it on its own is small enough to go after. And so I think of this in two phrases. One, building your problem solving capability around starting with those small occurrences and solving problems at that level. But when you are aggregating your problems, building big themes around them, like we have a problem solving right now. Everybody will say, oh, we have a staffing problem and a supply chain stability problem. Every, almost everybody's going to say that. I'm like, you don't have a staffing problem, right? You have a, you have a, you have a hiring problem, you have a retention problem. You have a how to leverage the hours. You have how many hours people are going to put in based on the people that are already there. You're going to have a. How much energy they have during the hours they're working. And even those are too broad. You can't solve a staffing problem. I don't know what that looks like. There's way too many problems. So really getting after getting down to. And I've honestly had this conversation a lot just around staffing problems. Don't, please don't write an A3 around staffing problems. Like that's just such a broad theme. It's like saying I have a weight problem but. And I'm going to solve it with one thing. We have to understand that the retention problem and the hiring problem are two very different problems. And even the hiring problem, is it the number, is it how fast they get hired, is it where they're coming from? Or do they meet fill the needs once we do hire them? There's so many different aspects of that. It's far too broad and very hard to solve those problems. And again, we do a lot of that work whether we admit it or not, whether we want to or not. We do a lot of that work before we ever pick up a tool or a template, which is why it's so important as a capability. It happens in an executive committee or executive team or in some performance review or some metrics review is we've gone halfway down the idea of framing the problem before we ever say, you you own this problem and here's the tool you're going to use.
Chapter six. You talk about integrating intuition. That's, that sounds very interesting to me. So talk a little bit about intuition and its role in problem solving.
Yeah, so I think intuition, you know, we like to think of problem solving as an analytical thing. And that's true. It's not that it's not. But at a lot of time there's other parts that, that come into play that the math or the steps or the fishbone or the process breakdown doesn't necessarily point you in the right direction. You have to make assumptions, you have to kind of go, it feels like we're stuck. It feels like we're in the wrong channel. It feels like we're bringing the wrong tools to bear. And, and there's decisions, there's experience based decisions that come into problem solving. Again, it's not a recipe, it was a recipe. We could write a lot more code around how to do that. So, you know, and so there is something to experience, to intuition, to creativity. And those things have to have room to breathe in your problem solving capabilities. But the best problem solving, there's a lot of, a lot of research behind this. I don't go a ton into the is really that kind of a book. It's meant to be a little more pragmatic. But there's also a lot of, you know, whether it's Einstein or someone else, a lot of people, you know, some of the best and brightest scientists in the world, you know, have things to say about this is how you even do science, is it? There's a basis of intuition. And so it's really about the marriage of them, the intertwining of the analytics, the math, the science, the rigorous path and the intuition, the creativity path. One of my favorite quotes in this chapter that's just fun is from a mathematician, scientist, very logical person, known for their logic is your intuition and your intellect should be working together, making love. And I think it's a very provocative statement, of course, but it is again about the intertwining of these two things, these two sides of the brain, if you will. But also again, problem solving will, I don't say will take care of the analytical side, the intellectual side, but if you have any tools, there's a rigor behind it. That part will be somewhat taken care of. It's allowing for the breathing room for the intuition that I think is the tricky part and the one that really good problem solvers master.
Yeah, yeah. So you go on later in this section in chapter eight, which is the final chapter of section two here, you're talking about testing to learn. And so obviously those of us who are sort of passionate about kind of like what Mike Rothers brought into the movement here, you know, the whole scientific thinking concept of don't be so sure, test, you know, and learn and, and so forth. Is that sort of where you're going in this chapter as well, to, to just, just test your. Maybe take that intuition and test it, experiment with it.
Exactly. And, and, and I think, you know, for me this, this always came out of Steve Spears work. First and foremost, I decoding the DNA of the to production system and, and you know, based on his research. But, but, you know, very strong on testing, very strong experimentation, building a community of scientists. But, but, but where I think where I talk about it as a, as a, as a capability versus just a step is a lot of people do build it into their problem solving near the end, right? And they kind of go, okay, you have an idea, now go test that idea. Right? Validate, verify, test your idea, make sure it actually solved the problem. And you know, absolutely, definitely do that. Right. But there's opportunities to test, to learn all the way through. How do you know that your problem statement is correct? Is there some test that can validate that your problem statement is valid, is right. Is taking you in the right direction as you analyze current state? Is there some tests, some experiments, some validation you can seek that you, you understood the cause and effect well. So to me, it's any point that you need some higher confidence, some verification, some validation. What tests can you do along the way? And so if you, we like, you know, a lot of us would like to say, if we're talking in models, is problem solving is both one big PDSA cycle, but also lots and lots of PDSA cycles along the way.
Yeah.
Your problem statement itself is a PDSA cycle. How do I know I got my problem statement right? So part of this chapter is trying to help people say, you know, I can't build enough steps into a problem solving process that would force you to experiment at every point that you would. And that's why I think of it as a capability you test every time you think you need to along the way. You have a bent, a mindset and a capability to go test anytime you need to validate assumptions that you've made.
Yeah, got it, got it. All right, well, let's move on. So section 3 is titled problem Solving Culture. So we're talking about some deliberate learning, ideal state Creativity over capital. Lots of good stuff in this section. So give us a high level overview of that, Jamie.
Yeah, so for anyone who's read the Hitchhiker's Guide to Lean knows that chapter one is about culture, about behaviors, about principles and behaviors. And Andy Carlino and I, you know, we taught and talked about that for a very, very long time. I believe getting the behaviors right, getting the culture right, is one of the most important variables to any Lean journey. And so this is really about. This section is about some of the behaviors that help enable effective problem solving. And some of the behaviors, like learn deliberately, are behaviors that you have to enact within your problem solving effort. And some of them, like transparency, vulnerability and trust, are more about what wraps around it, right? It's about your portfolio of problems and problem solving. And what is an underlying culture, set of behaviors that helps make a problem solving culture effective day in and day out.
I'm wondering if you could talk a little bit about chapter 11 here. Creativity over capital. So creativity begets creativity, capital diminishes capital. That's a provocative statement there. What's this all about?
Well, and so if you think about problem solving beginning with just symptoms, right? How do we know the problem exists? You can at least overpower, overcome almost any set of symptoms, not any set of symptoms, but almost any set of symptoms with some kind of resources, right? I can buy capital. I can throw money at it. I can throw or people at it. I can reduce prices to satisfy customers. When our defects are too much to bear, all sorts of ways we can throw money at the problem. But the more I throw money at the problem, the less money I have, and the fewer problems I can solve by throwing money at the problem. And so the more we spend our money to solve problems, the less of it we have available. On the flip side, when we throw creativity at problems, when we try to come up with creative solutions and solve problems in a simple or elegant way that doesn't involve capital, well, just by the sheer act of thinking through that act of creativity was exercising the muscle of creativity. And it gets stronger the more we practice. Coming up with creative ideas is why artists have. Most artists have a daily practice. You know, they draw something every day or they write every day. They have to keep the muscle alive. And so creativity is a muscle that if you let it stagnate, it withers, right? And so the more we use creativity to solve the problems, the more it becomes a strength of the organization. And so we really, as a behavior, as a mindset, we have to value Solutions generated through creativity more than capital. And so a leader, if you're looking at it from a leader standpoint, the very second you bring me a capital intensive solution, I'll ask, okay, well, are there other solutions that don't require that amount of capital? Are there other solutions that might not be as effective, might not seem as safe, but might be different? It doesn't mean we're going to choose them. Sometimes we choose, yeah, go buy the million dollar thing or the billion dollar thing. But we want to also look at, did we miss the creative solutions because we didn't even try. That's the real risk, right?
Wits over your wallet, right?
Yeah, yeah, it's, you know, I grew up, I still am Pennsylvania Dutch. It's an underlying culture that's known for being frugal. And so this also has as an appeal to me on a personal level, but I also think it is just better problem solving. How do we seek those creative solutions? Because again, lots of companies can always throw money at every one of their problems. Those are not the ones that I look at and go, well, you guys are really, really good at this.
Yeah.
Because at some point that just doesn't scale anymore.
Yep. Okay. Section four, Success through coaching. What do we got going on here?
Yeah, so, so to jump ahead a bit, the next section is about leaders. And I would, you know, at first, maybe, maybe even at first outline, I would, you know, coaching is one of the roles of the leader and just bury it in there as a chapter. But I have a lot to say about coaching and it doesn't always have to come from a leader as well. And so to me, I really, I decided to abstract coaching as its own section because I think it is the highest leverage point for improving problem solving. And the main reason for that is twofold. One is that everybody's baseline for problem solving is very, very different. And for this reason, we've been problem solving since we were infants. So we have a personal history of problem solving. We grow up solving problems. We have an educational bias and we have a work bias. We have a lot of individual experiences that shape our problem solving perspectives and capabilities and behaviors and all these other things. So it's very personal. We aren't all starting from the same standpoint. So, so that's one. The second thing is that it's not a one and done thing. I, I can't, I can't teach people, you know, how to solve problems and then they go off and now they're different. It's, it's a. How many Swings of the bat in the batting cage can I do? And I need as much detailed feedback on the 10th swing of the bat as I do the first. Yeah, because there's, it's so complex, it's so nuanced. There's so many layers and, and it layers to the onion of problem solving. And so coaching allows us to get into the repetitions and the long learning journey of improving our problem solving. And so for those two reasons in particular as more. But I argue that those are the reasons that coaching is the highest leverage point of really improving organizational and individual problem solving.
So what advice do you have for organizations that are maybe just getting started with problem solving, continuous improvement, whatever you want to call it. And they don't necessarily have, I don't know, experienced coaches. They have managers and supervisors and so forth. But like, what do you do if you don't know how to really coach? You've never done it. Is it just literally a matter of going and getting some training or what do you think? Like, how do you get started when you're at sort of ground level with, with this thing? Yeah.
And so a lot of organizations wait to have experts, you know, available and they're going to go coach everybody. But A, that takes a long time to build and you're missing your greatest leverage point. And B, there's a lot that can be learned by coaching. In fact, I argue if you're going to do, let's just say 25 repetitions of problem solving, you will learn. I argue, people can argue with me on this. I would argue you learn more by coaching problem solving 25 reps than you do doing problem solving. And for this reason, the person doing the problem solving is as much, if not more focused on the substance of their problem solving than they are the methodologies, the how, the thought process, the next steps, all of that, the coach is 100% focused, should be on how the person is going about solving the problem. So for, you know, like hours, hour to hour bias, you learn more. You spend more time with the how of problem solving as a coach than you do as an actual problem solver. And second, you know, I'll say that the power of observation is very, very, you know, it's a learning oriented mindset. So you observe, you know, you have a lot of emotions tied up in your own problems. But if you get to step back and objectively observe as a coach, you just, you can, you, I think you can learn a lot. So I argue that as long as you have some framework, some standard, some guide, it does not have to be perfect. It can even be simply, here's how you ask good questions, which there's a whole chapter in the book just on that in the section. Then ask good questions. Great. I don't even know what good looks like, but I'll learn with you what good looks like because I'm going to ask questions and we're going to look at it together. Now, is that as good as getting coached from someone with deep experience? No, I don't think it is. But it is also better than not getting anyone to work with you. And so if. If the choice is coaching or, you know, inexperienced coaching or no coaching, I'll take inexperienced coaching any day. As long as it's a learning mindset, as long as we insert it with the right intent.
It's kind of like when people say, hey, which. Which s of 5s is the hardest? And I say start.
Right, Right.
That's the hardest S. Right.
I agree with that entirely. It's, you know, and, you know, I have been problem solving and coaching problem solving for a long time. I still learn from coaching problem solving. And so it is like, well, at what point are you done learning? So you are now ready to coach? Well, never. So you might as well start that learning journey itself.
Yep, for sure. Okay, well, in the last section is the role of a leader. And you've sort of touched on it a little bit, but maybe let's go a little bit deeper. Talk about the leader as a, as you say, a system architect there in chapter 20.
Yeah. So I mean, the role of the leader. When I. When I went from first outline to maybe at least second draft, I realized this whole section of the book might have been its own book. And I had to consolidate some things to make the book manageable. But the role of the leader is a lot of things. But the first and foremost, I believe, is architecting your system for your team at any level around problem solving. Right. And this is things like, what are the sources? Right. We have many sources of problems. We have our inbox. We have metrics, we have standards that have failed. We have the customer complaints, whether internal, external. We have stuff that comes down from above. So we have many, many sources of where problems come from, how we know about them. I call that the problem landscape. Do we manage that as one. Do we manage it independently? How do we prioritize what problems we're going to solve? Or do we just let everybody figure that out on their own? Well, that can be a very. That can be its own barrier to Even getting started. And so I think one of the I talked earlier about writing helps me articulate my own views. This is one of my points that I think I've always known, but I think I've been more clear about having written the book, is that your company might have its own management system, its own systems of working, but all context is local. A financial manager and an IT manager, and a product manager and an HR manager. What's the cadence, the magnitude, the source of problems? That's a very local context, local issue that even if we do have a company way in which we manage problems, I still need to make it work from my local context. And so I believe every manager has to at least, you know, maybe not design from scratch, but at least manage and design and architect the system that they use for their team to find, to surface, to prioritize, to manage, to put to bed problems. That whole thing happens in the context of essentially a management system. Someone has to architect that system. That's one of the key roles of the leader.
I love it. So the last question I gotta ask is, I don't know this, I've never heard of this. In chapter 23, you talk about the 25 problems myth. Are you willing to tell us what that is or do we need to buy the book and read about it?
No, no, I'll tell you what that is. And it's usually not 25. But this is the way I do the simple math is that most managers, and particularly early managers, but I'll say even I see the same problem in CEOs of multi billion dollar companies, can fall into this trap is, let's just imagine I have five direct reports. Each one of them has five problems. The myth is that I then have 25 problems. And my argument is no, your team has 25 problems. You have five different problems. Those aren't your problems. Those are your team's problems. Now, you may have to help own the problems, solve the problems, coach the problems, prioritize the problem. You might have to do all those other things that we talk about in the role of leader, but those aren't your problems, right? They're your team's problems. What are those 25 problems telling you about the problems that you should have? So to be a little more articulate about it, if, if I see that across my whole team, they have a whole bunch of problems that relate to upstream inputs. Well, now I have a theme around a pattern of problems across my team. I now have maybe a broken connection or an alignment issue or some other Sort of higher magnitude, broader problem that I'll then have to break back down. But that's the problem I own. We have a systematic broken alignment issue, for example, between myself or my team and my upstream partners. But I learned that from the details of my problems. The issue is that if I just jump in and say, oh, my team has 25 problems, I'm going to care about those same 25 problems. I don't fix the bigger picture, systemic stuff that those 25 problems is informing. And so I end up micromanaging. I end up missing the strategic system at level things. I end up, you know, under, under leveraging my own role. So that's, that's a bit about what I mean by the 25 problems myth.
Got it. Got it. Wow, this sounds like a heck of a book. So this episode is going to be released here and it's going to be in middle part of September 2021. So when can folks get, get their hands on this book, Jamie?
Well, so the release date is currently scheduled for. Currently scheduled for October 26th. Everything seems to be in line for that to happen, but, you know, some things are out of my control. So October 26th is when it should come out. Hopefully about the time maybe this episode comes out. It will be available for pre order and our goal is to issue a, you know, Kindle paperback, maybe on a separate platform, a hardcover and an audiobook all at the same time. So still a bunch of things that have to happen. Yeah, but that's our goal. October 26th. That's when we hope this is released.
Awesome. So again, it's called People Solve problems. The power of every person, every day, every problem. And we'll link to everything as it becomes available. We'll go back and update the show notes. So, you know, a lot of people listen to these podcasts months after they're first released. So just go to GembaPodcast.com this is episode 389 and we will get everything linked up there. And I personally can't wait to read it. Jamie. I'm excited. This sounds like a great book and you're a fantastic writer. So the one thing I love about the way you write, it's almost like, well, you're a practitioner who writes and I appreciate that. So that's what I really value. And sometimes you get academics who write, which that's great, you know, that's fine. But sometimes they haven't. You can tell they haven't really done this. They just know a lot about it, you know, but you've actually done it.
So, and I write, you know, I know there's a lot of lean thought leaders out there that'll read this book and a lot of instructors and consultants and all sorts of other things and that's great. But I really write this for the practitioners at all levels who are grasping with what's in front of them. They're working through the complexities and challenges of leading and I try to hopefully make this a bit simpler for them just to get started. And of course it becomes complex again once you get forward, but go forward in your journey. But at least how do we simplify it, have the right framework, get going. And, and that's the, that's the goal of my writing. Always, always has been good stuff.
Hey, if folks aren't connected with you and they want to connect, what's the best way?
Jamie well, either on LinkedIn, if they spell my name right, there's not many of me out there or jflinch.com they can always find my, find my website and find me through there again.
And if you're just listening, it's F L I N C H H B A U G H Jamie Flinchbaugh. And again, we'll link to everything there in the show notes, episode 389. So Jamie, thanks for coming on again. I know we'll be on down the road. So you know I always appreciate you carving out time for us.
Thank you Ron. I appreciate it.
All right, take care. Thanks for listening. Whether you've been on the continuous improvement journey for many years or perhaps you're just getting started, GEMBA Academy is here to support you. And while we're best known for our more than 1500 Lean and Six Sigma teaching and virtual tour videos, we also have a team of experienced Lean and Six Sigma practitioners available for one on one coaching, as well as a variety of Lean and Six Sigma certification options. To learn more and to schedule a demo, head on over to Gemba academy dot com.
