In the Kaizen process, we ask everyone–regardless of role or title–to identify problems (or opportunities) in their daily work. They're encouraged to write down an idea that might solve the problem–or at least move things in the right direction.
What's written on the Kaizen card, or submitted into software like KaiNexus, isn't a final answer. It's a starting point–a spark for discussion among a team or with a supervisor.
Recently, while coaching a health system on Kaizen, I got a thoughtful question from a physician who had participated in the excellent Lean healthcare training at the University of Michigan. She said:
“In our training, we were told you should never jump to a solution when solving a problem.”
She's not wrong. In structured problem-solving–especially for complex or high-impact problems–we teach the importance of understanding the current condition and digging into causes. We don't want people prematurely locking into solutions based on assumption or gut feel.
But here's the nuance:
Not every problem needs root cause analysis. And not every improvement needs to be an event.
Some Problems Are Just… Fixable
Let's say someone identifies a problem:
“Our IV trays are disorganized.”
A team member suggests:
“Let's remove the unnecessary items and standardize the layout.”
That's a great idea. We don't need to run a full-blown A3 or gather a cross-functional team. We can try the idea. We can involve those who use the trays. We can test the change, gather feedback, and adjust as needed.
In Lean thinking, this is what we'd call a “just do it.”
Quick action. Low risk. Low cost. High usability.
It doesn't mean we skipped thinking–it just means the thinking wasn't formalized in a structured event or document. These small improvements still follow the spirit of PDSA: Plan, Do, Study, Adjust.
Related post:
Other Problems Deserve More Rigor
Now, contrast that with a more complex challenge:
“Patients are waiting too long in the waiting room.”
That's not something we fix with a label or a bin. It's systemic. It might require:
- Data collection
- Cross-functional input
- Root cause analysis (like the 5 Whys or fishbone diagrams)
- An A3 problem-solving approach
- Or even a Rapid Improvement Event with preparation, a charter, and full-time participation
Or maybe… we start smaller.
Can we break the problem into parts? Can we test ideas iteratively without creating risk or confusion? Can we avoid sub-optimizing one part of the process while worsening another?
The Role of the Kaizen Coach: Triage with Respect
As Kaizen leaders or facilitators, our job isn't to dictate solutions–it's to coach thinking and triage problems. We ask:
- Is this idea safe to try?
- Can the team test it quickly and learn from it?
- Does this issue have a broader root that needs deeper exploration?
- Is this something that could benefit from cross-functional visibility?
In other words, can we keep it simple–or do we need structure? Both are valid. Both are part of a healthy improvement ecosystem.
When everything becomes a project or event, we risk overwhelming teams and slowing down momentum. But if we dismiss structure altogether, we risk shallow thinking and short-lived results.
The sweet spot lies in discernment–something we develop over time, through practice and coaching.
Final Thought: Bias for Action, Balanced by Thoughtfulness
A healthy improvement culture isn't obsessed with tools. It's guided by purpose, people, and progress.
Some improvements require events. Others require encouragement.
If we treat every idea like a Rapid Improvement Event, we'll exhaust people and dilute urgency.
If we treat every issue as a quick fix, we'll miss deeper opportunities for learning.
Lean thinking–when applied well–gives us the range to do both. We can respond with the right level of structure, based on the situation.
That's not jumping to solutions–it's jumping into learning.
Please scroll down (or click) to post a comment. Connect with me on LinkedIn.
Let’s build a culture of continuous improvement and psychological safety—together. If you're a leader aiming for lasting change (not just more projects), I help organizations:
- Engage people at all levels in sustainable improvement
- Shift from fear of mistakes to learning from them
- Apply Lean thinking in practical, people-centered ways
Interested in coaching or a keynote talk? Let’s talk.
According to Daniel Kahneman, jumping to solutions is advantageous if: 1. the solution is likely to be correct (i.e., the answer is fairly obvious), 2. the environment is predictable (low variability) and 3. the penalty for being wrong is small.
When jumping to a solution, the study/check process in PDSA/PDCA becomes paramount. Despite our best efforts to assess a situation, the things we believe should be obvious just aren’t sometimes. Better to study/check thoroughly than pay the price later.
Yes, I usually recommend that if a proposed solution/countermeasure is small, inexpensive, easily testable, is not risky, and easy to undo (low penalty for being small), then the bias should be for quick action AND following up.
We can’t just Plan-Do or Do-Do, we have to remember to Study and Adjust to close the loop. Otherwise, we’re just randomly doing stuff.
Kaizen can have a bias for action, but can be disciplined and systematic (without being bureaucratic).
Mark,
This is a very good point. You do want to solve the symptom but know the root cause of the issue first. Leaders are pressured in getting results that they miss going through the process on fixing the issue permanently. Now, I always advise clients to make the decision based on what the data is telling them before they go out and start fixing issues. The response in many cases “what data?” That is where they need the most help in creating a process that helps capture the right data to make an informed decision on which issues have the most impact. During the process there will be issues what will be considered ” quick fixes” as long you can quickly identify the root cause. Thanks for sharing .
I like Joel’s filter above. Plan to use on Monday with a new group.
Additionally, why do we want every employee to be a problem solver?
My answer is we want everyone engaged and then we want the benefits of actual improvement.
Focus on engagement first. Rigorous RCA is often an extra burden, especially for the newbie. After folks are engaged, then focus on structured problem solving including RCAs. My personal experience is that you can have an engaging and meaningful kaizen system without RCA, but the ideal is to get to RCA thinking in the end.
Hi Mark,
I find table 9-3 in Gemba Kaizen very relevant here. Mr. Imai divides problems into three categories according to their nature, then he estimates their respective percentages and gives some example:
Type A: Causes are clear Countermeasures can be taken immediately (70-80%) examples: Standard was not followed, out of spec materials and supplies.
Type B: Causes are known but countermeasures cannot be adopted (15-20%) example: Occurs at the time of setup adjustment; example 2: Occurs during frequent stoppages of equipment.
Type C: Unidentified causes (10-15%) Example: Situation suddenly went out of control
I like it because it gives a clearer picture on what to expect in a workplace.
Thanks
Sami
I love this conversation! As a coach, I’m always looking to improve my skill at helping our folks find the sweet spot between analysis paralysis and jumping to solutions.
I agree that we can harness our people’s bias for action by accepting the just-do-it approach in the right situations….as long as the PDSA mindset is being utilized. It doesn’t even have to be a formal PDSA cycle using standard templates or anything, so long as the individual is pursuing the just-do-it in a scientific method-like manner.
Regardless of whether an idea falls into the “just-do-it” or “requires deeper RCA” category, there’s another factor at play, and that’s the question of whether the improvement effort is a step toward something or simply a stand-alone improvement. A stand-alone improvement that is not connected to any goals/plans/strategies/visions/etc. is still highly valuable just for the way that it engages our people and teaches them skills. But if that same improvement effort was connected to a bigger challenge, it becomes much more meaningful to both the individual and organization.
Mark,
The example you use:
Has an implicit “why” in there, i.e. “Why are our IV trays disorganised?” It could be that they have never been organised so the solution is as above. But it could be that there is a method for organisation and people aren’t following it, which begs another why: “Why are people not following the method?”
I suppose my point is that, especially at the beginning of learning improvement,it is sometimes useful to slow down, just a little, and for coaches to tease out the implicit “why?” even when it looks like there is an obvious solution. Mainly because it will stand people in good stead for more complex situations.
That’s a great point. Asking “wny?” once might be a helpful question, but that’s still not a formal root cause analysis.