The Expert Who Couldn't Explain What They Knew

The Expert Who Couldn't Explain What They Knew

You have someone on your team who does exceptional work. Their output is consistently excellent. You ask them to document their process so others can replicate it. They try. The documentation looks complete. Juniors follow it carefully and still can't match the output. The expert reviews their work, spots problems instantly, but struggles to say exactly what went wrong. You've just run into one of the most frustrating, most common knowledge transfer problems in any organization.

Core Claim

Deep expertise isn't stored as a list of instructions you can look up and follow. It's baked into your nervous system as automatic pattern recognition, operating below the level of conscious thought. That's what makes experts fast and accurate. It's also what makes them terrible at explaining what they do.

Situation

Picture your most seasoned colleague. They review a proposal, spot a fatal flaw in 30 seconds, and send it back with three sentences of feedback. A junior spends an hour reviewing the same document and misses the problem entirely. You ask the expert to walk the junior through their thinking. They try, but the explanation is frustratingly vague: "It just didn't feel right. The numbers were off."

That's not unhelpfulness. That's a structural feature of how expertise actually works.

The expert becomes a single point of failure. Projects queue up waiting for their review. Juniors can't develop because they can't see what the expert sees. And when the expert eventually leaves, retires, or gets promoted, the knowledge walks out the door with them.

Mechanism

Here's what's actually happening inside the expert's head. Their years of experience have built an incredibly refined internal model of what good work looks like in their domain. When they look at your proposal, their brain isn't running through a checklist. It's generating a prediction: "this is what a solid proposal looks like," and comparing that prediction against what's in front of them. The mismatch registers as a feeling, a sense that something is off, long before conscious analysis kicks in.

This is predictive processing doing exactly what it's supposed to do. Expertise is efficient precisely because it bypasses slow, deliberate reasoning. The expert perceives the answer directly.

The problem: that perception is implicit. It's procedural knowledge, the kind stored in the same place as riding a bike or driving a car. When the expert tries to explain their thinking, they're not reading from an internal manual. They're reconstructing a story after the fact. The micro-decisions their brain made automatically, in milliseconds, don't show up in that reconstruction. The explanation sounds reasonable but is missing most of the actual content.

Practice

The fix, developed by cognitive scientists Gary Klein and Beth Crandall through a method called Cognitive Task Analysis, is to externalize the expert's decision-making in real time, not after the fact.

Here's how it works in practice. Pair the expert with a junior colleague while the expert works on a live problem. The junior's only job is to ask two questions, repeatedly: "What are you noticing right now?" and "What would change your approach?"

This isn't a passive documentation exercise. It's a structured interruption of the expert's automatic processing, forcing implicit priors into explicit, examinable language. The expert is pointing at what they see as they see it, rather than describing it abstractly from memory later.

Why It Works

When you narrate your thinking in real time, you're converting automatic pattern recognition into hypotheses that other people can actually examine and learn from. The junior isn't just watching, they're building a working model of how the expert's attention moves across a problem.

There's a side benefit worth noting: experts frequently discover calibration errors in their own thinking during this process. Assumptions they've been operating on for years, never examined, suddenly become visible. The knowledge transfer goes both ways.

You're not trying to capture expertise in a document. You're trying to make the invisible visible, one live problem at a time.