Jamie Flinchbaugh has a new book out about problem-solving, People Solve Problems: The Power of Every Person, Every Day, Every Problem. The basic setup is reasonable - we all solve problems all the time, how should we think about it? I like how this isn’t a set of specific directions for problem solving, but rather what any approach to problem solving should have from the individual contributors through to the leaders. The book is primarily centered around problem solving in a Lean environment, and there are frequent references to Flinchbaugh’s books (along with other Lean-related books). But it is clear from the tone and examples that the concepts here apply well beyond formal Lean implementations.
“Problem solving is about discovery. It is a problem that we don’t yet know how to solve, and therefore it is an act of discovery, not just solution matching.”
Flinchbaugh goes through a basic structure of problem solving - even starting with a discussion of the problem that the book is addressing: that many “problem solving” implementations are heavily focused on the tools and artifacts, rather than on the underlying mindset and behaviors. The tools support the mindset, they don’t create it. This applies to almost any change effort - if we think that Lean or Theory of Constraints or Agile are the artifacts people see, we have lost the boat. It’s the cargo cult mentality or wearing black turtlenecks because your hero wears them. Flinchbaugh attempts to discuss throughout the book the underlying principles / mindset that create positive problem-solving behaviors, which then create the desired results of learning at the individual and organizational levels. Tools that are out there - those that work for people using them - have been developed by organizations over time and through practice, iteration. Without the inherent practice and internal learning, picking up someone else’s tools of any discipline inherently means you will be starting in a different place and get different results than the original developers. This thought may be deeper than it seems.
For people in many disciplines, the problem-solving general framework should look familiar. It might be the scientific method or your favorite learning loop or something more formally applied to problem solving.
Identify the problem. This may happen through observation or analysis, but it includes not only noticing something (“that’s interesting”) - it also implies that we see a difference between what we expect and what we got. And to be a problem, this difference in expectation has to be meaningful to the organization. It has to be worth pursuing. My wife likes to separate this into two statements, “Does it exist?” and “Is it a problem?” Flinchbaugh also comes to the idea that “lack of a solution” is not a problem. Not only does the problem need to make sense, but those who are affected by it - and by the potential solutions - should agree that it is a problem. There is also the idea here of being careful about playing Whac-a-Mole with symptoms, instead of finding an underlying core problem.
Coming up with ideas and selecting a solution. Is there really only one way to solve the problem? Do you already have a selected solution before investigating? Another sign that the problem-solving mindset is missing. The basic idea here is that once we have an idea of the underlying causes and conditions, there are likely many options to try. Thinking about the options might even change how we frame the problem. Are there aspects of the options which might require us to expand or narrow the scope of the problem? Might they create unintended side effects or raise other challenges?
Test and reloop. This is where many Change efforts stop. Pick a solution and go - damn the torpedoes. But in a learning organization - and problem-solving is definitely a learning process - we test out the changes. Sometimes that can be done in the lab or with a small group of people, or tested for a short period. What do we expect to happen? What actually does happen? Does this change our understanding of the situation? (Don’t be lulled into confidence if the results are better than expected, this suggests we don’t understand the situation fully too.) Do we drop the suggested solution or modify it?
I particularly liked Flinchbaugh’s early comment about these elements of problem solving - it is a process of learning and investigation. If your problem statement never changes while going through the process, it’s an indicator that you are following rote steps, rather than diving in and trying to learn something. We always see a situation differently after exploring it - in this case, the understanding of a problem will change as we explore it.
Flinchbaugh discussed the high-level process in the first third of the book, the rest was focused on the elements of a problem solving culture in organizations. To summarize, it is all about the learning organization - individuals shifting from being knowers to learners, relentless pursuit of the ideal, collaboration, trust, coaching, and leadership. Much of the discussion in these sections reflects back to the high-level process above and deepens it. I found the several chapters on coaching rather insightful, as that is a lot of what I find myself doing in my own work. But the coach isn’t only a formal role - how do we set an organization to create coaches at many levels (both formal levels and levels of capability)?
I picked up the book after hearing about it on Mark Graban’s Leanblog podcast with Jamie Flinchbaugh.