'
The person who knows that column H in the receiving workbook exists because a customer changed their labeling requirement in 2019 and nobody ever removed it. The one who knows which supplier's lot codes need reformatting before they go into the system, and why. The one who remembers that the third shift enters weights differently, so the Monday report always looks wrong until you adjust for it.
None of this is written down. It doesn't need to be, because that person has been here fourteen years and knows all of it cold.
That's the risk. Not their competence, which is real. The fact that a meaningful part of how your operation works exists only in their memory.
Why this became urgent?
Two things changed at once.
The workforce is turning over faster than institutional knowledge can transfer. The Bureau of Labor Statistics puts warehouse worker turnover at 36% annually. Even in more stable plant roles, the experienced cohort is retiring, and Deloitte's 2026 manufacturing outlook names capturing institutional knowledge from retiring employees as a specific priority for the year, alongside more headline topics like agentic AI.
At the same time, order processing volumes have risen roughly 95% since 2019 across supply chain operations. More transactions flowing through the same processes means more moments where someone's undocumented judgment gets applied, and more places where its absence shows up.
The combination is what makes this different from the standard succession planning conversation. It isn't just that a knowledgeable person might leave. It's that the volume of decisions depending on that knowledge has roughly doubled while the tenure of the people making them has shortened.
What actually lives in people's heads?
It helps to be specific, because "tribal knowledge" is vague enough to be easy to dismiss.
In food operations, the undocumented layer usually includes: which customer requires which label format and why, the crosswalk between your item numbers and each supplier's, how to interpret each supplier's date coding, which lots get held for a customer-specific spec, how yields typically run for a given cut or batch so anomalies get caught, the workaround for the thing the ERP has never handled correctly, and the informal tolerance for when a count discrepancy is worth investigating versus absorbing.
Look at that list. Almost every item is a rule. Rules are the most systematizable thing there is, which is precisely why it's frustrating that they live in memory instead.
The reason they live in memory is rarely negligence. It's that each one arrived as a one-off exception, solved by a capable person under time pressure, and never got promoted from a workaround to a documented process because it was working fine.
Why documentation projects fail?
The standard response is to write it all down. Build a process manual. Interview the veterans before they retire.
These projects have a poor track record, and it's worth understanding why rather than just trying harder.
Documentation goes stale immediately. The manual describes the process as of the day it was written. The first time a customer changes a requirement, the document is wrong, and there's no forcing function to update it. Within a year, people stop trusting it and go back to asking the person.
Documentation also isn't available at the moment of decision. Someone at receiving, handling a pallet with an unfamiliar date code, does not stop and consult a binder. They ask whoever is nearby. The knowledge needs to be present in the workflow, not adjacent to it.
And the interview approach has a specific failure mode: experts don't know what they know. Ask someone with fourteen years of experience to explain how they handle exceptions and you get the general version. The specific judgment, the part that matters, only surfaces when an actual exception appears, which is exactly when nobody is taking notes.
What works instead
The alternative is to encode the rules in the systems where the work happens, so following them is the default rather than a thing to remember.
Validation at the point of entry. If a supplier's lot codes need a particular format, the system should enforce the format rather than depending on someone knowing to reformat them. If a date is outside a plausible range, it should be rejected at entry, not discovered three weeks later in a trace query. Every validation rule is a piece of institutional knowledge that no longer needs a person.
Customer requirements as data, not memory. Label formats, spec tolerances, item number mappings, and routing rules stored against the customer record and surfaced automatically on the relevant order. This is the same argument that applies when a customer changes ownership and their requirements shift: the operations that absorb it easily are the ones where requirements were data all along.
Mappings maintained as a system, not a file. The crosswalk between your item numbers and each supplier's belongs in a governed dataset attached to your item master, not in a spreadsheet named after the person who built it. This one change addresses a large share of what's currently undocumented in most midsize operations.
Expected ranges made visible. If yields typically run within a certain band, the system can flag when they don't, which converts a veteran's instinct into an alert anyone can act on. The experienced person's judgment is what defines the band. Once it's defined, the judgment is portable.
Notice the pattern. None of this replaces the expert. It relocates the specific, repeatable parts of what they know into the place where the work happens, so their expertise gets spent on genuine exceptions instead of on remembering routine rules that a system could enforce.
The uncomfortable version of this question
Here's the test, and it's worth asking honestly rather than defensively.
Pick your most experienced operations person. If they gave notice tomorrow, and worked out a normal two weeks, what would break in the following ninety days?
Not what would be harder. What would actually break, or get quietly wrong in a way nobody catches for a month.
If the answer is nothing, your rules are in your systems and you're in unusually good shape. If you can list three things without thinking hard, those three things are your project, and they're each smaller than they feel.
The good news in all of this: the knowledge still exists right now, in someone who is still here and can still explain it. That's the window. It closes on a schedule nobody controls.
Platsera builds custom software for food and logistics operations. Real engineering, not a design shop reselling code.
