Tacit Dimension Michael Polanyi

Why Your Documentation Has Blanks

The problem hit me during an onboarding cycle. A new engineer spent three weeks trying to reproduce a deployment procedure that was fully documented. Every step was written down. The results were still inconsistent. I watched them get stuck on a single gate where the procedure said "check the sensor readings." It meant nothing precise. Which sensor? What threshold? What if two sensors disagreed? The person who wrote that section assumed all of it was obvious. It wasn't obvious. It was tacit knowledge, and it was never going to survive in a paragraph. I sat with their senior for two days. Not to extract the knowledge explicitly, but just to watch. The senior glanced at a dashboard, made a decision in about four seconds, and moved on. No notes were taken. The knowledge existed in the glance, not in anything transcribable. That gap between what the document says and what the work actually requires is what Michael Polanyi named the Tacit Dimension Michael Polanyi is best known for describing, and it's the reason almost every knowledge transfer initiative fails at the edges.

What the Tacit Dimension Michael Polanyi Actually Means

Polanyi's core claim is simple and easily misread: we know more than we can tell. He didn't mean that as a poetic observation. He meant it as a structural claim about how knowledge works. All knowing involves a commitment that cannot itself be fully stated. TheTacit Dimension Michael Polanyi captures that unarticulated commitment. His framework uses a dependent-referent structure. You focus on one thing to understand another. A thermometer has a mercury column you can read, but you focus through that column to know the temperature. The mercury is the proximal term. The temperature is the distal term. In expertise, the same pattern repeats. A technician listens to an engine sound and focuses through that auditory signal to understand the mechanical fault. The sound is proximal. The diagnosis is distal. Most attempts to "capture tacit knowledge" miss this structure entirely. They try to document the distal term while ignoring the proximal integration that makes it work. You cannot copy the result. You have to reconstitute the integration. That requires exposure to the same signals, in the same context, repeated enough times for the pattern recognition to boot up.

Where This Breaks Down in Practice

The most common mistake is treating tacit knowledge like a translation problem. You assume someone has knowledge they just can't articulate, so your job is to coax it out through interviews or documentation exercises. This usually backfires because asking someone to articulate their process shifts their focus. They start monitoring their own thinking instead of doing the work. The quality of what they produce drops. The explanations sound logical afterward but don't actually describe the original performance. I ran into this exact issue when a team tried to create a decision tree for production incident response. The senior engineers produced trees that looked rigorous. When junior staff used them in real incidents, the trees missed the branching conditions that mattered. The seniors couldn't remember the sub-second cues that told them which branch to take. The cues were still there in their perception, but articulating the process had separated them from the cues that originally made the process work. The second issue is that tacit knowledge is embodied and contextual, not just cognitive. It lives partly in the body and partly in the specific environment where it was learned. A machinist knows a tool is wearing out by the feel in their hands and the sound in the room. Removing either variable degrades the knowledge. This is why shadowing programs fail when they are too short. Three days of observation does not recreate enough context for the integrative pattern to form.

How to Work With It

There is no clean extraction method. The most reliable approach is extended proximity. Pair a less experienced person with someone who has the tacit knowledge and let them work the same problems for a substantial period. I typically see results after six to eight weeks of daily pairing, not before. The knowledge transfer is not conscious. It happens through repeated exposure to the same signals in the same environment. If extended pairing is not possible, structured reflection helps partially. After a real task, the experienced person describes what they noticed and what they did not notice. The less experienced person writes those observations down. This does not transfer the tacit integration, but it does reduce the blind spots. It is faster than pairing but significantly less effective. Expect about half the transfer rate of sustained proximity, which means it takes roughly twice as long to reach the same competence level.

Common Pitfalls to Avoid

One pitfall is the illusion that codified knowledge replaces tacit knowledge. Documentation reduces variability for routine cases. It does not replace the need for tacit judgment in edge cases. I have seen teams treat a well-written procedure as a complete knowledge transfer and then wonder why performance degraded when a non-standard case appeared. The procedure covers the normal path. Tacit knowledge covers everything else. Assuming documentation is sufficient is a costly error. Another pitfall is treating tacit knowledge as transferable through instruction alone. Watching a demonstration five times does not create the same pattern recognition as performing the work under similar conditions for five weeks. The difference is not effort. It is structure. Demonstrations show the distal result. Practice builds the proximal-distant coupling that produces the result in the first place.

When This Framework Fails Completely

The tacit knowledge approach does not scale well beyond small groups. The proximity requirement means it works for teams of maybe five to ten people. Beyond that, the cost of extended pairing becomes prohibitive. If you need knowledge transfer across dozens of locations or hundreds of employees, this method will not work. You need formal training structures, simulation environments, or process redesign instead. Tacit knowledge transfer is expensive by design. Accepting that limit prevents you from wasting resources trying to force it into contexts where it cannot function. There is also a narrow situation where explicit instruction actually works better. When the knowledge domain is highly rule-bound with low ambiguity, procedural training is faster and more reliable. Inventory management, basic equipment operation, standard compliance checks. If the decisions follow clear conditional rules, do not bother with shadowing. Write good procedures and train against them. The Tacit Dimension Michael Polanyi describes becomes relevant only when the work requires judgment that cannot be fully stated.

A Specific Workaround I Used

On the deployment problem mentioned earlier, I tried a direct approach first. I asked the senior engineer to write down every consideration that went into the sensor check. They wrote twelve items. Three of them were wrong. The rest were incomplete. The engineer genuinely believed they had captured everything. The error came from the focus shift I described. Once they started writing, they were no longer doing the work, so the knowledge shifted. The workaround was to record a live session. I set up audio and screen capture while the engineer handled a real deployment. Then I had the junior engineer watch the recording and pause it at each decision point to predict what would happen next. We compared predictions against actual outcomes. This preserved the proximal-distant coupling because the junior engineer was still tracking the same signals in real time. The recording was a poor substitute for physical presence, but it captured enough context to close most of the gap. The junior engineer reached acceptable independence in three weeks instead of the usual eight. The key detail most people miss is the pause-and-predict step. Watching passively transfers very little. Predicting forces the observer to engage the same integrative process the practitioner uses. It is cognitively expensive. It is also the part that makes the difference.

What to Track When Measuring Success

If you are implementing any of this, measure consistency on edge cases, not just speed on routine tasks. Routine task speed improves with documentation. Edge case consistency improves with tacit knowledge transfer. If your metric is wrong, you will optimize for the wrong outcome and never notice the gap until something breaks. Track the number of non-standard cases each person handles without escalation. Track the variance in outcomes across similar edge cases. Track how long it takes a person to recognize when a situation deviates from the standard path. These metrics reflect tacit integration. Time-to-first-decision, error rate on uncommon inputs, and the ability to explain why a familiar pattern felt wrong are better signals than certification completion rates or test scores. The Tacit Dimension Michael Polanyi identified is not a philosophical curiosity. It is the structural reason most knowledge transfer programs look good on paper and underperform in practice. Knowing more than you can tell is not a personal failing. It is the normal condition of expertise. Working with that reality, rather than against it, changes what is possible.