The Most Valuable Process in the Company May Not Be Written Down | Observations from the Shop Floor
Michael Gardner, COO
Every company has an employee who makes things work.
You know who they are, even if their title does not suggest how important they have become. They are the person everyone calls when something doesn’t look right, the person who knows which vendor always ships short, the person who remembers why a particular customer receives special handling, or the person who can look at a report and immediately sense that something is off. They can often solve a problem in five minutes that would take everyone else five hours.
Most organizations think of these individuals as employees.
I often think of them as processes.
Not because they were hired to be one, but because over time they have accumulated so much operational knowledge that the business quietly begins to run through them. Their experience becomes part of the workflow, their judgment fills the gaps between procedures, and their memory connects decisions made years apart. Eventually, they become the mechanism through which work actually gets done.
Over the years, I’ve spent time in manufacturing plants, distribution centers, accounting offices, customer service departments, and warehouses. The industries change. The products change. The software changes.
Yet one observation appears so consistently that I now expect to find it in nearly every company I visit: the most valuable process in the company may not be written down anywhere.
It may not exist in a procedure manual, be documented in the ERP system, or appear in the employee training program. And yet everyone knows it exists.
At some point during a conversation, a manager will point toward a desk and say, “If you really want to understand how that works, go talk to Susan.”
Or perhaps: “Mike knows all that.”
Sometimes the comment is accompanied by a slightly embarrassed smile and the familiar admission: “We’ve been meaning to document that for years.”
What makes these moments interesting is where they usually occur. More often than not, they happen while standing in front of an ERP system, a WMS system, a CRM system, or some other technology platform that was purchased specifically to standardize business processes. The organization may have invested heavily in documenting workflows and enforcing consistency, yet the most important process in the company is still sitting in a chair.
The Process Behind the Process
Most companies have documented procedures. There is a purchasing process, a receiving process, a production process, and an invoicing process. These procedures are often well designed and necessary because they provide structure, consistency, and accountability.
But if you spend enough time observing how work actually gets done, you will often discover a second process operating underneath the official one.
The official process is what the system expects.
The unofficial process is what allows the business to succeed.
Someone reviews a report every morning because experience taught them the report misses something important. Someone calls a supplier every Thursday because years of interaction have shown that promised dates are rarely accurate. Someone double-checks a particular type of invoice because they learned long ago that a certain discrepancy never appears in the system.
None of these activities are documented – yet the company depends on them.
The reason is simple. Businesses do not actually run on documented procedures alone. They run on accumulated judgment.
Documentation can tell someone what to do. Experience teaches them when not to do it. That distinction matters more than most organizations realize.
A purchasing manager may know that a vendor promises four-week lead times. After twenty years of experience, however, they also know that during hurricane season that promise quietly becomes six weeks. A customer service representative may know that a customer requests Friday deliveries, but experience has taught them that “Friday” really means “Thursday afternoon if possible.” An accounts payable clerk may recognize that an invoice technically matches the purchase order, yet something about the pricing feels wrong because they have seen this situation before.
None of this knowledge exists in a procedure manual. It exists in people.
And in many organizations, that knowledge represents the difference between a process that functions on paper and a process that functions in reality.
Why These Employees Matter
What makes these employees so valuable is not their ability to follow a process.
It is their ability to recognize exceptions.
The longer I work with businesses, the more convinced I become that successful companies are not built around managing normal transactions. They are built around managing exceptions.
Normal transactions are relatively easy. Software handles those. Rules handle those. Automation handles those.
The real value emerges when something does not fit the pattern.
An order arrives with unusual requirements. A supplier misses a shipment. A customer requests something outside the standard workflow. Inventory does not reconcile. A report looks correct but somehow feels wrong.
These are the moments when operational reality and system reality begin to drift apart.
Experienced employees recognize those moments almost instinctively because they understand the context surrounding the transaction, not just the transaction itself. They know which discrepancies matter and which can be ignored. They know when a rule should be followed and when a situation requires judgment.
This is where the true operating knowledge of the business lives.
The Risk Nobody Sees
The danger is not that these informal processes exist; many of them are incredibly valuable. The danger is that leadership often does not realize how much of the company depends upon them.
From the outside, everything appears to be working. Customers receive their products. Invoices get paid. Production schedules stay on track. The month closes successfully. Because the outcomes are positive, it is easy to assume the underlying process is stable and well understood.
In many organizations, leadership eventually discovers an uncomfortable truth:
We know the work gets done. We’re not entirely sure how.
Then the person carrying that knowledge retires, changes jobs, or simply is not available.
Suddenly, everyone discovers that what appeared to be a system was actually a person.
The organization was not running the process.
The process was running through the organization.
I have watched companies spend hundreds of thousands of dollars implementing software intended to standardize operations, only to discover after go-live that employees quietly recreate the missing pieces through spreadsheets, notebooks, emails, sticky notes, and memory.
This does not necessarily mean the software failed.
More often, it means the software captured the transaction while the employee continued to own the judgment.
The system recorded what happened.
The employee understood why.
When the Knowledge Leaves but the System Remains
Sometimes organizations lose knowledge without losing the process.
The software may still be running. The reports may still be generated. The workflow may still produce results. Yet the original reasoning behind the process has quietly disappeared.
I was recently involved in a discussion surrounding a customer-facing portal that had existed for years. At first glance, it appeared to be a straightforward technology question involving servers, websites, and infrastructure.
As we began planning a migration, however, a more important question emerged: why was it built this way in the first place?
The deeper we investigated, the more history surfaced. Previous websites. Domain changes. Infrastructure decisions. Customer habits. Individuals who had made key decisions and were no longer with the organization.
The system still existed.
The reasoning behind it was much harder to find.
What appeared to be a technology project became an exercise in reconstructing institutional memory. The most important discovery was not understanding how the system worked – it was understanding why it worked that way.
That experience reinforced something I have observed repeatedly over the years. Organizations often inherit systems long after they have lost the knowledge that originally shaped them. The software survives. The servers survive. The reports survive. But eventually someone asks a simple question:
“Why do we do it this way?”
If nobody can answer, part of the organization’s most valuable knowledge has already been lost.
What Technology Should Really Do
This observation has shaped much of how I think about technology.
The goal should never be to replace institutional knowledge, but to expose it, understand it, document it, and make it available to the next generation before it walks out the door.
Too often organizations attempt to automate processes they do not fully understand. They focus on the visible workflow while overlooking the experience that makes the workflow successful.
- Before a process can be automated, it must first be observed.
- Before it can be documented, it must first be recognized.
- Before it can become institutional knowledge, someone must acknowledge that it exists.
Technology is often the final step.
Observation is the first.
The companies that thrive over the long term are not necessarily the ones with the best software. They are the ones that successfully convert individual knowledge into organizational knowledge. They find ways to capture not only what happened, but why it happened. They preserve the judgment behind the transaction, transfer experience to the next generation, and reduce the organization’s dependence on any single individual.
In many cases, the most important discovery is not a new technology capability, but instead identifying the employee who has quietly been carrying a critical process for years.
Owning the Knowledge
Every successful company contains knowledge that was earned through experience. There is nothing wrong with that. In fact, it is often a competitive advantage. The challenge for leadership is recognizing the difference between institutional knowledge and individual knowledge.
Institutional knowledge strengthens the company because it can be shared, taught, improved, and transferred.
Individual knowledge creates dependency because it remains attached to a single person.
The most valuable process in your company may not be written down. It may not exist in a workflow diagram, a software application, or a procedure manual. It may exist in the judgment, memory, and experience of someone who has spent years learning how the business really works.
The question is not whether that knowledge is valuable.
The question is whether the company owns that knowledge – or whether the knowledge still owns the company.
Final Observation
The most valuable process in the company may not be documented in a system, a manual, or a workflow. It may be carried by a single employee. Exceptional organizations find ways to transform individual knowledge into organizational knowledge before it walks out the door—and before the reasons behind their most important decisions are forgotten.