A Bigger Toolbox Does Not Create Better Problem Solvers
Knowing more tools does not necessarily make someone a better problem solver. Real capability begins with observation, understanding the situation, and learning to think before choosing the method.
PROBLEM SOLVINGDEVELOPING PEOPLETPS FUNDAMENTALS
A Bigger Toolbox Does Not Create Better Problem Solvers
There is a moment in almost every continuous improvement journey when the toolbox starts to grow.
5 Whys.
Fishbone diagrams.
Pareto charts.
A3 thinking.
PDCA.
DMAIC.
Value Stream Mapping.
Standardized Work.
And naturally, we begin to assume that the more tools people know, the better they will become at solving problems.
But that is not necessarily what happens.
A person can know how to complete an A3 and still misunderstand the problem.
They can build a perfect Pareto chart and still be measuring the wrong thing.
They can ask “why?” five times and still never get close to the actual mechanism creating the condition.
Because tools do not create understanding.
They help structure it.
And structure is useful only when there is something meaningful to structure.
The real starting point of problem solving is not the toolbox.
It is observation.
What is actually happening?
Where does it happen?
When?
Under what conditions?
What should be happening instead?
What changed?
What do we know, and what are we merely assuming?
These questions sound simple. But answering them well often requires more discipline than applying any particular problem-solving method.
This is one reason the genba matters so much.
Not because being physically present automatically reveals the answer, but because it gives us an opportunity to confront our assumptions with reality.
The closer we get to the actual work, the harder it becomes to hide behind abstractions.
The report says the process is slow.
The genba may show that the process itself is fast, but material waits twenty minutes between operations.
The KPI says quality deteriorated.
Observation may reveal that the defect was created several steps earlier than where it was detected.
The operator appears to be making mistakes.
Watching the work may reveal that the standard is unclear, the information arrives late, or the system forces constant improvisation.
The tool did not reveal those things.
Seeing did.
And this creates an important distinction.
Teaching someone a problem-solving tool is relatively easy.
Developing someone who can recognize what deserves attention, separate facts from assumptions, understand cause and effect, test ideas, and learn from the result is much harder.
That capability develops through practice.
Through coaching.
Through repeated contact with real problems.
Through being asked good questions instead of being given quick answers.
Tools certainly have value.
A good tool can help us organize information, expose patterns, communicate thinking, and prevent us from skipping important steps.
But a tool should support thinking.
It should never replace it.
When organizations focus too heavily on methods, something subtle can happen: people begin looking for problems that fit the tools they have been taught.
A problem appears, and the first question becomes:
“Which tool should we use?”
Perhaps the better first question is:
“What are we trying to understand?”
The difference is small in wording, but enormous in practice.
One starts with the method.
The other starts with reality.
And sustainable improvement depends far more on the second.
The goal, therefore, should not be to create people who know more problem-solving tools.
It should be to create people who can see more clearly, think more carefully, experiment more deliberately, and learn more consistently.
Then the tools become useful.
Because they are finally in the hands of someone who knows when—and why—to use them.
A bigger toolbox does not necessarily create better problem solvers.
Better observation does.
And problem solving should always start with the problem, not with the toolbox.