Tacit vs explicit knowledge: examples and how to share each

Explicit knowledge is knowledge expressed in a form other people can inspect, such as a procedure, diagram or written explanation. Tacit knowledge is the experience-based judgement and know-how people use without being able to explain every part of it. A checklist can describe the steps in a task; recognising when those steps are no longer enough may depend on experience.

The distinction matters when a team documents its work, trains a colleague or prepares for someone to leave. Writing down a process helps, but the document and the ability to perform the work are different outcomes. Use documentation for what can be stated clearly, and supported practice for the judgement that still needs to be developed.

What is explicit knowledge?

Explicit knowledge has been articulated so that another person can examine it. Examples include a product specification, a troubleshooting procedure, a calculation method, a decision record and an explanation of why a team chose one approach over another. AIIM distinguishes this codified knowledge from the knowledge carried through people's experience. AIIM's explanation of tacit and explicit knowledge.

“Explicit” describes how the knowledge is expressed. It does not mean the content is correct, current or complete. An outdated procedure is still explicit. So is a clearly written explanation that rests on a mistaken assumption.

That distinction changes the review task. Check whether the material says what the reader needs, whether its claims are accurate, and whether its conditions still apply. Simply finding a document does not establish any of those things.

What is tacit knowledge?

Tacit knowledge includes abilities and judgement developed through experience: noticing a meaningful pattern, recognising an unusual situation, anticipating a consequence or adjusting an action to the circumstances. Cognitive psychologist Gary Klein argues that defining it only as something people cannot articulate misses these positive capabilities. His account emphasises recognition and pattern matching. Gary Klein, “Unpacking Tacit Knowledge”.

For a workplace example, imagine an experienced support lead reading a customer message. The written escalation policy says which categories require escalation. The lead also notices that a seemingly routine request contains an unusual combination of constraints and decides to ask another question before offering a solution. Some of that reasoning may be explainable afterwards; some may depend on recognising patterns learned across earlier cases.

This is an illustrative example. It does not mean an experienced person's intuition is always right. Ask what evidence supports the judgement and how someone else could check it. Experience can produce useful sensitivity, but confidence alone should not decide the issue.

The practical differences

Where you look for it

For explicit knowledge, look for an inspectable representation: a document, diagram, worked calculation or explanation. For tacit knowledge, look at how someone performs and adapts during a real task. Asking only for a folder of files may miss the second part.

How you share it

Explicit material can be reviewed, linked and revised. For tacit aspects, pair explanation with observation, practice and feedback. AIIM describes mentoring and on-the-job training as ways people share experience-based knowledge. AIIM on knowledge sharing.

A useful practical implication is to combine the two: let a colleague consult the procedure while attempting a task, then discuss where the instructions did not tell them enough. That exposes a more specific gap than asking whether they have read the document.

How you check understanding

For an explicit rule, ask the learner to find it, explain it and apply it to a suitable example. For a judgement-heavy task, also ask what they noticed, which alternatives they considered and when they would seek help. These are proposed review methods, not a validated assessment instrument.

What can go wrong

Explicit material can become stale or lose its context. A learner may follow the steps correctly in a situation where they do not apply. Tacit knowledge can remain concentrated in one person, while explanations such as “you just know” leave others with little to practise.

Both problems need a more concrete description of the work. Identify the conditions, the observable cues and the decisions rather than treating the knowledge category as the solution.

Workplace examples: the two usually appear together

The following examples are fictional and show how the distinction can guide a team's next step.

Customer support

The explicit part is the escalation policy, service description and steps for reproducing a problem. A tacit element may be recognising that the customer's explanation does not fit the usual pattern and choosing a clarifying question.

To share both, review two similar cases with different outcomes. Record which clues mattered and which did not. Then let the learner handle an appropriate practice case and explain their reasoning before receiving feedback. Keep real customer data within the team's approved handling rules.

Project planning

The explicit part is the brief, dependencies, acceptance criteria and recorded decisions. A tacit element may be noticing that an apparently small request depends on several teams whose availability is uncertain.

Make the dependency reasoning visible. Ask the experienced planner what they checked first, which assumption would change the estimate and what would cause them to escalate. Write down useful questions while retaining a review step for unfamiliar situations.

Research interviews

The explicit part is the interview guide and the purpose of each topic. A tacit element may be judging when to pause, ask for an example or move away from a question that is producing rehearsed answers.

For training, discuss an authorised example and compare possible follow-up questions. A transcript supports review of the words, but it does not preserve every gesture, contextual cue or aspect of delivery. Do not assume that reading it recreates the whole encounter.

Operational procedures

The explicit part is the sequence of actions, required inputs and checks. A tacit element may be noticing an abnormal result before it crosses a formal threshold.

Document the cues the experienced colleague can describe, then practise interpreting examples with them. Where a task has formal qualification or safety requirements, follow the applicable training and supervision process. An informal recording or AI-generated document does not replace it.

Is undocumented knowledge always tacit?

No. A colleague may know a precise rule that nobody has yet written down. Once asked, they can state it clearly. That is a different practical problem from a skill they cannot fully explain.

Teams sometimes use “implicit knowledge” for knowledge that could be articulated but has not been. Terminology varies, so agree what the label means in your discussion. The operational question is more useful: can the missing knowledge be stated clearly, or does the learner also need experience applying it?

For example, “the finance export must use this date format” may simply need documentation. Knowing which ambiguous transaction needs investigation may require examples, reasoning and supervised practice. Do not send both problems to the same document-writing queue by default.

Can you turn tacit knowledge into explicit knowledge?

You can often make parts of an expert's reasoning explicit. You should not assume that recording an explanation captures the whole capability. Klein's account distinguishes several forms of tacit knowledge and warns against treating them as a single thing with identical constraints. Klein's discussion of different forms of tacit knowledge.

A useful goal is to make the work easier to learn and review. Capture the steps and reasoning that can be expressed, preserve useful examples, and identify what still needs practice. A procedure can support judgement without claiming to contain all of it.

A practical way to capture an explanation

Start with one real task the learner needs to perform. Avoid a broad request to “document everything you know”. Prepare an approved example, identify any sensitive content and agree whether recording the explanation is appropriate.

Ask for a specific episode

Invite the colleague to describe a recent or representative case: what the situation was, what they noticed and what they did next. Use a fictionalised or otherwise approved example when the original contains private material.

Then ask questions that reveal decisions rather than just steps:

• What made you check that first?

• What would a less experienced person probably miss?

• Which other explanation did you consider?

• What would have made you choose a different action?

• Where would you stop and ask someone else?

Keep the answers tied to the case. A rule inferred from one example should be labelled as a candidate rule until the owner confirms where it applies.

Separate instructions, reasons and exceptions

After the explanation, organise the material into actions, reasons for those actions, checks, exceptions and unanswered questions. Keep the original source available during review. If the speaker contradicts themselves, ask for clarification instead of quietly choosing the cleaner sentence.

Weeve can help turn a spoken explanation into a draft operating procedure. This uses the recorded speech and transcript; it does not capture the screen, clicks or screenshots. Describe the relevant actions and checks aloud, then review the draft against the actual process.

Genuine Weeve interface with synthetic demonstration content. The source reader lets you check the words behind an interpretation; it is not a complete record of someone's expertise.

You can also ask Chat about saved recordings, using a request such as: “Separate the stated steps, reasons, exceptions and open questions. Cite the supporting passages and flag any rule you inferred rather than one the speaker stated.” Review source references and the answer's coverage before accepting the draft. Transcription and Chat can make mistakes or miss material.

Local Chat processes recording text on your Mac. If you choose an optional cloud provider, relevant text is sent outside the device. Use the setting appropriate for the material and the team's handling requirements.

Have another person try it

Give the learner a suitable example and ask them to work through it using the draft. Ask them to explain their choices. Note where they needed additional context, where a step was ambiguous and where the experienced colleague had to intervene.

Revise the document for gaps that can be explained. Plan further observation or practice for the remaining judgement. If the learner can repeat the original example but becomes stuck when one condition changes, the transfer is still incomplete.

Choose the right next step for the gap

If people cannot find an existing answer, improve its location and ownership. If the answer is missing but easy to state, document it. If people can recite the instructions but struggle to apply them, add examples and feedback. If experts disagree, preserve the disagreement and resolve the relevant conditions before presenting one universal rule.

Keep an owner and a review trigger for explicit material, such as a process change or a recurring failure. For practice, define the task the learner should be able to perform and when they should escalate. Count success by usable understanding and appropriate action, not by the number of recordings or pages produced.

The next useful step is small: choose one task, capture one explanation and have someone else attempt an appropriate example. That will show which knowledge belongs in a document and which capability still needs to be developed through experience.