The best press operator in the plant handed me a procedure he had written himself, and inside twenty minutes I watched him do eleven things that were nowhere in it.
He was not hiding anything. Asked why he adjusted a setting before the material reached temperature, he shrugged. He could not say. That is the problem with knowing how to document tribal knowledge in a plant: the person who has the knowledge is the person least able to hand it over, because expertise stops being a set of decisions and becomes a set of reflexes.
So the usual approach fails before it starts. You give your senior people a template and a deadline, they write down the procedure they believe they follow, and what comes back is the ten steps everyone already knew. The eleven moves stay where they were.
How do we document tribal knowledge in a plant?
Document it from observation, not from memory, and validate it with someone who has never run the job. Watch the work, capture every deviation between what the person does and what the document says, ask why at the moment of the deviation rather than afterward, then hand the draft to a new hire and mark every place they stop. Those stops are the knowledge you had not captured yet.
Everything below is the long version of that paragraph. It runs on one job, across two shifts, with a clipboard.
Why the ramp is slow, and why that is the real cost
The retirement story gets all the attention, and it is real. But most plants feel this in onboarding long before anyone retires.
Hand a new person the written procedure and they receive the ten steps. They do not receive the four seconds of listening to the feed before deciding on speed. They do not receive the sensor face that has to be wiped even though no document says so. So they get the job technically right and operationally wrong for months, and the plant absorbs the difference as scrap, slow cycles, and a senior operator who spends a third of the shift answering questions.
That gap between the document and the practice is not a training problem. It is a documentation problem wearing a training problem’s clothes. We wrote about the structural version of this in manufacturing knowledge capture — why experts cannot self-document. This article is the other half: what to do about it.
There is also a reason not to wait for the technology to solve it for you. Deloitte’s September 2025 road map on agentic AI in manufacturing analysed O*NET occupational and task-level data against US Bureau of Labor Statistics data for the sector and concluded that “81% or more of task hours across the industrial manufacturing sector are likely to remain human driven.” The work stays in human hands. Which means the knowledge stays in human heads until somebody goes and gets it.
Step 1 — Pick one job, not one department
Scope kills these projects. A plant-wide tribal knowledge initiative dies in month three because nobody can tell whether it is working.
Pick a single job that meets two tests: it produces variation you cannot explain, and fewer than three people can run it well. That is your candidate. One job, one week.
If you are not sure which jobs qualify, your existing manufacturing skills matrix will point at them, as long as you read it for depth rather than for coverage.
Step 2 — Watch the job with the current document in your hand
Stand at the cell with the existing procedure printed out and follow along while someone runs it. Every time the person does something the document does not say, or skips something the document does say, write it in a column. Do not interrupt.
You are building a deviation list, and the length of that list is your first real number. It is never short, and everyone in the plant will guess low.
Step 3 — Ask “why” at the deviation, not at the end
This is the step that most capture efforts get wrong, and it is where the method lives or dies.
Do not debrief afterward. By the end of the shift, the person has re-narrated the job back into the official ten steps, and the eleven moves have vanished again. Ask at the moment. Point at the thing they just did and ask one of these:
- What did you just do, and what happens if you don’t do it?
- How did you know it was time to do that?
- What told you? A sound, a colour, a number, a feel?
- Who taught you that, or did you work it out?
- What goes wrong on this job that isn’t in the instruction?
The last question is the highest-yield question in the whole method. It gets you the failure knowledge — the things the job does when it misbehaves — which is almost never written down anywhere and is exactly what a new person lacks.
Capture the sensory triggers verbatim. “When the stringer starts to look grey instead of blue you’re running hot” is a usable instruction. “Monitor weld parameters” is not.
Step 4 — Run it again on the other shift
Do not skip this. The second shift will do the same job differently, and the differences are the most valuable data you will collect all week.
Where two shifts diverge, one of three things is true: one way is better and nobody has ever compared them, both ways work and the standard is over-specified, or the job is genuinely condition-dependent and the condition has never been written down. All three findings are worth having. Only the second shift produces them.
Step 5 — Validate with someone who has never run the job
Write the draft, then hand it to a new hire or a person from an adjacent cell, and watch them work through it without help. Mark every place they stop, hesitate, or ask a question.
Every stop is a piece of tribal knowledge you had not captured. Fix the document at that spot, in their words, and repeat until they get through it clean. That is the finish line, and it is a far better test than any review signature.
Keeping the log of what they asked is worth as much as the document itself. We made the case for that separately in manufacturing work instructions for new hires.
What this looks like at SenseiLab
We run this by conversation rather than by clipboard. Operators, leads and supervisors talk directly to an AI agent about how they actually run the job — the deviations, the sensory triggers, the failure knowledge — and the procedure gets assembled from what they describe doing rather than what they remember writing. Then it gets validated on the floor and it keeps updating as the job changes. The five steps above are the manual version of that, and they work. The Sprint version does five to ten procedures in thirty days instead of one job in a week.
Run this on one job this week
Print the current procedure for your least-transferable job. Stand at the cell for one full run and log every deviation in a column. Ask “what goes wrong on this job that isn’t in the instruction?” at the moment it happens. Repeat on the other shift. Then hand the draft to someone who has never run it and count the stops.
Two shifts, one clipboard, no software. If the deviation list is under five, you picked the wrong job. If it is over fifteen, you found where your onboarding time is going.
Book a 30-minute SOP Readiness Diagnostic
If you want the scaled version of this, that is what the 30-day SOP Sprint does: five to ten validated Living SOPs, built with the people who run the work, deployed at the workstation, with one internal champion trained to keep them current. Start with a free 30-minute diagnostic and we will tell you which jobs to run it on first.
FAQ
How do we document tribal knowledge in a plant? Document it from observation rather than from memory. Watch an experienced person run the job with the current procedure in your hand, log every deviation between what they do and what the document says, and ask why at the moment of each deviation. Then validate the draft with someone who has never run the job and treat every place they stop as knowledge you missed.
Why can’t we just ask our experienced operators to write it down? Because expertise becomes automatic. Once someone has run a job for years, the judgement calls stop being decisions they can narrate and become reflexes they cannot see. Asked to write the procedure, they reliably produce the official steps and omit the adjustments that make the job actually work.
How long does it take to capture tribal knowledge for one job? One week is realistic for a single job using this method: one observed run per shift, a draft, and one validation pass with a new person. The constraint is access to the operator during production, not analysis time.
What is the difference between tribal knowledge and tacit knowledge? Tacit knowledge is the individual version — skill and judgement a person holds but cannot fully articulate. Tribal knowledge is the group version — practices a team shares informally that exist in no document. In a plant they overlap almost completely, and both are captured the same way: by observing the work and asking why in the moment.
How do we know when the knowledge has actually been captured? When a competent person who has never run that job can complete it from the document without asking a question. That is the only test that matters, and it is the reason step five is not optional.
About the author. Diego Echenique is CEO and co-founder of SenseiLab, with more than 20 years in manufacturing operations across Argentina, Chile, Europe, the Middle East and Asia. He has launched plants, led operations and run Lean and Six Sigma transformations across automotive, mining and heavy industry.
