My guest for Episode #432 of the Lean Blog Interviews Podcast is Jamie Flinchbaugh, an old friend of mine and a frequent guest (Episodes 5, 6, 10, 64, and 261, plus the two times he's interviewed me, Episodes 50 and 316). He's also the co-creator and frequent co-host with me on the Lean Whiskey podcast series.
Today, the talk is all Lean, no whiskey. We talk about leadership, problem solving, more today — talking about his new book, People Solve Problems: The Power of Every Person, Every Day, Every Problem. I put Jamie on the spot to coach me through some problem solving I'm doing related to podcast growth, and he makes a lot of great points.
Today, we discuss topics and questions including:
- So, we don't need to worry about AI problem solving?
- The role of software, like KaiNexus
- The story behind the book – after The Hitchhiker's Guide to Lean in '06
- Why this book? Why now?
- Behaviors drive action — what are some of the key behaviors that drive problem solving?
- Testing to learn… testing throughout?
- Open to the idea you might be WRONG – humility
- Entrepreneur — book is a product that scales – thinking about it like a startup?
- Book isn't A3 or PDSA or Kata centered… agnostic about the specific method??
- A3 — The importance of a good problem statement?
- How do we better understand cause and effect in problem solving?
- You can coach without being an expert
- The role of intuition vs data?
The podcast is sponsored by Stiles Associates, now in their 30th year of business. They are the go-to Lean recruiting firm serving the manufacturing, private equity, and healthcare industries. Learn more.
This podcast is part of the #LeanCommunicators network.
Watch the episode here
Listen to the podcast here
Jamie Flinchbaugh On “People Solve Problems” – His New Book
This is Episode 432. It's November 17, 2021. In this episode, our guest is our good friend Jamie Flinchbaugh. We're going to be talking about his new book, People Solve Problems. Thanks for reading.
—
Our guest is Jamie Flinchbaugh. He's no stranger to this show or likely not a stranger to you, the reader. He's been a guest before on episodes 5, 6, 10, 64, and 261. I don't have a good reason for those gaps there, Jamie, but welcome back.
Thank you for having me back. The gaps are largely as much that I didn't have anything interesting to say in between there. I was glad to be an early contributor and an ongoing occasional guest.
As a contributor, Jamie was writing for the Lean Blog. He has his website now. You can find that at JFlinch.com. Twice Jamie interviewed me on episode 50. I remember that was milestone. We'll do episode 500 together. That's still a little ways away, but how's that sound?
That's a ways away. You got plenty of other interesting folks to interview between now and then.
Jamie also interviewed me in episode 316 about my book Measures of Success. Starting in 2019, we started a podcast together called Lean Whiskey. We released our 30th episode. I think there were five episodes where I had somebody else as a guest co-host.
We didn't do all of them together, but this wasn't a pandemic project as some podcasts have been. This was an idea that had been cooking for a while and we've enjoyed a very open format of Lean Whiskey. Now, I'm only drinking tea because this is a different show.
I've got a bottle of water and that's convincingly coffee. It's not Irish up or anything. In the Lean Whiskey Podcast series, Jamie and I do talk about whiskey a little bit, but mostly it's lean talk. In this episode, it's going to be completely around Jamie's new book. Congratulations on getting that written and published. It's called People Solve Problems: The Power of Every Person, Every Day, Every Problem. It's available in paperback and Kindle. It's also an audiobook.
The audiobook was released as well. You can pretty much get it in any format you like.
I hope people will check that out and that's going to be the theme of our discussion here. For our first question, I don't mean this to be too flippant, but when you titled the book, People Solve Problems, are we not worried about AI replacing people when it comes to problem-solving?
I don't think we are. In fact, AI, machine learning, and big data are tools that we use to help analyze or standardize certain decisions without getting too far ahead of ourselves. I even write about intuition in the book and how that integrates. Those are things that machine learning can't do. The key is if we knew all the solutions to the known problems, then we would write the software but we don't. We have to stumble and find our way through developing and implementing solutions. That's why this is such a people-centric activity.
That's one of the downsides of automating people out of a job. Automation, whether it's physical automation or software automation can't contribute to the organization when it comes to problem solving and bettering the company.
That's right. I think they can help standardize and provide leverage in a lot of ways. By no means am I anti-software, but the key is somebody still has to understand cause and effect. Whether it's about something that went wrong or it's about something that could go better, whichever type of gap you're talking about, someone has to decide that there's a gap. Someone has to find a way through and understand cause and effect so that you can find a better path. As we develop software, you can't treat that as a black box. You've got to understand how we get the result that we get even if a machine is doing that work for you.
I'm wearing a KaiNexus logo shirt. One other tidbit about Jamie's background is he has been an advisor to the company. He's been an investor and a friend of the company but KaiNexus has never pitched or promised or even dreamed that web-based software would be in some way automating problem-solving that we're in agreement. There is a role for people using software to help track their improvement activities, for example.
A little backstory to help eliminate that point is that people need help too. They need a good system underneath them, whether it's pen and paper or it's software to help keep things organized, track things, connect them to each other, reference, sort, provide reminders, and all those wonderful things. I saw plenty of organizations over the years that would do a great job with putting problem-solving up on a wall and walking the wall. That's great if that works for you, but I've also worked with organizations that are 10,000 people spread out over an equally broad number of locations and there's no wall to walk.
People need help, too. They need a good system underneath them, whether it's pen and paper or software, to help keep things organized, track things, connect them to each other, reference, sort, provide reminders, and all those wonderful… Share on XThe software provides that job aid to help make those things a little bit easier. I had identified that as a possibility and in my old business, I put developing such software on my own strategic plan. After a couple of years of not getting around to it, that's when I discovered KaiNexus and decided, “I only wanted the problem improved. I didn't need to do it all myself.” When I found KaiNexus, I stopped trying to build my own software and just got behind KaiNexus.
Thank you for doing that and for your support. As the book title says, People Solve Problems, I think of KaiNexus in a way. There's a parallel in healthcare. You have an electronic medical record system. Now IBM and Watson have made noise for a decade or longer about AI diagnosis or what have you. I don't know how that's panned out. It still seems more promising than anything. However, having a system of record to keep things organized and to allow for communication, collaboration, and tallying up the way people might tally up data within an electronic medical record, there's something useful there that interface between people and technology that's supporting them, not replacing or automating their thoughts.
There are opportunities to use diagnostic tools and AI to help reduce noise, variation, and provide some job aids to help the judgment along to say, “Did you mean to look at this? Would you consider that? Did you forget this step?” There are a lot of great things you can do to help reduce that variation and make us less dependent on having a bad day or being tired or rushing through a task. Again, those critical moments of judgment, insight, intuition, and creativity are things that still humans are absolutely best suited for.
A final point I'll make before moving on back to the book, there are certain things that software can more rigorously track and follow up on. For example, if somebody has said, “I'm going to complete a certain task or assignment by a certain date,” that can be automated. That reminder or something that flags the human to intervene and whether that's a manager or an improvement coach to jump in and try to help but that's pretty minimal when it comes to automating things.
This is where our brains when we have a lot of the things taken care of with routine, standards, and automation, our brains can be free to do those other things. I like to argue that if you had to rethink the process of brushing your teeth every day, that couldn't be you're a-ha moment when you start thinking about a problem at work and let your brain run free with it because your brain is busy just trying to get through the tasks. We do want to standardize things, automate them, and make them a lot easier so that we can use the human brain for tasks that it's best suited for.
A quick aside. I was thinking the other day. The biggest time-saving technology for me is Google Maps or GPS software. Think of how much time you used to invest into researching getting from point A to point B in advance, and God forbid something goes wrong or changes with your route along the way. Those are hours that can be redeployed to something more enjoyable or more productive.
I used to go on trips 3 to 4 weeks a month and I'd map out and print the map instructions for airport to hotel, hotel to client, client to dinner, dinner and back to the hotel. Every little segment I was going to be on was its own little set of maps. What a wasteful task that has proven to now be, but was necessary at the time.
I had a 2004 model-year car that I got rid of in 2015, and in the back seat pocket, I found a printed-out Yahoo map from 2005. The car was a little time machine.
Right on top of it is laying an old garment which was discarded a few years later, probably.
Back to the book, People Solve Problems, it had been how many years between The Hitchhikers Guide to Lean that you, you co-authored with Andy Carlino and this book People Solve Problems?
That came out in December of '05. I keep wanting to shorten that duration. It's late in December that it's an '06 book. It's been a long time. In my head, it was ten years, but clearly, that was off by a significant factor.
That's not criticism. I was curious about the fifteen years, and I'm sure along the way, there are many books you could write next and you're thinking of in terms of topics, themes, or structure. Out of all of that and considering all the things that you're doing and you're busy, what was the spark then that said, “This idea now, I'm going to sit down and move forward with it?”
There are a couple of factors. One is what I had always said for the longest time. When lean was commonly referred to as a waste elimination method, I pushed back pretty hard on the Lean Community as a whole. I said, “Waste is a type of problem and it's not all about waste elimination, it's more about problem-solving.” That was a position I've held for a long time. It's not only about problem-solving but it's more about problem-solving.
On top of that, I essentially started a new advisory and coaching firm at the beginning of 2020, I've wanted to write a book for a while again. The Hitchhiker's Guide continues to do well still. For some reason, it was like, “I don't feel like I need to write another book.” However, in problem-solving, I had no tools. I wasn't particularly focused on teaching people leadership, their own tool set, and their own leaders who design how they're going to do things.
Those things work out quite well which means that I don't have to tell you what template to use or how to do these things. There are people inside that know how to do it, but they're still struggling to make problem-solving come to life, to breathe, and to flourish in their organization. For years in culminating and writing this book, I've been paying attention to what else is. Why after tool and after tool for problem-solving do companies still struggle to make problem-solving flourish in their organization? That's what got me to start digging into this topic in a much deeper way.
There's a lot of depth in a lot to dig into with the book. The first question that comes to mind is that early in the book you talk about the idea of behaviors driving action. What are some of the key behaviors that can either drive more problem-solving activity or maybe more importantly, better and effective problem-solving?
I can't remember if I start with this one, but it's perhaps my favorite and that's the key to learning deliberately. Problem-solving is by definition or at least my definition a learning activity. If we already know the answer, then you don't have to problem-solve, you execute. Even most of the time that we think we know the answer, we can execute. If your computer's glitchy, 19 out of 20 times, people restart their computer and at least half the time, the problem solves itself. You don't even want to understand why. You just accept the gift and move on.
Problem-solving is, by definition, a learning activity. If we already know the answer, then you don't have to problem-solve; you execute. Share on XHowever, problem-solving is about understanding why, what's going to work, why the problem exists, and what the gap is. You have to approach it from an orientation of learning. As an observable side of this, I'll go to organizations and even if they do it digitally, you can still get the sense of, “Did they solve this problem on the template A through Z in a linear fashion?”
Every step was filled out sequentially along the way with no backtracking, no backspacing, no deleting, and no erasing. Every time I see that, not in one problem but in all of them, I can tell they're not treating it as a learning activity. They're treating it as a documentation activity because there's no way that we're right about each step linearly that often. In a learning orientation, problem-solving means we circle back. It's not steps A through Z.
We bounce around the alphabet. We learn something and we go back a step. It's a much more circular process of discovery. That's just an observable indicator of when I think people are treating problem-solving like a procedure instead of a discovery method. Along with that, I'll point out another behavior. To collaborate, I want to say more about it but I used that one word. Collaborating is an important behavior because you'll convince an organization that they should be working across organizational boundaries in problem-solving but then they start doing things like having pre-meetings.
It's like, “Let's have a pre-meeting and decide what we want to share with that group and what acceptable answers are we willing to negotiate.” That's not collaboration. Collaboration is let's come to the table, join forces, and figure out how to close the gap. Again, setting the meeting and having another group in the meeting to talk about the problem isn't collaboration. It's how we approach that conversation. That's the behavior that makes it work. Those are a couple of examples that I find challenging for organizations to embrace.
I don't know if it's a gray area or an overlap between mindsets and behaviors that are driven out of the mindset. In the book, you've touched on this a little bit but I wanted to hear more from you. You talk about the idea of testing to learn and testing throughout the problem-solving process. The way I would state behavior is helpful is shifting from knowing things to figuring things out, learning, and testing, for example.
“We know the root cause,” which begs the follow-up question, “Do you really? How do you know or do you just have a suspected root cause?” Those are some of the things that I think you can test. I was wondering if you can elaborate a little bit more on building your chops around testing instead of knowing the importance of that.
One of my favorite questions as a coach is, “How do you know?” Most people think about this as the last step of problem-solving. It means you're going to validate that your solution works and absolutely do that. Test the solution to see if it produces the result you expect but there are opportunities along the way where somebody writes a problem statement. How do you know that's the gap? How do you know that standard is sufficient? How do you know that gap is what the customer experience is? Here's what the root cause is. How do you know that's the root cause? In physical environments, these are easier things to test.
If you're troubleshooting an electrical system, there are a lot of ways to test whether your hypothesis is correct around the root cause. “I think this is where the trip is.” We can isolate and test it. You can see if it's a broken leg or overcharged. It's much easier to do in a lot of those physical systems. Our processes are not so easy, but still important because everything is a theory.
Our problem statement is a theory. Our root cause is a theory. How do you know? Here's our target state. This is what we think good looks like. How do you know that too? You always want to be testing. There's a phrase from the book called Noise, and they borrowed it from another book. I'm not going to recall the backward reference.
Is this the Daniel Kahneman book, Noise?
This is the latest Daniel Kahneman book. With Thinking, Fast and Slow, most of his life is research, and then everything that didn't make that book ended up in Noise. They used the term perpetual beta. This is more about forecasting specifically, but they talk about the best forecasters being on perpetual beta, which means everything is held lightly. Everything is an assumption, subject to change, and subject to challenge.
Everything is an assumption. Everything is subject to change and challenge. Share on XI think it's a great phrase and a lot of the spirit in which we do, we should engage in problem-solving. The way this culminates and the best indicator of this behavior is not what happens when you get an answer worse than what you expect, but what happens when you get an answer better than what you expect? Are you still curious, or do you move forward? If you're trying a different idea and you expect to be able to shave 20 minutes off of a task and it turns out you saved 50 minutes, you are like, “That's interesting. I better bank that. I put myself down for 50. I am smarter than I thought.”
That's a natural reaction but the learner is like, “What did I miss? I'm glad it's 50. I certainly am not going to not throw the idea out because it gave me better results than I expected but I'm a little concerned that I don't understand why things are the way they are.” That's the learner mentality that I think is a great place for it to show up and to test whether it's there because it's much easier to bank the surprise game and walk away.
Think about a sales team and they start writing off a customer or a prospect. They are like, “They're done. They're not going to buy,” and then they turn around and buy. You're like, “Great. I'm thrilled but wait a minute. We wrote them off and then they bought. What did we not understand? What are the consequences of that gap in knowledge?” There's no tool or software that forces you to do that. It requires, I don't say natural curiosity because it's not natural most of the time but that decision to operate in a behavior of curiosity.
I think the curiosity is key. One thing I've reflected on and talked to people about is retraining ourselves to not feel ashamed over not knowing something, being wrong, making a mistake, and instead trying to be excited about the learning that comes from that. I had a guest on My Favorite Mistake Cash Nickerson who said it well. He said, “It takes humility to even entertain the idea that your idea could be a bad one. The business that you start might not work out. The improvement idea that you have in the workplace doesn't get to the root cause of the problem.” To even think of that as a possibility requires humility and that's sometimes been for one reason or another drummed out of us. We're not willing to admit, “I tried something and it didn't work.”
I refer to myself as a recovering engineer. I've got three engineering degrees and one of the things I'm trying to recover from is the idea that we should be right all the time. I used to hold that belief before I was an engineer anyway, so it was a more natural thing but this is a behavior that can be learned. I've been an entrepreneur in the past. I don't consider myself one right now because the business I have, I'm not setting up to scale. I am not building a business. It's only me doing what I do, but I would still and I'd go in and out of this practice.
For certain periods of time, I would force myself to come up with a new business idea every single month. The idea was to force me to be creative because that takes practice and thinking strategically and all the things. How would you put this business together? It doesn't make sense. What questions do I have? That was always good practice but the other part was to be able to look at my own ideas and say, “That's awful. That's not going to work. That's bad.”
I can throw it away and be okay with throwing it away. If you fall in love with every idea, then the cycle of testing your idea can be very big and cumbersome. If you look at more ideas and say no to some of them or many of them, you realize that not only is it okay to have bad ideas or wrong ideas, it's natural and it makes you smarter about what the good ones are.
Not only is it okay to have bad or wrong ideas, it's natural, and it makes you smarter about what the good ones are. Share on XIn the past few days, I gave some advice to a client that has dramatically ramped up their problem-solving. I was challenging them on what percentage of the ideas tested worked. So far, it's been all of them. I was like, “Are you challenging yourself to stretch, be creative, and do breakthroughs?” That probably suggests to me that you're not stretching yourself very far because they shouldn't all work. You're not trying very hard at breakthrough performance if every idea is such a slam dunk that it works each time.
We talk about learning or unlearning and relearning these behaviors. You probably know of the exercise. I don't know if you've participated in it, where you're given a bunch of materials like uncooked spaghetti and marshmallows and whatever else is in that and you have to build the tallest structure that you can that doesn't collapse in a certain period of time. I think I've only read about this.
I've facilitated the marshmallow challenge many times. I've facilitated it for several hundred people once or a few times. It's a great exercise because teams come together and they want to be right. They have a time limit and they don't experiment or test. They only design with an assumption and then they try to win. It's interesting that a lot of kindergartners do better than a lot of professional adults because they're more willing to play these ideas, to be wrong, and to try it out because they're not expected. Who is expected to have the answer to how to put spaghetti and marshmallow and tape together? There was no class on that even if you were an engineer or an architect. You shouldn't have the answer so go ahead and play. You're facing a new territory and most of the time we are.
Going back to when you say you're an entrepreneur. I think that's probably in your nature. You don't lose that. You might not have an active startup at the time, but to be fair to you, I think bringing a book to market is an entrepreneurial venture. It's not forming a company, but thinking of the book as a product, it helps ideas scale in a way that might scale better than relying on going and giving talks or speeches. Did you think about the book as a startup in any way?
A bit. I was less concerned about the profitability of the venture, in part, because I wasn't trying to employ people through it. As an entrepreneur, my big focus is not on how much money I make as the founder or owner, but on all the people that depend on the business having a livelihood. That's stressful but also rewarding. To me, it was less about the profitability of the venture, but it is about testing the ideas. It is about providing access to ideas at a lower price point than engaging with me directly. With my old business, I wanted to keep lowering the lowest entry point.
Entrepreneurship should be less about the profitability of the venture and more about testing ideas. Share on X“Instead of a consulting engagement, could you attend a class? How cheap can that be?” It's like, “Write a book. Now you can test the ideas even cheaper or at least access them.” There are a lot of people that will never call me or engage me as a coach or an advisor, whether they can't afford to or never think to or whatever. They don't even know how to find me but if they can find some ideas in the book that are useful at a much lower price point than working with me directly, then fantastic.
What's interesting is the book is its own business model or is it simply a product line under the current one? It may not matter because, in a lot of regards, it's also, “What do I gain from the project beyond the financial reward of selling a book?” I feel like I have always sharpened my own thinking by writing. It's one of the reasons I wrote a column for many years and why I started guest blogging for you long before I had my own blog. Writing I think makes me smarter.
Going back to your earlier question, that's one of the reasons I wrote this book is that I had a lot to say, but I didn't have a lot to say well. Writing the book forces me to learn how to say these things or at least say them better. I'm certainly glad to have published if I decided not to publish and I had all this writing. It would've been a big exercise for myself but it still would've been a worthwhile one.
The title of the book is People Solve Problems. It's not a book about “A3” problem-solving. It's not a book about PDSA or Toyota Kata. In the book, early on, especially you make this point of I don't know if agnostic was the exact word you used, but not caring so much about what the exact framework is. Is that a fair way of recapping that?
Absolutely. I do say it's a tool-agnostic book. The first version of it was not because I like A3 problem-solving. I've got Art Smalley and Durward Sobek's Understanding A3 Thinking right over my shoulder. It was my favorite of the many good problem-solving books. That's my favorite. Some of the best problem solvers I've ever met use different tools. That's an acknowledgment. The best problem solvers I see use some of the same tools that some of the worst problem solvers use.
I felt like tools matter without a doubt, but it's not the distinguishing factor in success. I wanted to make this not about lean and not an extension on A3, but to highlight the challenges that are faced, whether somebody is doing Six Sigma, DMAIC, Shannon, A3, 8-Step, or whatever. The barriers to success are pretty common across all of those tools, at least the barriers that I observe organizations have.
You talk about A3 problem solving, which is a framework I find helpful. I've tried to practice, share, and teach it with others. One of the key steps in A3 problem solving is defining a good problem statement. In the book, you do talk about the importance of this. Can you talk about that outside of any of the frameworks when it comes back to behaviors and such?
As a core capability, first of all, every tool pretty much has some step where you form the problem statement. That's a pretty universal thing as it stands alone but there's also a lot of problem-solving that happens without anybody ever picking up a tool. I don't want to say amusing, but what I'm curious about is that when people decide to pick up a tool, they're like, “Let's craft a good problem statement. What are the criteria for a good problem statement?”
When they're not or when they're in a meeting talking about a problem, they brush over that like it doesn't matter. It's like, “If you spent 15 seconds, 30 seconds, 5 minutes, or whatever, you don't have to whip out a problem-solving tool if you only said, “Let's frame the problem. Let's understand what problem we're solving in conversation mode. You would still have a much more productive conversation.
Seeing it as a gap, whether it's a strategic gap, a gap to the standard, the desired, or what the customer wants, and without bias towards a solution or cause. Also seeing it as essentially others would agree, the same way, and as malleable. We can change how we define the problem based on our socialization, engagement, testing, and stress testing of the idea of the problem statement that we can then change how we've defined the problem statement.
For example, I had a problem statement written around my weight, and I've taken a lot of weight off but in the end, it was much more about health than it was about weight. Weight was a good symptom, but it wasn't the actual problem statement I was after. Now that I'm like, “I've hit a certain weight. Do I keep losing weight or do I work on other things? What's the real gap?”
I don't need to write it down. I can and probably will but it's the thought process of understanding the gap. As a gap, being malleable with it, and being curious about, “Is that the right gap and what do we understand or not understand about it?” Regardless of your problem-solving tool, or even if you're having a conversation without a problem-solving tool, the question matters.
We've got a question for you. I'm going to put you on the spot and ask for a little coaching or feedback. One problem or it's more of an improvement and I could frame it as a problem. This won't be the most precise problem statement articulation, but I've been trying to grow the audience for the My Favorite Mistake show. You mentioned cause and effect. I wanted to explore this a little bit.
You'll probably pick right up on what I would expect you might want to coach me on here. I'm trying all sorts of different countermeasures. I've engaged a PR firm to help create some opportunities to be on some radio shows to try to talk about the podcast and the themes of the podcast. I've been a guest on other podcasts. I went and tweaked the formal name of the podcast to help try to return better if somebody were to search for business mistakes.
My podcast didn't come up in the results, but it's now My Favorite Mistake: and there are some words there. It's coming up better in some of the searches. I'm trying all these different things and help solve this problem. What are some questions that you would ask or guidance that you might give me about trying all these?
Without being an expert in the domain, which I'm anything but I pretty much stop at recording podcasts rather than knowing what makes them successful. I would start to ask questions about what good looks like and what variables matter for growth from a tracking standpoint. While you have a lot of episodes of My Favorite Mistake, you don't have the same duration as other podcasts. What matters more? The longevity of it from the first date to the most recent date or how many episodes there are? I don't know, but how might we compare that against other data points that you have?
There's a variable on maybe not considering if the podcast is too long or too short.
If you start to look at your own body of knowledge, you also have to ask yourself, “Are there other bodies of knowledge out there? Do I compare this to the Lean Blog show or do I compare this to other podcasts that are similar in domain and style? The existing knowledge you have is mostly about your own podcasting. Also, you've listened to others. You've listened to advice. You've talked with many other podcasters, but quite frankly, most people you know in podcasting have less experience than you.
If you start to look at your own body of knowledge, you also have to ask yourself, 'Are there other bodies of knowledge out there?' Share on XYou're usually more in the advice-giving domain than the advice-receiving domain. How do you get curious about what others have done in that space? The other thing I think I'd start to poke at is you're trying a bunch of things. You're trying them all at once. How do you know that 5 of them helped and 4 of them hurt? You ended up a little bit better off, but you could have been a lot better off if you had only done the five things that helped.
We might have enough base knowledge of how things were to go, “Will this actually hurt?” Maybe it won't hurt or it won't help when done at the same time as something else. Is it throwing spaghetti against the wall and seeing what sticks? Is it simply trying to prime the pump and then see what happens? Is it trying to develop a recipe for what is going to make a difference?
One of the key questions I ask which isn't the heart of what you're after is, “Are you trying to build knowledge for the next three new podcasts that you start or are you just trying to build knowledge to support this one podcast?” It's because the knowledge that you gain from learning has a different return on investment depending on how you see that knowledge in relation to the rest of your work. Is this scalable knowledge that you're building or is this acute specifically applied knowledge?
There are a number of things you touched on there. For one, I figured that as you did, you would pick up that I'm probably trying too many things all at once, which then completely muddies the cause and effect of which of those countermeasures I put more time and/or money into versus not. I'm muddying the water there. My other reflection is I'm being more of an experimentalist than a problem solver.
I don't think this is a case where I can say there's a root cause for why. I'm trying to grow. It's not even so much solving a problem. I could define anyone who's not reading as a problem. That's not the right way to say it, but I'm trying things. I'm falling into a trap of trying too many things at once as you pointed out.
Absolutely. At least if you want to understand why you got the result that you wanted so you could double down or not double down. Even around the problem statement as you said, they're all gaps. Maybe the gap isn't every person in the world should tune into this show, but what is the target number and by when? A lot of times, I'll see problem statements written as, “This should be faster, bigger, and better.”
Even if it's faster, it's like, “How much faster?” We don't know. We only know it's too slow.” Write your problem statement with a blank space that says, “It currently takes X and it shouldn't take Y.” One of the things we have to do and be curious about and explore is what should Y be. What is the target? If we haven't defined it yet, theoretically, most problem-solving tools would say, “Define it first before you go on problem-solving.”
However, in a lot of cases, people don't know. There's nobody that can draw a line in the sand and define it. It takes their exploration of getting into the problem to do the learning that tells you what the answer maybe should be. That's why I say, “Write Y or put a space there or a blank,” and remind yourself that it's not faster. It's X amount faster and I got to figure out what X is. That's something I should be curious about as well.
Going through that impromptu exercise and thank you for humoring me with that, you apologized a little bit about, “I'm not an expert in this domain.” I think the discussion proved that you don't have to be a domain because I wasn't asking you for the answers. “Jamie, what are the three things I should do to grow my podcast?” That might be something born out of expertise, but coaching around thought processes is pretty transferrable.
That's where I think coaching and problem-solving are one of the most underutilized investments there. For one, we're more focused on the answer than we are on the process. Once we're in the problem, why are we doing problem-solving? To come up with an answer. We are naturally going to be more focused on the answer.
Coaching and problem-solving are two of the most underutilized investments. Share on XThe coach can help us focus on the process. When the process has gone awry, they can call it out. They can call attention to it. I think that's one reason. Second is that as a coach, even if I'm not that good, I am putting all of my energy into the process, which means that my learning as a coach around the process accelerates faster than it would by doing the problem.
Again, when you're in the problem, you're two parts focused on the solution and one part focused on the process no matter how hard you try. However, if you're the coach, you're 100% focused on the process. You can learn about the process better and faster. The third thing I'll say is, and this is reinforced in the book Noise, although it's not where I get it from, there is wisdom in crowds. There are catching blind spots. There is thinking out loud and things like that.
I believe that in a good organization, the minimum number of people involved in any problem is two. Whereas in most organizations, one individual can conceive of a problem, investigate it, come up with a solution, and even implement it without interacting with anybody if they so choose. I believe that makes us not just worse at problem-solving but makes us less effective in the solution space as well.
One other thing I wanted to follow up on is there are two things that might be interconnected. You might want to address them one at a time. When you were going through coaching me, you brought up the idea of when you rely on your own experiments versus looking to others for experience, knowledge, and information. The second question is coming back to something you mentioned, and I know you write about, is the role of intuition versus data.
The idea of what is our own domain and where is my knowledge versus somebody else's is that at some level, we have to treat every instance, every step in repeat as its own experiment. It's like, “This recipe works great.” It doesn't work as well for me. What's different? Is it the kitchen? Is it the oven? Is it the ingredients? Is it the person? There's always something different. Even now, I was listening to someone talk about a solution they had put in place and they're now going to apply it to this next step in the process that they are responsible for.
They're responsible for this process. It worked in the front half. Now they're going to try it again in the back half. Are you going to try it or are you going to test it? Are you going to implement it? It's like, “Just because it worked once, it doesn't guarantee it's going to work in the second stage of the same process.” It still should be treated as a test. This is one of those places where intuition starts to come into play. It's like, “How similar is that? How similar are situations? How similar are our podcasts? How similar is the front half of the process to the back half of the process? What might matter?”
If you go look at academic research and in most cases, it tries to draw a correlation, whether it's through actual physical modeling or data sets. They basically try to do some type of study or experiment and draw correlations between key variables. However, before they start, they decide what variables to include and which ones to exclude. Did they model the whole world to draw that conclusion or did they use their experience-based intuition to say, “This is where I think I can draw the line?”
Without question, they sometimes draw it way too narrow and intuition does not always serve us well but we utilize it whether we think we are or not. I have fifteen problems I could go solve. Which one do I want to go solve? Do I have a rigorous analytical process or did I have a gut feeling? Do I need to test everything I write down or do I only need to test these three things? There is some intuition in all of that.
Problem-solving is much better when we acknowledge it and embrace it. Essentially, when we create the room in our processes to allow the intuition to seep in, to breathe, or to be tapped. Whether that's a facilitated exercise that allows people to tap into their creativity and their thought process or sleeping on it, which is a common technique.
What I love to do now is when I have not so much my own problems, but the people I coach. When they're wrestling with difficult problems, I'm coaching them over a period of time with the challenges they're facing. If I've got a call coming up on Tuesday and I'm going for a hike on Sunday, let that question linger in my head, be more curious about it, and see what comes out.
I'm not trying to solve it while I'm on my hike, otherwise, I bring a notebook with me. I am allowing my intuition to perhaps interact with that question or that problem for a period of time. Intuition is always there. We just pretend we're analytical all the time. We're much better off when we embrace and allow intuition to be used effectively along the way.
The way you talk about intuition makes me think of a concept that's used a lot in the Training Within Industry approach. The word is a knack. Sometimes you have a knack for it. For example, I'm building on a different approach like a recipe. Let's say, Jamie, you said, “Mark, I know you make pizzas in the backyard. Send me your dough recipe.”
I could send you the recipe, which is written out of mathematical measurements of flour, water, yeast, and salt. You may report back to me and you're like, “That dough was dry. It didn't even really form into a ball.” I'd be like, “I forgot to pass along the knack of there's the formula, but some days you have to add more water based on humidity and other factors.” You say, “How do I know how wet the dough is?” I'm like, “You just know.“
The thing is our brains are incredibly capable. There is a lot of research behind what percentage of our brain power we're tapping into, and it's small. Whatever the number is doesn't matter. Here's a good example of how our neural system is far more effective than our deliberate thought process. Stand on one leg and try to think your way through. Lean to the left, lean to the right, rotate your hip, and rotate your ankle. Try to analytically have balance.
You're going to fall over. Allow your body to make all those neural connections and adjustments and it's amazing. Balance works. The thing is that our brain is capable of learning that we don't have the numbers, the words, the frameworks, the lines, and the pictures to articulate. The smarter we get, the better we are at converting what we do internalized to a recipe, to a process, or to a procedure.
I always like to say that art is a science that we haven't yet fully articulated. It's not that there isn't science behind good dough. There is science behind it, but how do you find it? We don't know how to articulate it yet. We don't have the words, the math, or the way to put it into a recipe yet. We still rely on the knack, the art, and the intuition to figure that out which is science we haven't figured out yet.
Art is a science that we haven't yet fully articulated. Share on XI like the way you put that because when it comes back to the dough, I know how wet and sticky the dough should feel. It's almost too sticky to handle, but not too sticky but some of this, we don't know yet how to quantify or I could give you a formula. I'm like, “You should use 70% water by weight to the flour.” There could be a formula that involves the temperature, humidity, or age of the flour. There are these different variables that, as you said, we don't know how to make formulaic.
I'm much like you with pizza. I'm playing with the art of making espresso. You watch videos and they contradict each other left and right. “Don't do this.” “This doesn't matter.” “This is the most important step.” You listen to these and it's hard to conclude what the science is. There are things that are scientific studies, but even that, the metric is, what's the solubility of the coffee in the water? That's a measure. Is that the measure?
There are people that are like, “I'm good at tasting coffee.” Maybe I'm not as good. I am trying to develop my own science, but more importantly, on the pathway of developing my own science, I'm developing my intuition. I don't think I'm ever going to get into science because nobody seems to have in this domain. However, I can at least, in pursuing it as a science, I get my intuition sharper when it comes to this because the age of the beans and the ambient temperature and all of these things do, in fact, matter.
In a way, everything we're talking about there with dough and espresso on some other level, maybe a conversation about lean, problem-solving, formulas, experience, and conflicting advice from different sources. Jamie is a good source and there is a lot of good stuff in the book, People Solve Problems: The Power of Every Person, Every Day, Every Problem.
The last thing before we have to wrap up is there's a section that's titled Call A Band-Aid a Band-Aid. I have to tell you real quick. When I worked for Johnson & Johnson, at some point, I do believe there was a memo that told those of us in the consulting group to not use the term band-aiding a process because that was a registered trademark of Johnson & Johnson. Also, band-aiding the process has a negative connotation.
It does and it's okay.
Why is that?
It's not a permanent fix. It's okay, but let's not pretend we've solved the problem. Certainly, if you're part of J&J, you probably shouldn't use it in that way. Since I'm not, it's okay. It's a common term. It's out there, but again, let's not pretend that was problem-solving. That was covering up the symptoms so it doesn't get worse.
Sometimes, a Band-Aid might be necessary, but if you're constantly cutting yourself all the time, you need to step back and say, “What do I need to change about my tools, my process or what have you to avoid needing to use all those adhesive bandages?” We could adhesive bandage that process.
It doesn't make for a good chapter title, but yes, it's a necessary thing. We have way too many things wrong to not use some Band-Aids. Band-Aids are very helpful. They prevent small problems from becoming big problems. It's tremendously valuable, but we didn't solve the problem and we shouldn't pretend that we did.
Band-Aids are very helpful. They prevent small problems from becoming big problems. It's tremendously valuable, but if we didn't solve the problem, we shouldn't pretend that we did. Share on XI do have to wrap up here, but again, our guest has been Jamie Flinchbaugh. The book is People Solve Problems: The Power of Every Person, Every Day, Every Problem. Please do get that now. It's available in paperback, Kindle, and audiobook. You can learn more also at JFlinch.com. We call him JFlinch for short.
Thank you, Mark. I appreciate you having me on.
Thanks for being here.
—
Thanks again to Jamie Flinchbaugh for being our guest. You can find Jamie's new book on Amazon. Again, his website is JFlinch.com.
Important Links
- Jamie Flinchbaugh
- Episode 5 – Past Episode
- Episode 6 – Past Episode
- Episode 10 – Past Episode
- Episode 64 – Past Episode
- Episode 261 – Past Episode
- Episode 50 – Past Episode
- Episode 316 – Past Episode
- Measures of Success
- Lean Whiskey
- People Solve Problems: The Power of Every Person, Every Day, Every Problem
- KaiNexus
- The Hitchhikers Guide to Lean
- Noise
- Thinking, Fast and Slow
- Cash Nickerson – My Favorite Mistake Podcast Past Episode
- Understanding A3 Thinking
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
