Tacit and Explicit Knowledge

In 1958, the Hungarian-British polymath Michael Polanyi made an observation that is as simple as it is devastating for anyone in the business of building knowledge management systems: "We can know more than we can tell."

Six words. That is the core of the tacit knowledge problem, and it has been the rock upon which knowledge management initiative after knowledge management initiative has foundered. You can spend millions of dollars on a wiki, a document management system, a knowledge graph, and a dozen AI-powered tools, and at the end of the day, the most valuable knowledge in your organization — or in your own head — will stubbornly refuse to be captured in any of them.

Understanding why this is the case, and what can be done about it, is arguably the most practically important thing you can learn about knowledge management. This chapter is where the philosophical rubber meets the road.

Polanyi's Tacit Dimension

Michael Polanyi was a physical chemist before he became a philosopher, which may explain why his philosophical work has a directness and concreteness that is sometimes lacking in the genre. His central argument, developed across several books but articulated most accessibly in The Tacit Dimension (1966), runs as follows.

Consider the act of recognizing a face. You can pick your mother's face out of a crowd of thousands without hesitation. But can you explain how you do it? Can you articulate the features, proportions, and relationships that distinguish her face from all others? You cannot — or at least, you cannot do so with enough precision to enable someone else to pick her out based solely on your description. Your knowledge of your mother's face vastly exceeds your ability to articulate that knowledge.

This is not a failure of language or effort. It is a structural feature of how certain kinds of knowledge work. Polanyi argued that all knowledge has a tacit dimension — a component that cannot be fully articulated in explicit terms. Even the most formal, propositional knowledge rests on a foundation of tacit understanding: you cannot read a mathematical proof without tacitly knowing how to read, how to follow logical arguments, and what counts as a valid inference step. These underlying competencies are largely invisible to the person who possesses them, which is precisely why they are so hard to transfer.

Polanyi introduced a useful distinction between focal awareness and subsidiary awareness. When you drive a car, your focal awareness is on the road, traffic, and your destination. But you are also subsidiarily aware of the pressure of the steering wheel in your hands, the vibrations of the engine, the position of the pedals under your feet. You are relying on all of this subsidiary knowledge to drive, but if you shift your focal attention to it — if you start thinking consciously about what your hands and feet are doing — your performance actually degrades. The pianist who starts thinking about their fingers fumbles. The centipede who starts thinking about which leg to move next trips.

This is not mysticism. It is a perfectly tractable observation about how skilled performance works. The tacit component is not ineffable in the strong sense — it is not beyond all possible understanding. But it is not the kind of thing that can be straightforwardly written down and transferred via documentation.

Explicit Knowledge: What You Can Write Down

Explicit knowledge is, by contrast, knowledge that can be articulated, codified, and communicated in formal language — words, numbers, diagrams, equations, code. It is the kind of knowledge that appears in textbooks, manuals, databases, and knowledge bases. It can be transmitted from one person to another without the two people ever meeting, because the knowledge is encoded in a medium (text, typically) that is independent of the knower.

The examples are obvious: the boiling point of water, the syntax of Python, the steps in a Standard Operating Procedure, the provisions of a contract. Explicit knowledge is what documentation is made of.

The overwhelming majority of effort in knowledge management has been directed at explicit knowledge, for the obvious reason that it is the kind amenable to being managed by systems. You can store it, index it, search it, version it, and share it using technology that has existed, in some form, since Gutenberg. The tools have gotten better — from filing cabinets to databases to wikis to knowledge graphs — but the basic approach is the same: take knowledge that is already explicit and make it easier to find and use.

This is valuable work, and I do not mean to diminish it. But it is the easy part of the problem. The hard part is the tacit knowledge, and the hardest part of the hard part is the interface between the two.

The SECI Model

In 1995, Ikujiro Nonaka and Hirotaka Takeuchi published The Knowledge-Creating Company, which proposed a model of knowledge creation based on the interplay between tacit and explicit knowledge. Their SECI model (Socialization, Externalization, Combination, Internalization) has become the most widely cited framework in knowledge management, despite — or perhaps because of — its simplicity.

The model describes four modes of knowledge conversion:

Socialization (Tacit to Tacit)

Socialization is the transfer of tacit knowledge directly from one person to another, without passing through an explicit form. The mechanism is shared experience: apprenticeship, observation, imitation, and practice.

A junior developer sits next to a senior developer and watches them debug a production issue. The junior does not just learn the specific commands and techniques used; they absorb a way of thinking about problems, a set of instincts about where to look first, a feel for when something is "off." None of this is written down. Much of it cannot be written down. It is transferred through proximity, observation, and shared activity.

Traditional apprenticeship systems — in craft trades, medicine, law, and many other fields — are fundamentally socialization technologies. The master does not teach primarily through lectures or textbooks; the master teaches by doing, with the apprentice watching, imitating, and gradually developing their own tacit understanding. The lengthy duration of these apprenticeships — years, typically — reflects the time required to transfer tacit knowledge through shared experience.

In organizational contexts, socialization happens through mentoring, pairing, team collaboration, and the informal interactions that occur when people work in physical proximity. The loss of these interactions during periods of remote work is not just a social problem; it is an epistemic one. The tacit knowledge that would have been transferred through daily co-located work does not get transferred at all, and no amount of Slack messages or Zoom calls fully compensates.

Externalization (Tacit to Explicit)

Externalization is the process of articulating tacit knowledge in explicit form — putting into words (or diagrams, or models) something that was previously unarticulated. This is the critical bottleneck in knowledge management, and the place where most systems succeed or fail.

Externalization is hard because, by definition, it requires expressing what has not previously been expressed. The knowledge holder must become aware of their own tacit understanding — which is typically invisible to them — and find a way to communicate it. This usually involves metaphor, analogy, narrative, and other indirect forms of expression rather than straightforward propositional statements.

Consider how an experienced software architect explains their design decisions. They might say something like: "This system is like a series of locks on a canal — each component controls the flow of data to the next, and you can raise or lower the water level independently." This metaphor conveys something real about the architecture, but it is not a specification. It is an attempt to externalize tacit understanding in a form that evokes a similar understanding in the listener.

The best externalization techniques share several features:

• They use concrete examples rather than abstract principles. "Here's what I did when I encountered this specific situation" is almost always more useful than "Here's the general principle."
• They capture the reasoning, not just the conclusion. "I chose option A because B would have caused problems X and Y" transfers more knowledge than "Use option A."
• They acknowledge uncertainty and context-dependence. "This usually works, but not when..." is more honest and more useful than an unconditional prescription.
• They use multiple modalities. Diagrams, stories, worked examples, and annotated code samples all capture different facets of tacit knowledge.

Documentation reviews, post-mortems, and structured interviews are all externalization practices. So is the practice of rubber-duck debugging — explaining your problem to an inanimate object (or a patient colleague) in order to make your own tacit understanding explicit. The act of articulation itself often produces new understanding, which is why writing is not just a way of recording what you know but a way of discovering what you know.

Combination (Explicit to Explicit)

Combination is the process of assembling, rearranging, and synthesizing existing explicit knowledge to produce new explicit knowledge. This is what most traditional information management is about: collecting documents, organizing databases, creating reports and summaries, building knowledge bases from existing materials.

A literature review is a combination exercise: you take explicit knowledge from many sources and synthesize it into a new explicit artifact. A data analysis that combines information from multiple databases to produce new insights is another example. So is the process of updating a knowledge base by integrating new information with existing entries.

Combination is the mode of knowledge conversion that technology handles best. Search engines, databases, data integration tools, and increasingly, AI-powered summarization and synthesis tools are all combination technologies. When you ask a large language model to summarize a set of documents or identify connections among them, you are using it as a combination engine.

The risk with combination is that it can produce the illusion of new knowledge without genuine understanding. Rearranging and repackaging explicit knowledge sometimes yields genuine insight, but often it just produces more explicit knowledge — more documents, more summaries, more entries in the knowledge base — without any corresponding increase in understanding. This is the knowledge management equivalent of rearranging deck chairs: the system looks busier, but nobody is actually smarter.

Internalization (Explicit to Tacit)

Internalization is the process of absorbing explicit knowledge into your tacit knowledge base — turning what you have read or been told into something you can do. This is, essentially, learning in its deepest sense: not just acquiring information but developing the ability to apply it fluently and automatically.

When you read a book on negotiation techniques and then, months later, find yourself instinctively using one of those techniques in a conversation without consciously recalling the book, you have internalized that knowledge. When a developer reads a tutorial on a design pattern and then, after using it several times, begins to see opportunities to apply it without conscious effort, the explicit knowledge has become tacit.

Internalization is facilitated by practice, repetition, and application in varied contexts. It is hindered by passive consumption. Reading a book does not internalize its knowledge; applying its ideas does. This is why "learning by doing" is not just a pedagogical slogan but an epistemological necessity. Explicit knowledge that is never internalized — never practiced, never applied, never tested against reality — remains inert information, regardless of how carefully it is stored in your knowledge base.

This has a sobering implication for knowledge management: the knowledge base, by itself, does not produce internalization. It can support internalization by making relevant knowledge available at the point of application — surfacing the right design pattern when you are working on a design problem, or the right troubleshooting procedure when you encounter a specific error. But the internalization itself happens in the practitioner, through practice. No system can do it for you.

Ba: The Shared Context for Knowledge Creation

Nonaka and Takeuchi introduced the concept of ba — a Japanese term that can be translated as "place" or "context" — to describe the shared space in which knowledge creation occurs. Ba is not just a physical location; it is a shared context that includes physical space, virtual space, mental space, and the relationships and interactions that occur within it.

Different modes of knowledge conversion require different types of ba:

• Originating ba (for socialization): face-to-face, informal, trust-based. The coffee room, the pair-programming session, the after-work conversation.
• Dialoguing ba (for externalization): structured but open-ended conversation, brainstorming, design reviews. The whiteboard session, the structured interview, the retrospective.
• Systemizing ba (for combination): collaborative virtual environments, shared databases, document management systems. The wiki, the shared drive, the knowledge graph.
• Exercising ba (for internalization): practice environments, simulations, real-world application with feedback. The lab, the sandbox environment, the first solo surgery.

The concept of ba highlights something that knowledge management technologists often overlook: the social and environmental conditions for knowledge creation and transfer are at least as important as the tools. You can have the best knowledge base in the world, but if people do not trust each other enough to share what they know (originating ba), or if there are no structured opportunities for articulating tacit knowledge (dialoguing ba), or if there are no opportunities to practice and apply knowledge (exercising ba), the system will contain only a thin residue of the organization's actual knowledge.

Why Most KM Systems Fail at Tacit Knowledge

With the SECI model as a framework, we can diagnose why most knowledge management systems disappoint.

They focus almost exclusively on combination and neglect the other three modes. Building a wiki or a knowledge base is a combination exercise — you are assembling and organizing explicit knowledge. This is necessary but not sufficient. Without socialization (to transfer tacit knowledge directly), externalization (to articulate tacit knowledge in explicit form), and internalization (to turn explicit knowledge into practiced skill), the knowledge base is a repository of documents, not a knowledge management system.

They assume knowledge is naturally explicit. The implicit assumption behind most KM tools is that people have explicit knowledge and just need a better place to put it. In reality, much of the most valuable knowledge is tacit and has never been articulated. The bottleneck is not storage and retrieval; it is externalization — getting the knowledge out of people's heads and into a form that can be shared. This is a human process, not a technical one, and it requires time, trust, and skilled facilitation.

They underestimate the cost of externalization. Articulating tacit knowledge is cognitively expensive. Writing good documentation takes time and effort, and it competes with the "real work" of doing whatever it is you are supposed to be doing. In most organizations, there is no incentive to spend time externalizing knowledge, and strong incentives not to — the person who is "always documenting" is often seen as less productive than the person who is "always building." This is a management failure, not a technology failure, but it means that even excellent tools go unused.

They conflate storage with transfer. Putting knowledge in a system does not mean anyone else will find it, read it, understand it, or internalize it. The knowledge management literature is full of studies showing that people rarely search organizational knowledge bases, preferring to ask a colleague instead. This is not laziness; it is a rational response to the fact that asking a colleague gives you access to their tacit knowledge — the context, caveats, and judgment that surround the explicit answer — while searching a database gives you only the explicit residue.

Concrete Examples

Software Engineering

Software engineering is saturated with tacit knowledge. Consider code review. An experienced reviewer does not just check for syntax errors and style violations; they assess the design — whether the abstractions are right, whether the code will be maintainable, whether it handles edge cases that are not immediately obvious. This judgment is built on years of experience writing and maintaining code, and it resists explicit formulation. You can write coding standards and style guides (externalization), but these capture only a fraction of what an experienced reviewer knows.

The practice of pair programming is a socialization technology par excellence. Two developers working together transfer tacit knowledge — debugging strategies, design intuitions, domain understanding — that neither could articulate fully in a document. The fact that pair programming is simultaneously a knowledge transfer mechanism and a productive work practice is not a coincidence; it is a feature. The knowledge transfers because it is embedded in shared, purposeful activity.

Architecture Decision Records (ADRs) are an externalization practice: they capture not just the decision but the context, constraints, and reasoning that led to it. Good ADRs transfer significant knowledge; bad ones (which just record the decision without the reasoning) transfer almost none. The difference is whether the author has done the cognitive work of externalizing their tacit understanding of why the decision was made.

Medicine

Medical expertise is a domain where the tacit dimension is literally a matter of life and death. A radiologist looking at a scan does not just apply a checklist of features; they perceive patterns, anomalies, and subtle indicators that they could not fully articulate even if you gave them unlimited time and paper. Studies have shown that expert radiologists can detect abnormalities with brief exposures to an image — too brief for conscious analysis — suggesting that their diagnostic skill operates partly below the level of explicit awareness.

Clinical reasoning — the process by which a physician moves from symptoms to diagnosis to treatment — is similarly tacit-laden. The experienced clinician develops a repertoire of illness scripts: pattern-matched templates that connect constellations of symptoms to diagnoses. These scripts are refined through hundreds or thousands of cases, and they operate largely through recognition rather than deliberate analysis. Textbooks can describe the scripts (externalization), and case-based learning can help students develop them (internalization), but there is no shortcut past the accumulated experience that produces genuine clinical expertise.

The failure of expert systems in medicine during the 1980s and 1990s is partly a tacit knowledge story. Systems like MYCIN were impressive at encoding the explicit, propositional component of medical knowledge — the rules and relationships between symptoms, diseases, and treatments. But they could not capture the tacit knowledge that physicians use to decide which rules to apply, how to weigh conflicting evidence, and when to override the standard approach based on a holistic assessment of the patient. The system contained the explicit knowledge; the physician possessed the tacit knowledge. The explicit knowledge alone was not enough.

Craft Trades

Craft knowledge is perhaps the purest example of tacit knowledge in action. A master potter's knowledge of how much pressure to apply when throwing a pot, how the clay should feel at different stages of drying, when the glaze is ready — this is knowledge that can only be acquired through extensive, hands-on practice under the guidance of someone who already has it.

The traditional apprenticeship model in craft trades — three to seven years of working under a master — exists precisely because this is how long it takes to transfer tacit knowledge through socialization. The apprentice does not just learn techniques; they develop a feel for the material, a sense of quality, an aesthetic judgment, and a repertoire of solutions to common problems. All of this is tacit. All of it is essential. And none of it can be adequately captured in a manual, however well-written.

This does not mean that documentation is useless in the crafts — written recipes, measured specifications, and step-by-step instructions all have their place. But they are supplements to, not substitutes for, the tacit knowledge that makes the difference between a competent practitioner and a master.

What Can Be Done

If tacit knowledge is inherently resistant to explicit codification, does that mean knowledge management systems are doomed to capture only the least valuable knowledge? Not entirely. But it does mean that the most effective approaches to managing tacit knowledge are indirect:

Create conditions for socialization. Design physical and virtual spaces that encourage informal interaction. Support mentoring and pairing. Protect the time people spend sharing knowledge with each other from the relentless pressure to produce visible output.

Invest in externalization practices. Structured interviews, post-mortems, design reviews, and documentation sprints are all ways to help people articulate what they know. Make these practices part of the workflow, not an afterthought. Reward people who do them well.

Design for internalization. A knowledge base that surfaces relevant knowledge at the point of need — when you are working on a problem, not when you are idly browsing — supports internalization by connecting explicit knowledge to practice. Spaced repetition systems, progressive disclosure, and worked examples are all internalization aids.

Accept the limits. Some tacit knowledge will never be fully captured, and that is okay. The goal is not to eliminate tacit knowledge but to manage the interface between tacit and explicit knowledge as effectively as possible. The knowledge base is one part of a larger system that includes people, relationships, practices, and environments. It is an important part, but only a part.

With this understanding of the tacit-explicit distinction firmly in hand, we are now ready to examine an even more fundamental set of distinctions: the relationships among data, information, knowledge, and wisdom, and what they mean for the systems we build.