Everyone a Problem Solver?
A phrase I keep hearing more of in the Lean world, even at a few hospitals is that leaders want “everyone to be a problem solver?”
Is this uniquely Lean? Depends on what you mean by “problem solving.”I'd argue most organizations have plenty of problem solvers. They're just solving problems at the wrong level.
Can't find a pulse oximeter? A nurse might go scrambling around to find one. Problem solved! People are taking initiative. That's good, except it does nothing to prevent the problem from happening again.
Can't find a pulse oximeter a second time? Many “problem solvers” might So stash one someplace in a secret spot. That way, I can always get one when I need it. Problem solved! People are being creative (thinking outside the box, even!). That's good, except their “solution” creates a problem for the other nurses.
I don't mean to single out nurses, that's just one example.
We need to redefine problem solving. We need not just fire fighting, but a new kind of problem solving where:
- People focus on finding the real root cause of a fire, not just putting it out
- People focus on preventing problems
- People focus on not sub-optimizing themselves or their own area
So maybe instead of “everyone a problem solver,” maybe “everyone a process improver” is a better expression? What do you think?
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn.
Don't want to miss a post or podcast? Subscribe to get notified about posts via email daily or weekly.
Agreed on the need to redefine problem-solving along the lines you describe. We (The UK Rightshifting Network cf LinkedIn group) have coined the term “Rightshifter” to describe people (workers, supervisors, managers, execs) interested in or actively engaged in moving their organisations “to the right” on the horizontal axis of the Rightshifting chart (i.e. towards improved *effectiveness*).
I believe any term with the word “process” in it is doomed to fail, for various reasons.
Yes.It is better idea than everyone involved in problem solving process. Thus soem definite people can focus more dedicatedly on the problem solving and the rest people can be process improvers instead.
I’m certainly one who spouts ‘make everyone a problem solving’ and I’m probably going to stick with that. I don’t think that what the person was doing was solving a problem. They were fighting a fire. They were dealing with a symptom. But nothing was solved, and in my testing of people’s perception of problem solving, they don’t think they solved anything either. In fact, I could watch someone spend all day putting out such fires, but when I ask them about problems, they respond “I don’t really have any problems.”
So I don’t think we need to change from making everyone a problem solving, because as I coach and teach that point, it is still recognized as a formidable gap.
But it does raise a key point that I think doesn’t get enough attention, and this might be the heart of your point. We don’t have a common definition of a problem, of problem solving, or of problem solving. Without high agreement, then moving forward is very difficult. I won’t suggest that the lean community must agree to one standard, but inside an organization you better. If one person defines a problem as “something that a team is assigned to fix” and another as “any deviation from the norm” then there will be considerable gaps in discussions.
So for an organization to be successful, they must define problem solving and establish high agreement as to:
1. What is a problem?
2. What does it mean when we are problem solving?
3. Who are the problem solvers? What does that mean?
.-= jamie flinchbaugh ´s last blog ..Did we fix banking, or not? =-.
Hey Jamie – yes, I think that’s the core of it… I know when you say “everyone a problem solver” that you mean real root cause systemic problem solving (the type of problem solving that prevents future problems instead of just putting fires out).
But, I think a lot of non-lean thinkers would hear “problem solver” and say “yeah, I am one” when they are a fire fighter. So they’d see no gap were you see one.
I like the way you stated it and the questions you raised.
As we work on redesigning care on our inpatient units, we are teaching the nurses, techs, and others how to recognize problems and distinguish them from workarounds. Then the problems are signaled and analyzed to create root-cause solutions. It’s a different approach than I’ve seen in the past, but it’s working, and it’s encouraging as we spread the concept to other areas.
You bring up an excellent point Mark. It is important to define what “problem solving” means if you want problem solvers in your organization.
If people do not have a deep understanding of current state and the root cause of the problem, I would suggest they are not solving problems.
If people only PLAN and DO but never CHECK to see if their counter-measures are effective in order to to know what their next ACT should be, I would suggest they are not solving problems.
It is amazing how often buzzwords or memes enter an organization but do not have a common agreement what they actually mean.
.-= Brian Buck ´s last blog ..Presentation Secrets Of Steve Jobs =-.
I like the idea of starting with language that people in organizations commonly use and have a generally positive feeling toward – like “problem solving” – and then inviting them to rethink what we mean by it. In my experience and based on my understanding of how the human mind works, this is a more effective way to coach and connect with people than to introduce new words.
On the other hand, I am reminded of Peter Senge’s critique of the phrase “problem solving”, and I paraphrase: what do you get when you solve a problem? The absence of a problem. He made this point to emphasize the difference between solving problems and creating the future we desire (part of his model of creating a tension between Current Reality to Desired Future, which I believe you used in your book, Jamie). So even if we all had a shared understanding of problem-solving that included root causes, would it produce the results we want?
It reminds me of a
Dean, wonderful point about buzzwords. One of my colleagues pointed out recently that special lingo allows us to talk about things we don’t actually understand. Conversely, if we had to use “real language” to describe what we mean, we’d need to know what we meant. This, incidentally, is one of the most powerful critiques I’ve heard of MBA programs (of which I am a graduate): they give people confidence to use new words but not the competence to manage. In contrast, just-in-time learning about Lean fosters learning by doing.
First, the model you refer to is actually from Robert Fritz. Peter included it in his book, as many of the concepts in the book were integrated from other thought leaders.
Second, it’s HOW you solve a problem in this case. A lean thinker doesn’t seek to just remove the symptom. If I pull out of my garage and find oil on the ground, I could clean up the oil, or even just put down cardboard. Or I could fix the leak. Or I could understand the process for how I inspect and maintain the engine and improve the overall system. A lean thinker seeks the latter. And that is effective problem solving, as the system is stronger in the future than it was in the past.
.-= jamie flinchbaugh ´s last blog ..Keen to Be Lean in Healthcare =-.
Interesting that Peter Senge’s “critique” of problem solving is mentioned, but not pursued. Senge became famous as an advocate of systems thinking. Systems thinkers typically would have a problem with problem solving. Some things to think about from their perspective: (1) Problem solving is reactive. We wait till there’s a problem, and then “solve” it. We need instead to be generative (creating a desired future). (2) Removing a problem only gets rid of what we don’t want, but doesn’t give us what we do want. As Russell Ackoff once wrote to illustrate this, changing a television channel because you don’t like what’s on won’t necessarily give you a program you’ll want to watch. Put another way, the opposite of a strong negative is not a strong positive: Getting rid of a headache does not make you smarter; fixing a flat tire does not give you a better car. (3) To systems thinkers, important problems do not exist in isolation. Managers have an interdependent set of problems (called a “mess”). To break them down (by analysis) into individual problems, and then solve them as individual problems leads to suboptimization, and (often) return of the problems “solved” because of their interdependence with the remaining problems. Problems in messes are “wicked” in that they can’t really be solved, but must instead be managed. (4) Ackoff distinguished between resolving, solving, and dissolving problems. To him, dissolving problems was the best approach. To dissolve a problem is to redesign the system it occurs in (or design a new one) so that the “problem” no longer exists. Example: Have a problem losing your keys? Dissolve it by designing/creating a door that doesn’t require keys. Perhaps everyone should be problem dissolver instead of a problem solver? Design thinking is the underlying methodology. (4) Cause and effect is often multidirectional, leading to causal loops (A causes B which causes A which causes more of B, etc.). In such cases, what does it mean to do root cause analysis? More generally, not only must we operationally define problems, problem solving, and problem solver, but root cause as well.
I don’t know why systems thinkers would have a problem with problem solving, since many of the top ones would talk about it. Since Peter has acknowledge that Toyota’s probably the best example of a “learning organization” there is, I think that a lot of people are saying the same thing here, but just using different words. Don’t get hung up on whether someone uses the word problem. Focus instead on the behaviors behind the words. Let’s keep this simple:
A. A system thinker doesn’t not just react, they generate results by changing the design, management, and improvement of work. Any good lean thinker does the same. This is a point of similarity.
B. There is never an absence of problems. A systems thinker designs work to accommodate, surface, and deal with those problems. Unless the argument is that a good system has NO problems, then this is also a similar line of thought.
C. A systems thinker uses data, observation, etc. to understand how the system is working and then changes the system. Problems are a great source of data. They are a great source of observation. A lean thinker understands the reactive problems to go and improve the system. Again, I think this is very similar.
If there is a gap between what Peter really means when talking about systems thinking and what lean thinkers mean when talking about problem solving, I think that gap is in word use alone.
It’s interesting to see what my question stirred up. Systems thinking… now the design thinking buzzword (or is it a methodology… or a tool?).
I certain mean no disrespect to the late great Mr. Ackoff. But the talk of dissolving and not suboptimizing, is it practical to solve the whole world or universe as “system”?
OK, let’s say losing keys is a problem… you say design a door that doesn’t require keys (or buy one, there are ones on the market that don’t require a key, they use a fingerprint).
But how about I can solve “don’t lose your keys” by putting my keys on a carabiner inside a bag I always carry?
Is that “suboptimizing”? Where do we let pie in the sky (solve the entire system) get in the way of what’s practical, today? That’s where the “systems thinkers” lose me. Thinking has value, but so does action.
And, yes, I’m reminded of the Dr. Deming quote “Don’t just do something, stand there!!” I’m not for while, unplanned, unexamined action. But we can’t stand there forever or our organization might go out of business. Survival is, of course, not mandatory, as Dr. Deming said.
@Jamie – it seems that some people’s brains shut off when they hear a word they don’t like:
Good reminder that Senge popularized what Fritz first wrote (the creative tension model).
I do beg to differ that the difference between the creative tension model and the problem-solving model (even in the way you define it, as looking at the underlying processes) is mostly semantic–or that Senge (at least circa 1994) would agree. The difference he described is not in the means but the end. “Problem solving is fundamentally different from creating. The problem solver tries to make something go away. A creator tries to bring something new into being. The impetus for change in problem solving lies outside–in some undesired external condition we seek to eliminate. The impetus for change in the creating mode comes from within.”
p.s. that last quote is from an article Senge coauthored with Fred Kaufman in 1994 (“Communities of Commitment”). It had a big impact on me at the time, which is probably why it came up in my mind today.
Mark: Using the carabiner is an example of resolving the problem. Nothing “wrong” with it, but it doesn’t prevent the problem from recurring. What if you lose the carabiner (or the bag)? What if it gets stolen? Etc. What about the root cause of why you keep losing the keys? Perhaps that same cause may even make losing the carabiner or the bag more likely? Anyway, it was only an example to illustrate the meaning of the term. An example from health care: a drug for an illness that causes problems may resolve/solve the problems, but wiping out the disease dissolves the problems.
By the way, I don’t think “Don’t just do something, stand there,” is Deming’s. I have heard him say something similar when speaking about tampering by managers: “We would be better off if they just came to work and did nothing.” This was meant as sarcasm in reference to managers making things worse by tampering with processes, increasing variation. I think he would really have preferred they understood variation, and the difference between common causes and special causes (more buzzwords?), and how the need to treat each differently.
Amiel: That quote had the same effect on me when I first read it (and heard similar comments from Senge and Kofman at a Pegasus Systems Thinking conference). It illustrates what I was saying in comment (2) of my post. It is a difference in paradigm, not just linguistics.
Systems thinkers don’t really see problems as existing “out there” independent of those who define them. They see them as mental constructs, dependent on perspective. High oil prices are a problem for American car owners, but not a problem for an oil cartel; a snow storm may be a problem for those driving to work, but not for a ski lodge. By reframing the situation, changing one’s perspective, a problem “disappears.” The situation doen’t change, just one’s view of it. Problems exist in language.
Jamie: The behaviors of problem solvers and systems thinkers can be very different because they “see” reality very differently. A problem solver, for instance, may develop and act on a countermeasure to a perceived root cause, whereas the systems thinker may not see a root cause, but a set of relationships and the need to change the interrelationships between system variables.
Please understand I am just trying to challenge some beliefs to provoke dialogue and thinking, not advocating a position.
Mark – I think you’re missing Deming’s and Ackoff’s meanings a bit.
What Deming is saying when he says “Don’t just do something, stand there” is that we should pause and look around, assess the situation, look for clues as to what might be the root cause of what we just saw, develop a plan and then take action. He’s not saying this should take hours or days or months and cause your company to go into ruin in the process. He’s just suggesting that taking a moment to gather some data before rushing to judgement and taking the WRONG action is a better approach in the long run. Think of it as Deming-ese for “haste makes waste”.
What Ackoff is saying about not suboptimizing has nothing to do with solving world hunger in lieu of figuring out how to not lose your keys. Rather he’s saying that we should be aware of the system that the particular problem we are looking at is part of rather than, again, rushing to judgement and acting on a part of the system to the detriment of the whole. Attaching your keys via a caribineer to your bag is a fair idea, but do you only lose your keys when you have your bag or do you lose them at other times? Is losing keys a result of an underlaying problem that you aren’t looking at – a problem with the system of you and your keys? Eliminating the need for keys may be a solution for your system, and that’s fine; you don’t need to draw the box any bigger, unless your wife or child has a problem with remembering the code to the door, and becasue of that you’ve just suboptimized your part of the larger system of your family to its detriment.
Lean done right IS Systems Thinking.
Simon & Steve – thanks for the clarification and discussion. I said I was “reminded” of the quote. You’re right, it’s not a perfect fit.
Amiel and Simon,
Given the weeks/months/years that I’ve spend with Fred Kaufman, Daniel Kim, Peter Senge, Nelson Repenning and others, systems thinking isn’t new to me. I’ve taught it, continue to teach it, and consider it a core part of who I am not just as a lean thinker but as a human being.
I would COMPLETELY agree that someone who is just a problem solver does exactly what you describe. I couldn’t agree more. But I never said that. In fact, I wasn’t even describing a problem solver. I was describing a lean thinker. I have tried to teach for many years that a systems thinker, particularly as Daniel Kim would describe it, is a core element of being a lean thinker.
The person you are describing, which was NOT the person I was describing, is indeed a problem. They can’t see past the next problem. They feel validated by swooping in and being the hero for people. They solve the problem. And the next one. And the next one. But things don’t really change. And that there is what we call a big problem.
.-= Jamie Flinchbaugh ´s last blog ..Keen to Be Lean in Healthcare =-.
Jamie: Since you are a systems thinker, and therefore are someone who understands complex relationships, “messes” (i.e. interrelated/interconnected systems of problems) and multidirectional cause and effect, as described previously, may I ask: What do you consider to be the definition of a root cause?
How do you reconcile systems thinking with linear root cause analysis (such as the 5 whys) which presumes non-cyclical cause and effect?
Thanks, Deniz Martinez
[…] Everyone a Problem Solver? dal Lean Blog di Mark Graban: Problem solving oppure fire fighting? (traduzione automatica) […]
Maybe by posting I am just adding more confusion to the already muddled conversation. My understanding is that systems thinking is used to understand complex systems. Lean done properly tries to remove complex systems, so problems become much more linear. Understanding a defect after it is caught at the end of production is much harder than if it is caught in the process it was made. Understanding what is happening with your material flows and why is complex in a push system, when pull systems make the system predictible. The list goes on and on. Lean tries to make problem solving more linear, therefore making root cause analysis on one aspect of a system easier to understand. Both disciplines seem to have advantages, and are not mutually exclusive and there is always the grey area between the two. On a related side note, Toyota Kata is an awesome book on toyota improvement routines.
Brandon, I like your comments and have been thinking about this thread.
Clayton M. Christensen, Harvard Business School, from the forward in “Chasing The Rabbit” by Steven J. Spear writes:
“Hospitals try to coordinate the work of thousands of people to save thousands of lives from a nearly infinite variety of medical conditions. Rather than proposing complex solutions to those complex systems, Steve [Spear] breaks down the complexity. All these systems, at the ‘atomic’ level, consist of activities, connections, and pathways. You get them right, and even unfathomably complex systems become high performing and self-improving.”
Using the framework of the DNA of Toyota and the Rules of Use, systems thinking can be broken down into “atomic” root causes.
It is important to understand the impact of change to the system but the problem is usually found at the process level. There may be cultural systems that may block the change to be dealt with, but that doesn’t change the root of the problem.
.-= Brian Buck ´s last blog ..Presentation Secrets Of Steve Jobs =-.