Learning to See A Personal Journey Through TPS
TPS changes more than the way we solve problems. Over time, it changes the way we see. This is a personal reflection on moving from learning the tools, to understanding the system, and eventually helping others develop their own eyes.
DEVELOPING PEOPLETHINKING DIFFERENTLY
Learning to See
A Personal Journey Through TPS
There was a time when I thought learning TPS meant learning its language.
The more terms I knew, the more I felt I was progressing.
Kaizen. Jidoka. Heijunka. Kanban. Takt time. Standardized Work. Genchi Genbutsu. Muda, mura, muri.
You begin to recognize the words. Then you begin to use them.
Eventually, without realizing it, you may even start changing the way you speak.
A delay is no longer simply a delay. It becomes a flow problem.
Too much material becomes inventory.
Someone walking across the shop floor becomes motion.
A machine waiting becomes downtime.
A recurring problem becomes an opportunity for kaizen.
At that stage, it feels like you are beginning to see the world differently.
And perhaps you are.
But looking back, I think I was mostly learning how to name what I was seeing.
That is important.
It just isn’t the same as understanding it.
When knowing the words feels like knowing the system
I suspect many people who begin a serious journey into TPS go through something similar.
You want to learn everything.
You read books.
You attend training.
You make diagrams.
You learn the tools and their relationships.
You begin recognizing things in the workplace that you had never noticed before.
“That is overproduction.”
“That process needs a Kanban.”
“They need Standardized Work.”
“This area needs 5S.”
“We should do a value stream map.”
And there is something genuinely exciting about that stage.
For the first time, what previously looked like ordinary work begins to reveal patterns.
You feel that you have acquired a new pair of glasses.
The problem is that once we acquire a new pair of glasses, we can become very eager to see everything through them.
Someone teaches us a hammer, and suddenly many things begin to look remarkably similar to nails.
I certainly went through that period.
I wanted to understand the tools.
Then I wanted to understand them well enough to explain them.
Then well enough to teach them.
And teaching creates another kind of learning.
When you have to explain something to somebody else, vague understanding is no longer enough. Questions expose the gaps.
“Why do we do it this way?”
“What happens if demand changes?”
“Why is this waste?”
“Why can’t we simply add another person?”
“What is the difference between the standard and Standardized Work?”
Those questions force you to organize your thinking.
So becoming a Trainer was an important part of my journey.
A Trainer learns to take what has already been learned and help another person understand it.
There is real value in that.
But eventually I discovered a limitation.
The real world rarely presents itself as a training exercise.
The day the tool stops giving you the answer
In a classroom, the problem has usually been selected before the exercise begins.
On the gemba, it hasn’t.
The machine stops, and nobody knows why.
A process that worked yesterday suddenly falls behind.
A customer order is late even though every department appears to have met its target.
Quality adds another inspection because defects keep escaping.
Inventory increases even though everyone insists they are trying to reduce it.
A supervisor spends most of the day expediting, calling, checking and solving emergencies — and somehow that becomes evidence that the supervisor is doing an excellent job.
None of those situations arrives with a label attached.
There is no sign above the problem saying:
“Please apply Tool #7.”
That was one of the important changes in my own understanding.
I gradually became less interested in asking:
“Which TPS tool should we use?”
and more interested in asking:
“What is actually happening here?”
That sounds like a small change.
It isn’t.
Because once you ask the second question seriously, the tool can no longer come first.
Observation has to come first.
From Trainer to Solver
I began to realize that knowing how something should work and understanding why it was not working were two very different capabilities.
A Trainer can explain the standard.
A Solver has to understand the gap.
And the gap is usually messier than the textbook.
People tell different versions of the same story.
The data appears to support one explanation until you look at it differently.
The problem disappears when you arrive to observe it.
The “root cause” somebody identified last month turns out to be only another symptom.
The countermeasure that seemed obvious creates a new problem somewhere else.
And sometimes the explanation you were most confident about turns out to be wrong.
That last part matters.
Problem solving gradually taught me something that tools alone never could:
My first explanation is a hypothesis, not a fact.
That changed the way I looked at problems.
Instead of trying to demonstrate that I knew what was happening, I became more interested in discovering whether what I thought was happening was actually true.
That is a very different posture.
PDCA begins to make much more sense from there.
Not simply as four letters.
Not as a template.
Not as boxes on a sheet of paper.
But as a discipline for confronting our thinking with reality.
We expect something.
We observe something.
There is a gap.
We develop an explanation.
We test it.
Reality answers.
And then we learn.
Sometimes reality says, “Yes, you understood.”
Quite often it says, “Not quite.”
That is where the learning begins.
First I saw tools. Then I saw problems.
Looking back, that may have been the second stage of my journey.
At first, I saw tools.
Later, I began to see problems.
Not problems in the everyday sense of “something bad happened,” but gaps between what we expected and what was actually occurring.
And gradually, another uncomfortable realization emerged.
Many of the things we were calling “problems” were not really the problem either.
They were symptoms.
A defect may be a symptom.
An extra inspection may be a symptom.
A late delivery may be a symptom.
An overflowing supermarket may be a symptom.
An operator ignoring a procedure may be a symptom.
A supervisor checking everything personally may be a symptom.
A daily emergency meeting may be a symptom.
Expediting may be a symptom.
Overtime may be a symptom.
Even heroic performance can be a symptom.
That changed the question again.
I was no longer satisfied with:
“How do we eliminate this problem?”
I wanted to know:
“What is the system making necessary?”
Why does this organization need so many approvals?
Why does this supervisor feel unable to delegate?
Why does the planner release too much work?
Why does Quality need another inspection?
Why does Maintenance live in emergency mode?
Why do people hide bad numbers?
Why does someone have to become a hero every Friday to make the shipment?
Those behaviors may look irrational when viewed individually.
But very often they are perfectly rational responses to the system surrounding them.
And that is where “learning to see” began to mean something different to me.
The symptom is visible. The disease often isn’t.
There is an analogy I increasingly find useful.
Imagine walking into a doctor’s office with a fever.
The fever is real.
It can be measured.
It may need attention.
But the fever is not necessarily the disease.
Treating the fever may make you feel better without changing what produced it.
Organizations often do the same thing.
A defect appears.
Add inspection.
An employee makes a mistake.
Add approval.
A report is wrong.
Add another report.
A deadline is missed.
Add another meeting.
Someone fails to follow the process.
Add another signature.
Inventory is inaccurate.
Count it more often.
The symptom temporarily improves.
Everyone feels relieved.
And the new control quietly becomes part of the system.
Months later, nobody remembers why it was created.
It is simply “how we work.”
The organization has learned to live with the treatment.
It may never have investigated the disease.
That realization made me increasingly cautious about quick solutions.
Not because countermeasures are bad.
Sometimes temporary controls are absolutely necessary.
You stop the bleeding before asking the patient to improve their diet.
But a temporary countermeasure should also create a question:
What condition made this control necessary?
Otherwise today’s protection easily becomes tomorrow’s bureaucracy.
Eventually, another transition begins
There is a point in this journey when something else changes.
You become reasonably capable of seeing problems.
Sometimes you can see the likely direction of an investigation before the people working on it can.
You notice contradictions.
You recognize patterns.
You hear an explanation and immediately sense that something does not fit.
And then a new temptation appears.
You want to tell people.
You want to save them time.
You want to say:
“Look here.”
“That’s not the real problem.”
“Check this first.”
“I’ve seen this before.”
And sometimes that is appropriate.
Experience should not become theater. There is no virtue in watching someone drive toward disaster simply to protect the purity of a coaching method.
But I began to understand that if I always gave people what I saw, something unfortunate happened.
They became better at seeing through my eyes.
Not necessarily through their own.
That created a new challenge.
One much harder than learning the tools and, in some ways, harder than solving the problem.
How do you help another person learn to see without simply lending them your vision?
The strange transition toward Sensei
I am cautious with the word Sensei.
I don’t think it is a title one should simply assign to oneself.
There is something odd about announcing:
“I am now a Sensei.”
In my experience, the transition is subtler than that.
At some point, other people begin to treat you differently.
Sometimes they use the word.
More often, they don’t.
You notice it in the way they approach you.
Earlier in your career, people may come because they want information.
“Can you teach us this?”
Later, they may come because they want a problem solved.
“Can you help us figure this out?”
And eventually some people begin coming with something much less defined.
“Something doesn’t feel right here.”
“Can you take a look?”
“What are we not seeing?”
Or they start explaining a situation to you and, halfway through the explanation, stop and answer their own question.
You haven’t given them the answer.
Perhaps you have barely said anything.
And yet something happened.
That, to me, is much closer to what the word Sensei represents.
Not the person with the most answers.
The person whose presence somehow helps others think more clearly.
Sometimes with the word. Sometimes with the attitude.
That distinction has become important to me.
We often think recognition comes through titles.
But sometimes people recognize a role without naming it.
They invite you to observe rather than to fix.
They value your question more than your recommendation.
They bring you into a conversation earlier — before the decision has been made — because they want help seeing the situation.
They challenge their own assumptions because they know you are likely to challenge them.
Sometimes they become slightly uncomfortable when you arrive.
Not because they expect criticism, but because they know the conversation may force them to think more deeply than they planned.
And sometimes they come back weeks later and tell you about something they discovered without you.
That last one may be the most satisfying.
Because perhaps they did not need your answer anymore.
They learned how to ask a better question.
The role changes before you notice it
Perhaps that transition happens before we recognize it ourselves.
We continue thinking that our contribution is our knowledge.
But others may already be valuing something else.
Perspective.
Questions.
Patience.
The ability to notice contradictions.
The willingness to go and see.
The discipline not to accept the first explanation.
The ability to distinguish what is known from what is assumed.
And, increasingly, the restraint not to demonstrate everything we know.
That restraint is difficult.
Particularly when you think you know the answer.
There is a peculiar kind of discomfort in watching someone explore a path that you suspect will not work.
Your experience whispers:
“Tell them.”
Development sometimes asks:
“Can they discover it?”
The answer is not always to remain silent.
That would simply turn coaching into another rigid method.
Sometimes we teach.
Sometimes we demonstrate.
Sometimes we intervene.
Sometimes we solve.
Sometimes we ask.
And sometimes the best thing we can do is wait another thirty seconds.
That judgment may itself be one of the most difficult capabilities to develop.
A Trainer gives knowledge
Looking back, I now see these stages somewhat differently.
A Trainer helps transfer knowledge.
There are things the organization already knows.
Standards exist.
Principles have been learned.
Practices need to be understood consistently.
There is no reason for every person to rediscover everything from zero.
So we teach.
A good Trainer makes knowledge accessible without turning it into dogma.
That is valuable work.
A Solver creates knowledge
A Solver encounters something we do not yet understand.
Now the answer cannot simply be transferred.
It has to be discovered.
Observation becomes more important.
Facts become more important.
Experiments become more important.
The difference between what we believe and what reality shows us becomes the source of learning.
The Solver does not merely apply knowledge.
The Solver generates new knowledge about a specific system.
That is a profound transition.
A Sensei develops the ability to create knowledge
And then, perhaps, comes another evolution.
The Sensei is not simply a Solver who has collected more years, more tools and more stories.
The role is different.
The objective gradually shifts from:
“Can I understand this?”
to:
“Can I help this person learn how to understand it?”
That requires another kind of discipline.
Because solving the problem yourself can often be faster.
Giving the answer can be more efficient.
Taking over can produce better short-term results.
And everyone may praise you for it.
But if every difficult situation requires your eyes, your experience and your judgment, then perhaps you have solved the problem while creating dependency.
The technical problem improved.
The human capability did not.
This may be why experience sometimes becomes less visible
There is an interesting paradox here.
At the beginning, expertise can be highly visible.
The Trainer speaks.
Explains.
Demonstrates.
Corrects.
The Solver investigates.
Analyzes.
Experiments.
Implements.
But a very experienced Sensei may appear to do surprisingly little.
A question.
A pause.
A walk to the process.
“Show me.”
“What did you expect?”
“What actually happened?”
“How do you know?”
“What changed?”
“Where did you first see the deviation?”
“What makes you believe that?”
“What would have to be true for that explanation to be correct?”
None of those questions contains the solution.
But each can change what the other person is looking at.
Perhaps the deeper expertise becomes, the less it needs to announce itself.
And no, I don’t think we ever arrive
I hesitate to write about this as if Trainer, Solver and Sensei were ranks.
They are not belts.
They are not certifications.
And I am not sure we ever permanently leave one role behind.
A Sensei may still need to train.
A Solver may need to teach.
A Trainer may discover a problem that forces them to become a learner again.
The same person can move between all three roles in a single day.
And someone who is a Sensei to me in one domain may become the student when we enter another.
Perhaps that is why I increasingly see the journey not as a ladder, but as a change in our relationship with knowledge.
At first:
I want to know.
Then:
I want to understand.
Eventually:
I want to help others understand.
And somewhere along the way, another realization appears:
I still have a great deal to learn.
Maybe that realization never goes away.
I hope it doesn’t.
Learning to see was never really about eyesight
For years, the phrase learning to see seemed to me to describe observation.
Go to the gemba.
Look carefully.
Understand the process.
See the waste.
Today I think it means considerably more.
Learning to see means learning to look beyond labels.
Beyond tools.
Beyond symptoms.
Beyond the first explanation.
Beyond the behavior of the individual standing in front of us.
It means asking what conditions produced what we are observing.
It means recognizing that a perfectly reasonable action by one person can create a terrible result for the whole system.
It means noticing when a control that once protected the process has become part of the problem.
It means distinguishing what we actually saw from the story we immediately constructed around it.
And perhaps, eventually, it means recognizing that our own way of seeing can become a constraint for somebody else’s development if we insist on giving it to them.
Looking back
When I look back at my own TPS journey, I don’t think the biggest change was the number of tools I learned.
It was what I was looking for.
At first, I learned the vocabulary.
Then I learned to teach what I knew.
Later, I became less interested in naming things and more interested in understanding problems.
Then I began to see that many problems were themselves symptoms of deeper conditions in the system.
And eventually I started wrestling with an entirely different question:
How do I help another person see what lies behind the problem without simply telling them what I see?
I am still learning that part.
Perhaps everyone who takes this journey seriously is.
And perhaps that is why Sensei is not really a title we decide to claim.
At some point, other people begin to place us in that role.
Sometimes with the word.
Sometimes simply through the way they approach us.
They stop coming only because they believe we might know the answer.
They come because they believe we might help them see.
And with that trust comes a different responsibility.
Not to make them dependent on our experience.
Not to impress them with what we know.
Not even to make them see exactly what we see.
But to help them develop the ability to look more deeply for themselves.
Looking back, perhaps my journey through TPS was never really about accumulating knowledge.
It was about changing what I did with it.
First, I learned to share what I knew.
Then, to learn from what I did not know.
Later, to look for the system behind the problem.
And now, increasingly, to help others learn without borrowing my eyes.
At first, I learned the names of the symptoms.
Then I learned to investigate the disease.
Now I am trying to help others see it for themselves.
And perhaps that is what learning to see was pointing toward all along.