Experienced employees know things that rarely make it into a procedure. Getting that knowledge onto paper is difficult enough. Figuring out what to do with it is where the real work begins.
Every manufacturing operation has a few people who seem to know how everything works. They’re the ones everyone goes to when something unusual happens, when a process isn’t behaving as expected, or when a problem keeps coming back despite everyone’s best efforts.
We often refer to what these “wise old owls” know as “tribal” or tacit knowledge. It’s tremendously valuable, but it also creates problems in the long run. What happens when one of those employees retires? How do you train someone else to approach the work with the same judgment? And how do you know that the way your most experienced employee does something is actually the way it ought to be done?
The conventional answer is to document what they know. Write a procedure, develop a checklist, and maybe record a few training videos.
That’s a reasonable place to start. But experience isn’t always easy to translate into written instructions, and there can be a surprising amount of disagreement about how a familiar process is supposed to work.
We ran into this recently at Trola Industries while trying to formalize our industrial control panel testing process.
The difficulty of explaining what you already know
We have experienced people who test industrial control panels before they’re shipped to customers. Part of their job involves verifying that the panels have been assembled and wired correctly, that the equipment meets applicable requirements, and that problems are identified before the panels leave our facility.
We wanted to turn that existing process into something we could teach and evaluate. That meant developing a documented practice, a checklist, and eventually a training program with defined competency levels.
It sounded straightforward enough. We already had people performing the work successfully, so why not ask them to write down what they do?
The problem was how much of their expertise was tied up in experience.
An experienced panel tester doesn’t simply follow a sequence of instructions. They look at a panel and notice things. They recognize patterns in workmanship, know where certain kinds of mistakes tend to show up, and develop a sense for when something deserves a closer look.
Some of this can be explained with engineering requirements and established testing methods. Other parts come from years of seeing different panels, different technicians, and different problems.
There’s almost an artistic quality to some of it. The tester might recognize something that looks a little unusual before they can fully explain why it caught their attention.
Asking someone to write all of that down is a tall order. They may not even realize how many small decisions they’re making.
We also discovered that our two primary testers had somewhat different approaches, particularly in how they documented what they found. Both have valuable experiences they draw on, but there wasn’t necessarily a single, consistent way of communicating the results of their work.
We needed a better way to understand the process before deciding how to standardize it.
Ask people to tell you what happened
Instead of having our testers sit down and write procedures independently, we brought the relevant people together for a conversation.
We spent about an hour walking through actual panel-testing examples. We asked what they looked for, what they did first, what problems kept appearing, and what they thought less-experienced people might overlook.
We were particularly interested in things they did almost without thinking. The small observations, habits, and decisions that might never come up if someone simply asked for a list of testing steps.
We recorded the discussion and kept the full transcript. We didn’t try to turn everything into a polished procedure while the conversation was happening.
That was useful because there were several different kinds of information mixed together. Some statements described established requirements. Others described personal preferences, practical troubleshooting methods, recurring problems, or expectations about how work should be performed.
Those differences matter. Consider a maintenance process. The technician performing the work may have one understanding of what’s required. The operator who reports the problem may have another. A supervisor may assume certain checks are being performed, while management may be expecting a level of documentation or quality control that hasn’t actually become part of the daily routine.
All of these people know something about the process. None necessarily sees the entire picture.
Even highly experienced employees can carry forward practices that are outdated, inconsistent, or inappropriate under certain conditions. Being good at a job doesn’t automatically make every habit worth teaching to someone else.
So the objective of these conversations is partly to collect information, but it’s also to understand where people’s perspectives agree, where they differ, and what still needs to be investigated.
Where AI was useful
After our panel-testing discussion, we had a fairly large transcript containing a mixture of technical details, experiences, opinions, and questions.
This is where AI helped considerably. We used it to organize the discussion, extract common themes, identify practices that appeared important, and point out areas where the information was incomplete or inconsistent.
That gave us a draft picture of the testing process and, importantly, a set of questions that still needed answers.
We then reviewed the material, corrected things, added information, removed things that didn’t belong, and brought in other perspectives.
I think this is one of the more promising applications of AI in manufacturing knowledge management. There are established techniques for interviewing experts, examining processes, comparing information, and developing work instructions. AI can make some of that work considerably easier, particularly when you’re dealing with hours of conversations or input from multiple people.
But you still need to decide whether the information is accurate, whether it applies to your operation, and whether it’s appropriate to make it part of an approved procedure.
A transcript is a record of what people said. An AI summary is an interpretation of that record. Neither establishes that the practices described are correct.
In a manufacturing environment, especially where safety and quality are involved, that distinction deserves attention.
What should become the standard?
One of the more useful findings from our panel-testing work involved how we document problems.
One of our testers uses a color-coding convention when marking up punch-list items. The colors convey information about the type of issue and help communicate who needs to address it.
We preferred that approach because it makes the information more useful to the people receiving it. The technician or engineer reviewing the punch list has a clearer understanding of what they’re looking at and where responsibility for resolving the issue belongs.
It also builds on something familiar. We already use similar color conventions for drawing markups, so the concept shouldn’t be foreign to an experienced panel builder.
There was a practical reason to favor this approach over another documentation method. It gave us better traceability and clearer communication without requiring an entirely new way of thinking about the work.
I think that’s a useful test for process standardization: What problem are we trying to solve, and does the proposed practice actually make the work better?
We don’t necessarily need every experienced employee to think through a problem in exactly the same way. Judgment and experience are part of why those employees are valuable in the first place.
What we do need is consistency around the requirements that matter, including safety, quality, documentation, and how problems are communicated and resolved.
There’s also a limit to how much change an organization can absorb at once.
We generally prefer introducing one or two improvements at a time, particularly when we’re dealing with established working habits. It gives us a chance to see whether employees understand the change and whether it’s having the intended effect.
And we try not to roll out a process change that we have no practical way to observe or evaluate.
For the punch-list example, that might mean reviewing how completed punch lists were coded at the end of a project. We’d also want real feedback from the project team. Were problems assigned clearly? Did the information help? Were there situations where the coding created added confusion to the team or didn’t provide enough detail as to what needed to be done and by what team members?
Our panel testing documentation continues to be developed and revalidated. We have a much better framework for describing what we do and why, along with a stronger, more traceable checklist we can leverage for better continuous improvement. The next step is to see how well that documented process holds up when people use it.
Until then, it would be premature to claim the exercise has reduced defects or improved testing efficiency. We have a method for evaluating those things, which is an important part of the work still ahead.
You can start without a knowledge-management platform
For a plant manager or maintenance leader interested in doing something similar, I wouldn’t begin with a large software investment.
I’d start with one troublesome process. Find something that relies heavily on a particular person, has recurring handoff problems, or seems to work differently depending on who’s involved.
Identify the person everyone goes to when that process causes trouble. There may be several people, and that’s fine.
Have a conversation with them. Record it using Microsoft Teams or even a phone, assuming the appropriate permissions and company policies allow it.
I’d be careful about how the exercise is introduced. People can understandably feel threatened when management starts asking them to explain everything they know. They may worry that they’re being evaluated, that their methods are being criticized, or that the company is trying to make them less necessary.
That’s not the objective.
Explain that you’re trying to make the process easier for everyone involved, including them. Better information going into a process and clearer communication coming out of it can eliminate some of the recurring problems that end up back on the experienced employee’s desk.
Then ask them to walk you through the work.
Don’t start with, “Tell me every step you perform.” Ask what a typical day or week looks like. Ask them about a job that went particularly well. Ask about something that went badly and how they figured out what was happening.
Stories are useful because they give you context. When someone describes the best and worst experiences they’ve had with a process, you start to see its boundaries. You learn what conditions matter, what makes the normal approach stop working, and what decisions the experienced person makes when things become unusual.
Afterward, compare what you heard with the understanding of the people upstream and downstream. Look for assumptions and disagreements. Use AI to help organize the information if it’s useful, but have the right people review and validate the conclusions.
Then pick something small to improve, decide how you’ll evaluate it, and see what happens.
You can expand from there.
Five questions to ask your most experienced employee
If you’re unsure where to begin, choose one process and ask the person who knows it best these five questions:
- What do you look for that most people don’t notice? Ask them to describe the subtle signs, recurring problems, or observations that experience has taught them to recognize.
- Tell me about a time this process went exceptionally badly. What happened, how did they recognize the problem, and what did they do differently as a result?
- What do other departments misunderstand about your work? This can reveal missing information, unrealistic expectations, and opportunities to improve handoffs.
- What do you do when the normal procedure doesn’t work? Understanding exceptions can be just as valuable as documenting the routine, provided those responses are reviewed for safety and appropriateness.
- How would we know whether someone else was doing this correctly? This begins to connect personal experience with observable standards, training, and evaluation.
You probably won’t get complete answers to all five in a single conversation. You may find that the answers raise more questions than they settle. That’s useful information, too.
Making knowledge useful
There’s a lot of interest right now in using AI to capture tribal knowledge before experienced workers retire or move on. I think there’s genuine opportunity there, particularly in making the process of interviewing people, organizing information, and examining different perspectives less labor-intensive.
But even without AI, manufacturers can do a great deal with techniques that have been around for a long time: observation, structured interviews, process reviews, practical testing, and good documentation.
Our panel-testing project reminded us how much understanding can be gained by simply getting several knowledgeable people in a room and asking them to walk through what they actually do.
Some of what we heard was already established practice. Some were individual experiences that deserved a closer look. And some of the most useful material came from finding differences in how people understood the same process.
The next step is to put that understanding back into the work, evaluate it, and keep improving it.
That’s ultimately what makes the exercise worthwhile. A document sitting on a server doesn’t do much for the next person trying to learn the job. A well-understood process, tested against the work people actually perform, has a much better chance of helping them.
And you don’t need to capture everything your employees know before you can start making progress.
👉 [Reach out to Trola to get started].
Contact Trola today for a private consultation and discover how we can help you plan for the future while building for the now.