Capturing tacit knowledge

Capturing tacit knowledge hinges on one practical step: converting hard-to-explain expertise held by people into explicit, codified knowledge that others can access. That conversion requires codification, but codification only works if the capturing process is done well—by pulling the “thoughts and experiences” experts use while solving real problems and translating them into rules, programs, or other structured representations.

Tacit knowledge lives in two places: in explicit artifacts like books, manuscripts, and guidelines, and in tacit form inside experts themselves. The capturing task focuses on the second category—transferring expertise from knowledge sources (often experts) into a repository where it can be reused. In this workflow, a knowledge developer acts as the bridge. The developer collaborates with experts to capture how they actually work, then uses tools and techniques to interpret what experts say and infer the underlying reasoning. The end goal is to build rules that reflect an expert’s decision process closely enough that other people can apply them later.

That work is demanding because experts rarely rely only on written facts. Novices may offer solutions based on common-sense reasoning and readily stated figures, while experts approach problems through a different lens: how they define the problem, weigh factors, and arrive at a solution. For knowledge developers to codify that expertise, they must understand the problem domain and how it is modeled, not just the final answer. Scenario-based thinking becomes important here: developers need to capture how experts would respond when similar situations arise in the future, so the resulting knowledge remains usable beyond a single case.

Choosing the right experts is another major determinant of success. Experts are distinguished by the quantity and quality of knowledge in a domain, plus their ability to explain processes clearly. The transcript emphasizes traits that support knowledge transfer—communication skills, patience, motivation to share, and the ability to see the “big picture” by identifying causes rather than only symptoms. Experts are also described as divergent thinkers who use innovative approaches while remaining stable and persistent in how they solve problems.

Organizations then face a structural choice: rely on a single expert or assemble multiple experts. A single-expert approach can be simpler and can preserve confidentiality, since one specialist provides advice within a restricted domain. But it can also limit perspective and reduce the depth of discussion needed to capture the full reasoning behind decisions. Multiple-expert systems are favored for complex problems—especially in R&D, diagnosis, and treatment of critical illness—because pooling diverse expertise can improve knowledge representation and generate alternative ways to model and solve the same issue. The trade-offs are real: scheduling experts, managing disagreements, handling confidentiality concerns, and avoiding conflicts of interest. Multiple experts also typically require multiple knowledge developers to capture and codify each domain effectively.

Finally, the transcript lays out how knowledge developers should elicit tacit knowledge through interviews. Interviewing is presented as the most sought-after technique, but it must be planned: obtain permission in advance, avoid interrupting, prevent defensiveness, validate what is collected, and reduce reliability problems through careful questioning. Different interview formats—structured, semi-structured, and unstructured—can be combined with varied question types (multiple choice, subjective, objective, yes/no, ranking scales). The developer must also manage biases, use a level playing field, and avoid discrimination, while ensuring the expert feels confident that the information will be used for a clear purpose.