Ask your best machine setter how he can tell that a machine is about to start producing scrap. The answer will be: "You can hear it." Ask what exactly you can hear, and you get a shrug. He knows. He just cannot say it.
That is tacit knowledge, and in most companies it is the most valuable knowledge there is: it sits with the people who have been around for fifteen years, it appears in no document, and it walks out with them when they leave. This article shows how to recognize it, why the usual reflex - "write it down, would you" - fails, and which methods and questions make it tangible anyway. Without academic language, and with an interview guide you can copy.
What tacit knowledge is, briefly
The term goes back to the philosopher Michael Polanyi, who in 1966 coined the line: "We know more than we can tell." That says everything essential. Explicit knowledge can be spoken, written down and handed over: the price of an article, the steps in an approval, the phone number of the freight forwarder. Tacit knowledge, sometimes called experience-based knowledge, is what someone can do without being able to put it into rules: recognizing patterns, reading situations, doing the right thing at the right moment.
Explicit and tacit knowledge do not differ in importance but in transferability. Your company's explicit knowledge fits into a knowledge base. The tacit part fits into none, as long as it stays tacit. If you are interested in the theory: the SECI model by Nonaka and Takeuchi describes how knowledge moves back and forth between the two forms. For everyday practice, it is enough to know that the conversion is work and does not happen by itself.
Explicit or tacit? Three examples from the shop floor and the office
The difference is clearest where both forms sit side by side.
The setter hears what the gauge does not show yet
The tool settings are in the setup sheet. That is explicit. The fact that after the machine starts up, the setter stays next to it for two minutes and, at a slightly changed running noise, reduces the feed rate by three percent before the measurement shows any deviation at all - that is written down nowhere. The younger colleague starts up by the sheet, measures after twenty parts, and by then has twenty parts of scrap.
The sales manager knows who to call before the price list goes out
The new price list goes to all customers as a mail merge. Explicit, documented, stored in the CRM. The day before, the sales manager calls three customers personally, because he knows that one of them would otherwise be offended, one would immediately go asking the competition, and one will accept the increase if you offer him longer payment terms at the same time. Which three, why, and what you say to them: recorded nowhere. When he goes on parental leave, his stand-in sends the price list out. Two of the three customers are gone six months later.
The accountant knows the exceptions that are in no manual
The invoicing run is described in a standard operating procedure. What it does not say: that the customer whose parent company sits in Austria will not pay an invoice without a purchase order number, that the municipal utility stops accepting invoices in December, and that at the largest customer the invoice goes to a man in purchasing who is officially not responsible at all. The accountant knows these forty exceptions. Whoever covers for her produces forty payment reminders and forty open items.
What all three examples have in common: the explicit knowledge is there and it is correct. It just is not enough to do the job well. The distance between "by the instructions" and "the way the experienced person does it" is tacit knowledge, and that distance is exactly what makes a company with a bus factor of 1 vulnerable.
Why "just write it down" fails
The obvious reflex when a knowledge holder retires or resigns: have them document their work. The result is almost always disappointing, for three reasons that have nothing to do with how diligent the person is.
First, the knowledge holder does not know what he knows. After fifteen years, the look at the machine is no longer a conscious act. Asked to write down his work, he writes down what looks like knowledge to him: the sequence, the values, the order of steps. That is the explicit part, which is usually already written down somewhere. The tacit part he considers self-evident, plain common sense, or not worth mentioning.
Second, documentation describes the normal case, but the value sits in the deviations. Nobody voluntarily types forty customer exceptions into a Word document. They do not even come to mind while he is sitting at his desk being asked to describe "the invoicing run." They come to mind when the specific invoice is in front of him.
Third, there is no trigger. Documentation is a task with no deadline, no customer and no consequence if it is skipped. It loses against every task of the day. And if it does get forced through during a notice period, time pressure produces a document that nobody can find a year later.
The conclusion is not "documentation is pointless." The conclusion is: tacit knowledge cannot be requested like a phone number. It has to be drawn out with questions, observed, and told as stories. There are methods for that.
Methods for making tacit knowledge explicit
Follow-up questions: "How can you tell that ...?"
The single most effective technique is a way of asking. Not "how do you do that?", but "how can you tell that ...?" and "what would have happened if you had not done it?". These questions force the knowledge holder to name the criterion behind the action. "You can hear it" becomes, after a follow-up, "the tone gets a shade higher and more restless, like a slight rattle." That is not a measurement yet, but it is a description a successor can recognize. Persistence is what matters: usually the usable answer only comes after the third follow-up.
Observation with thinking aloud
Some things can only be shown. In an observation you accompany the knowledge holder for an hour or two at work and ask them to think aloud: why this grip now, why this glance at the display, why this phone call before the email? You take notes without judging. Observation costs more than a conversation, but it uncovers exactly the small moves that go unmentioned in an interview because they seem obvious. How to combine this with other survey formats is described in the guide to capturing as-is processes.
Stories instead of rules
People are bad at naming their rules, but they remember situations. "Tell me about the last time something went wrong" almost always yields more than "what are the risks in your area?". From the story of the customer who walked away over the price list, you can derive the rule: with customers above 50,000 euros in annual revenue and increases above three percent, call first. The sales manager would never have phrased it that way if you had asked directly. The story contains it.
Case discussions in the team
Put a real case from last week on the table, ideally one that was a close call, and have two or three people talk through what they would have done and why. The differences in the answers show where tacit knowledge is unevenly distributed. The reasoning of the experienced people is the raw material for your documentation. Half an hour every four weeks adds up to more over a year than any workshop.
An exceptions log
The most pragmatic method for areas like accounting, order processing or purchasing: a running list of exceptions, maintained at the moment they occur. Whenever the accountant handles an invoice differently from the standard, she notes the customer, the deviation and the reason. Three lines, thirty seconds. After a quarter, that list holds what no manual holds. To keep it from turning into a private spreadsheet, it needs a fixed place where the deputy can find it too; how to build a knowledge base that actually gets used is a topic of its own.
| Method | Mainly uncovers | Effort per knowledge holder |
|---|---|---|
| Follow-up interview | Decision criteria, rules of thumb | 2 x 30 minutes |
| Observation with thinking aloud | Manual steps, sequences, unconscious checks | 1 to 2 hours |
| Stories | The rules behind exceptions, risks | Part of the interview |
| Case discussion | Unevenly distributed knowledge in the team | 30 minutes monthly |
| Exceptions log | Customer, supplier and system exceptions | Ongoing, seconds per case |
That first method can now be delegated, too. At wissa.ai, an AI runs the interviews by chat or voice, 15 to 20 minutes per person, and follows up exactly where a human would: "How can you tell?", "When does it run differently?", "What happens if you do not do it?". If someone mentions a colleague who knows part of the process, that colleague is invited next, so the system works its way from one knowledge holder to the next. The exceptions end up in the process documentation with a source reference, every statement traceable back to the conversation it came from; and if the deputy says something different from the regular owner, the contradiction is flagged rather than smoothed over.
An interview guide with ten questions
The following guide is designed for a conversation of 30 to 45 minutes. You can use it as it stands. The order is deliberate: concrete first, abstract later, and the question with the highest yield at the end.
Interview guide, tacit knowledge - Area: ______ Knowledge holder: ______
1. Walk me through your last working day step by step. What did you do
first, what came after that?
2. Where did you do something differently from "by the book" yesterday?
Why?
3. How can you tell something is off before anyone else notices?
4. What would have happened if you had not seen or done that?
5. Tell me about the last time something went badly wrong. What would
have prevented it?
6. Which customers, suppliers, machines or cases do you treat differently
from the rest? All of them you can think of, please.
7. What does your deputy ask you most often while you are on vacation?
8. What would a new colleague still get wrong after three months, even
after reading the instructions?
9. Who do you turn to for advice when you are stuck? On what?
10. What do you know about your work that you believe nobody else in the
company knows?
Two notes on running it. First: follow up at least once on every answer before you move to the next question. Second: write statements down verbatim, not summarized. "I ease the feed rate back a bit when it starts to rattle" is documentation. "Setter adjusts parameters based on experience" is not.
Worked through: a machining shop with 70 employees
A contract manufacturer with 70 employees, turning and milling machines, three shifts. The most experienced setter, Mr. Brandt, 61, has announced his retirement in two years. Two younger setters have been trained up, but the scrap rate in their shifts is twice as high as in his. The setup sheets are complete. The difference is tacit.
The operations manager schedules three sessions: two follow-up interviews with Mr. Brandt using the guide above, 40 minutes each, and a two-hour observation on an early shift with thinking aloud. Total effort including write-up: one working day for the operations manager, four hours for Mr. Brandt.
The result: 17 decision rules that appeared in no setup sheet. Among them: with material 1.4571, check the first three parts after a tool change instead of after twenty, because the cutting edge beds in during the first few minutes. On one particular customer part, clean the clamping device after every batch, because chips collect in a pocket and ruin repeat accuracy. When the machine starts cold after the weekend, run only non-critical parts for the first half hour. On top of that, nine exceptions relating to individual customers and tools, and three rules that Mr. Brandt, when pressed, classified as "actually superstition" himself and that were dropped.
The 17 rules were added to the setup sheets, each with the note "Source: interview Brandt, 03/2026." The two younger setters worked with them for three months and flagged two rules as unclear, which were sharpened up in a case discussion. Six months on, the scrap rate in their shifts was 40 percent lower. Not zero, not at Brandt's level. But the gap that used to be inexplicable is now two thirds explained and transferred.
Limits: what cannot be made explicit
It would be dishonest to claim that every bit of experience-based knowledge can be turned into rules. The setter's ear, the feel in the hand when tightening a screw, the sales manager's sense for the mood on a phone call: that is skill, and skill comes from practice, not from reading. No interview in the world turns a successor into a Brandt in two weeks.
What can almost always be made explicit are the decision rules that follow from the skill: when to check, when to call, when to deviate, when to ask someone. And the exceptions: which customer, which part, which machine is different from the rest. Those two layers account for the largest part of the difference between a beginner and an experienced hand, and they can be lifted in three to four hours per knowledge holder. The skill itself the successor still has to build, but he builds it with guidance, and considerably faster. Which forms of handover suit that, from tandem work to job rotation, is compared in the guide to knowledge transfer methods.
A second limit is human. Anyone asked to give up their knowledge has to be sure it will not be used against them. The setter who names his rules gives away part of what makes him irreplaceable. That only works in a setting that is voluntary, respectful and explicitly free of performance evaluation. Try to extract tacit knowledge under pressure and you get the version for the boss, not the version that is true.
If you do not want to run the interviews yourself, or simply have no time to do it for 20 knowledge holders: wissa.ai asks the follow-up questions, documents decision rules and exceptions with a source reference for every statement, and updates the documentation after each conversation with a diff against the previous version. GDPR-compliant with EU hosting, voluntary participation, no performance evaluation. The first three interviews are free; after that, 12 interview credits cost 149 euros, and interviewed employees stay free. Register for free
Conclusion
Tacit knowledge is the distance between "by the instructions" and "the way the experienced person does it." You cannot have it written down, because the knowledge holders themselves do not know what they know, and because the valuable part sits in the exceptions rather than the normal case. What works is drawing it out instead of asking for it: persistent follow-ups on "how can you tell", observation with thinking aloud, stories about the last time it went wrong, case discussions, and a running exceptions log. Not everything becomes explicit that way. The decision rules and the exceptions do, and they account for most of the difference.
FAQ
What is the difference between explicit and tacit knowledge?
Explicit knowledge can be spoken, written down and passed on: prices, procedures, machine settings. Tacit knowledge is experience-based knowledge that someone applies without being able to state it as rules: recognizing patterns, reading situations, knowing the exceptions. The difference is not in the value but in the transferability.
What is an example of tacit knowledge at work?
A machine setter who hears from the running noise that scrap is about to start and eases back the feed rate before the measurement shows any deviation. The settings are in the setup sheet; the hearing is written down nowhere. Similarly: the accountant who knows which customers will not pay an invoice without a purchase order number.
How do you make tacit knowledge explicit?
By drawing it out rather than asking for it: questions like "how can you tell that ...?" and "what would have happened if not?" force the knowledge holder to name the criterion behind the action. Observation with thinking aloud, stories about the last mistake, case discussions in the team and a continuously maintained exceptions log round it out.
Why does it not work to have employees simply write down what they know?
Because they do not know what they know. After years, experience-based knowledge feels self-evident and does not register as worth mentioning. On top of that, documentation written at a desk describes the normal case, while the value sits in the exceptions, which only come to mind when a concrete case is in front of you.
Can all experience-based knowledge be documented?
No. The skill itself, the ear or the feel in the hand, only comes from practice. What can be documented are the decision rules that follow from it, and the exceptions. Both account for the largest part of the difference between a beginner and an experienced hand, and both can be lifted in a few hours per knowledge holder.