Systems Have Memory Problems Too

Have you ever noticed that the longer a process exists, the more likely someone is to ask, "Why do we still do this?"

While it may sound whiny or irritating, sometimes it is exactly the right question. It may reveal an outdated process, or something else entirely unexpected.

Maybe it's a forgotten lesson.

The strongest organizations aren't afraid of those questions. Rather, those questions are welcomed and appreciated. Asking why is a sign of engagement.

Processes and policies are not meant to be set in stone forever. Some processes should evolve. Some should be simplified. Some should disappear altogether.

The challenge is knowing the difference, which becomes much harder when the original context has been forgotten.

Over time, organizations accumulate solutions to problems.

A recurring error leads to a new safeguard. A near miss leads to a new process. An adverse outcome leads to a new expectation. Eventually, the solution becomes routine.

The people who experienced the original problem move on while the process remains.

What once made perfect sense begins to look unnecessary.

Not because the process changed.

Because the memory did.

Conversations don't happen and cynicism begins to fill the space where understanding once lived.

"This doesn't make any sense."

"This is just one more thing we have to do."

"What a pointless rule."

Sometimes those statements identify real opportunities for improvement.

Other times, they reveal something organizations often struggle to recognize:

A memory problem that can only be solved with information.

Policies, standards, and safeguards can be inherited.

The lessons behind them must be taught.

That doesn't happen automatically.

A policy can tell people what to do. A procedure can describe the steps. A standard can define expectations.

But none of that explains the problem they were originally created to solve.

That responsibility belongs to people.

Specifically, it belongs to leaders who take the time to share the context behind a process. To explain why something was created, not just the process itself.

What risk it was intended to address.

What lesson the organization chose not to forget.

This is one of leadership's most important responsibilities: connecting the policy on paper to the problem that it solved.

Not because every process should remain unchanged.

And not because every policy deserves to survive forever.

But because good decisions require understanding.

Without context, people evaluate a process based only on what they can see today.

With context, they can decide whether the process still serves its intended purpose.

A culture that stops asking why eventually forgets what it knows.

And when that happens, the lesson is often relearned the hard way.

The policy is rarely the whole story.

Somewhere behind it is a lesson worth remembering.