The Knowledge That Never Made It Into the Standard

The Knowledge That Never Made It Into the Standard

Some people can recognize a problem before anyone else even notices that something is changing.

An operator hears a different sound coming from a machine.

A technician recognizes a vibration that shouldn’t be there.

A supervisor notices work beginning to accumulate and knows that, unless someone intervenes, trouble is coming.

When we ask how they knew, sometimes they answer:

“I don’t know. I just noticed.”

But they probably do know.

What has happened is that years of experience have developed their ability to recognize conditions that others have not yet learned to distinguish.

In Mexico, we have a saying:

“The devil knows more because he’s old than because he’s the devil.”

It’s our way of recognizing the value of experience.

And organizations have plenty of these old devils.

People who know the machines, the processes, the materials, and even the subtle behaviors that indicate something is about to go wrong.

They are the ones who solve problems that others don’t even know how to begin investigating.

And we’re usually very grateful to have them.

Until one day, we discover something troubling.

The knowledge exists.

But the system hasn’t necessarily learned it.

What the Standard Doesn’t Fully Explain

Standards describe the best-known way to perform work under specific conditions.

They establish sequences, timing, key points, and the reasons behind certain actions.

They are essential for preserving what has been learned.

But when we observe an experienced person at work, we may discover something more.

They don’t simply follow a sequence.

They observe.

They compare.

They anticipate.

They recognize small differences that others cannot yet distinguish.

They know when to continue and when to stop.

And, most importantly, they understand why certain conditions matter.

Imagine an experienced operator hearing an unusual sound.

Without making a big deal out of it, he checks a condition, makes an adjustment within his authority, and the process continues normally.

The problem disappears before it becomes an interruption.

His supervisor walks by.

The machine is running.

Production is on target.

The operator is doing his job.

Everything looks fine.

And the supervisor continues his walk.

But he has just missed an extraordinary learning opportunity.

Because that reaction may not have been described in the Standardized Work.

And nobody asked what happened.

What Are We Looking For When We Go to Gemba?

We often talk about the importance of going to Gemba.

Observing the actual work.

Checking conditions.

Confirming that standards are being followed.

Identifying abnormalities.

All of that is necessary.

But Gemba is not simply about supervision.

Gemba is also an opportunity to discover what we don’t yet understand.

Let’s return to our operator.

The supervisor could have asked:

“What did you just notice?”

“How did you know something was changing?”

“What made you decide to intervene?”

“Is that covered by our standard?”

“How would someone with less experience recognize the same situation?”

Perhaps he would have discovered a condition that had never been documented.

Perhaps an early warning sign of failure.

Perhaps a more effective way to identify an abnormality.

Or perhaps he would have found a practice that needed to be examined before anyone could consider it correct.

Because not every reaction from an experienced person should automatically become part of the standard.

Experience can also contain habits, assumptions, and solutions that worked under certain circumstances but may not be safe or repeatable.

That’s why we need to understand before we adopt.

However, if we don’t observe or ask, we will never even reach that evaluation.

And here is a distinction I consider fundamental:

We can go to Gemba to confirm what we already know, or we can go to discover what we still need to learn.

The first may confirm that work is being performed as expected.

The second can help us improve the system.

We need both.

Knowledge Is Not Understanding

Knowing the standard doesn’t necessarily mean understanding the work.

We can memorize a sequence of operations without fully understanding why they must be performed in that order.

We can know a process’s limits without recognizing the early signs that it is beginning to lose stability.

We can know what to do when an abnormality appears without understanding how to anticipate it.

Knowledge is not understanding.

Knowledge tells us what to do.

Understanding helps us recognize why, when, and under what conditions we should do it.

And that understanding cannot always be transferred through a document.

It develops through observation, practice, questions, mistakes, feedback, and reflection.

Our old devil may not have simply known the process better.

He had learned to see things that we had not yet learned to recognize.

And for years, we had the opportunity to learn from him.

The Indispensable Expert

Many organizations depend on a handful of people to solve difficult problems.

When something goes wrong, everyone knows whom to call.

The expert arrives.

Observes.

Asks a few questions.

Finds something nobody else noticed.

Solves the problem.

Everyone breathes a sigh of relief.

And work continues.

Until the next time.

Sometimes we even celebrate this capability as an organizational strength.

“Good thing we have someone who knows how to fix these things.”

But we rarely stop to ask:

What did everyone else learn?

Did anyone understand how the expert identified the problem?

Was the standard reviewed?

Did someone else develop the ability to recognize the same condition?

Or did we simply reinforce our dependence on the expert?

Individual experience can solve a problem.

But if that experience doesn’t develop the capabilities of others, the system remains vulnerable.

And leadership has an important responsibility here.

Recognizing people who know is not enough.

We need to learn from them.

Documenting Is Not the Same as Developing

When organizations realize they depend too heavily on one person, the usual response is:

“We need to document everything they know.”

The intention is reasonable.

But documenting knowledge does not guarantee that others will develop understanding.

We can write detailed instructions.

Add photographs.

Create checklists.

Even record videos.

All of that can help.

But if someone doesn’t understand what they are observing, why it matters, and how to respond when conditions change, a gap remains.

The standard must preserve what has been learned.

But it must also provide a foundation for teaching, observing, and improving.

It is not a substitute for thinking.

Nor is it a document that should remain untouched when we discover a better way to work.

A good standard preserves yesterday’s learning while allowing tomorrow’s learning to develop.

And achieving that requires more than documents.

It requires leaders who can teach and people who have real opportunities to practice, understand, and improve.

The Old Devil’s Final Trick

But let’s return to our character.

For years, the old devil solved problems.

Recognized abnormalities.

Anticipated failures.

Helped his coworkers.

And kept processes running that may have depended on his experience far more than we realized.

We walked through Gemba.

Reviewed the indicators.

Verified compliance with standards.

And returned to our offices satisfied.

Until one day, the old devil decided to retire.

And that’s when he played his final trick on us.

He took everything he knew with him!

Suddenly, problems began appearing that previously seemed to solve themselves.

Failures took longer to identify.

Small abnormalities became major interruptions.

And someone said:

“Well, he knew how to fix those things.”

Of course he did.

He had demonstrated it for years.

But now comes the uncomfortable part of the story.

The real trick wasn’t that he took his knowledge with him.

It was that we never truly learned from him while he was there.

For years, we observed his results, but not necessarily his decisions.

We saw him solving problems, but we didn’t always understand how he recognized them.

We confirmed that the process was working, but we failed to discover how much it depended on what that person had learned to see.

And perhaps most troubling of all:

We went to Gemba to confirm what we already knew, not to discover what we still needed to learn.

What Should Really Remain

People change positions.

They retire.

They find new opportunities.

And eventually, they leave the organization.

That’s a natural part of professional life.

The problem is not that they leave.

The problem is that their experience disappears without having sufficiently contributed to developing others.

An organization doesn’t learn simply because its people accumulate years of experience.

It learns when that experience becomes a shared capability.

When standards evolve.

When people develop judgment.

When leaders ask better questions.

And when knowledge no longer depends exclusively on the person who acquired it.

So, during our next Gemba walk, perhaps we should do more than verify whether people are following the standard.

We should observe how they think, what they recognize, and how they respond when actual work presents conditions that the document doesn’t yet address.

And ask ourselves:

What have the people doing this work every day learned that we still haven’t learned to see?

Because someday, our old devils will leave.

And when that happens, what matters won’t be how many years they spent with us.

It will be how much we learned from them.

Leadership’s real responsibility is not to prevent knowledge from leaving. It is to develop the understanding that allows what has been learned to remain.