What is the curse of knowledge?

The curse of knowledge is a cognitive bias where someone who knows something finds it hard to imagine not knowing it — so they communicate as if everyone shares their context. Coined by economists in 1989, it explains why experts make poor explainers: their own understanding fills in gaps the listener can't, so the message that feels clear to them lands as noise to everyone else.

What is an example of the curse of knowledge?

The classic example is Elizabeth Newton's "tappers and listeners" study. Tappers drummed out famous songs and predicted listeners would identify 50% of them; in reality, listeners got only 2.5% (3 of 120). At work, it looks like a senior engineer writing docs that say "this is the primary class for Fribblers" — obvious to them, meaningless to a new hire.

Is the curse of knowledge a cognitive bias?

Yes. It's a well-documented cognitive bias, sometimes called the curse of expertise. It's closely related to hindsight bias and illusory transparency — all variations on the same theme: your own knowledge distorts your estimate of what other people know or can infer.

How do you overcome the curse of knowledge on a remote team?

You can't fully remove it, but you can engineer around it. Test documentation on your newest team member, have receivers restate what they understood, and escalate ambiguous, high-stakes knowledge to a live, visual conversation instead of a longer doc. The key shift is replacing one-way broadcasting with a two-way channel where the listener can ask questions in real time.

What is the tappers and listeners study?

It's a 1990 Stanford experiment by Elizabeth Newton, popularized in Made to Stick. Participants who tapped out a song's rhythm dramatically overestimated how recognizable it was to listeners — predicting 50% recognition versus an actual 2.5%. It's the most cited demonstration of the bias because it shows how vividly experts overestimate how well their message is getting through.

The Curse of Knowledge: Why Your Docs Fail

In 1990, a Stanford graduate student named Elizabeth Newton ran an experiment so simple it sounds like a party game. She split people into "tappers" and "listeners." Each tapper picked a famous song — "Happy Birthday," the national anthem — and tapped out the rhythm on a table. Then they guessed how many listeners would name the tune. The tappers predicted the odds were 50 percent. The real number? Listeners guessed only 2.5 percent of the songs — 3 out of 120.

The tappers heard a full orchestra in their heads. The listeners heard random knocks on a table. That gap — between what the expert knows and what the expert can actually transmit — is the curse of knowledge, and it is quietly wrecking your remote team's documentation, onboarding, and handoffs.

Here's the uncomfortable part: the standard fix — "write better docs" — often makes it worse. This piece breaks down what it really is, why distributed teams get it worst, why more documentation can't cure it, and what actually closes the gap.

What the curse of knowledge actually is

The term was coined in a 1989 Journal of Political Economy article by economists Colin Camerer, George Loewenstein, and Martin Weber. They were studying markets, but the mechanism is universal: once you know something, you can't un-know it, and you lose the ability to imagine what it's like not to know it. As Chip and Dan Heath put it in Made to Stick, "Once we know something, we find it hard to imagine what it was like not to know it."

It goes by other names — the curse of expertise, the expert's curse. Whatever you call it, it's not a knowledge problem. The expert knows plenty. It's a transmission problem. The tapper isn't lying when they predict 50 percent; they genuinely can't hear the table the way the listener does, because their own brain is filling in the melody.

That's why the curse is so dangerous on a team. The people who write your runbooks, design docs, and onboarding guides are, by definition, the people who understand the system best — which makes them the worst positioned to explain it to someone who doesn't. The more of an expert you are, the louder the orchestra in your head, and the more of the song you forget to write down.

Why remote teams suffer the curse worst

In the same room, the curse has a natural brake: the listener's face. You explain something, you watch their eyes glaze over, and you back up. That feedback loop is instant and unconscious. You correct course before you even finish the sentence.

Strip out the room and the brake disappears. On a distributed team, the expert writes a document alone, with the song playing only in their head, and ships it into a wiki. The newcomer reads it alone, hours or time zones later, with no way to signal "I'm lost on line three." There's no glazed-over face to catch. The curse of knowledge in communication thrives on exactly this: one-way transmission with no return channel.

This is why knowledge transfer in remote teams is so much harder than leaders expect, and why it shows up as a real line item. Atlassian's State of Teams 2026 found that poor coordination has hardened into a "fragmentation tax that costs the Fortune 500 $161B each year." A big slice of that bill is knowledge that exists somewhere in the company but never makes it from the head that has it to the head that needs it.

The documentation trap: why more docs make it worse

Here's the orthodoxy almost every remote handbook preaches, and it's mostly right: default to async, and write everything down. GitLab, Doist, and a generation of distributed teams built real advantages on it. Good documentation scales across time zones, survives turnover, and beats a meeting most of the time.

But "write more docs" quietly assumes the docs transfer understanding. The curse says they often don't. A document written by an expert encodes the expert's blind spot. It's complete and obvious to the author — and a wall of jargon to everyone else. You don't fix that by producing more of it. You just scale the tapping.

One developer on Hacker News described the pattern perfectly: an API with "all kinds of methods for manipulating 'Fribblers,'" where the Fribbler class documentation just says "This is the primary class representing Fribblers." Technically accurate. Completely useless. The author knew what a Fribbler was, so the sentence felt like an explanation. To a newcomer, it's three knocks on a table.

The data backs up the gap between looking informed and being informed. DX, analyzing 400 companies from late 2025 into 2026, found AI tools cut time-to-productivity nearly in half — "from 91 days with no AI usage to 49 days with daily AI use." Impressive, until you read their own caveat: that milestone "does not, on its own, tell us about... the depth of understanding new hires have of the systems they're touching." Shipping faster is not the same as understanding more. You can clear the onboarding checklist and still not know why anything works.

And when surface-level material fails, people fall back on humans. In the 2025 Stack Overflow Developer Survey, the single biggest frustration with AI answers was solutions that are "almost right, but not quite" — hitting 66% of developers — and 75.3% said that when they don't trust an answer, they ask another person. The docs were there. The understanding wasn't, so they went and found a human who had it.

AI doesn't break the curse of knowledge — it scales it

The obvious 2026 response is to point an AI at your wiki and let it answer questions. It helps with search. It does not break the curse — because the curse lives in the source material, and AI faithfully inherits it.

Glean, which sells enterprise AI search, admits the ceiling directly: "Organizations with high data quality achieve factual accuracy exceeding 95%, while those with poor data quality experience accuracy levels of only 60-70%." Feed an AI documentation cursed with the expert's blind spot, and it retrieves that blind spot faster and more confidently. Garbage in, fluent garbage out.

The most striking evidence comes from AI research itself. A December 2025 paper, "Emergence: Overcoming Privileged Information Bias in Asymmetric Embodied Agents via Active Querying," names the failure mode outright as "the Privileged Information Bias (or 'Curse of Knowledge')." When a knowledgeable "Leader" agent had to guide a "Follower" that couldn't see what it saw, the Leader perceived the target in 35.0% of episodes — but the team succeeded only 17.0% of the time. Nearly half of all workable plans failed purely on communication.

The fix the researchers found is the whole point of this article. It wasn't better one-way instructions. It was a "pull-based protocol" — active querying — where the follower interrupts to ask, with successful runs featuring twice the rate of clarification requests. Even machines only beat the curse by turning a monologue into a two-way conversation.

How to overcome the curse of knowledge on a distributed team

If the curse is a transmission problem, the cure isn't more transmission — it's a return channel. Stop optimizing how you broadcast and start engineering how the other person talks back. Four shifts matter most.

Test your docs on the newest person, not the smartest one. A document isn't "done" when the author is satisfied; it's done when someone who wasn't in your head can act on it. Hand new material to your most recent hire and watch where they stall. That stall is the curse made visible. This is the difference between documentation that looks complete and onboarding that actually works.

Make the receiver play it back. The cheapest curse-breaker is having the listener restate what they understood before they go act on it. It surfaces the gap while it's still free to fix — the same logic behind the readback rule. Writing for the reader instead of yourself — leading with the conclusion, not the backstory — is the same instinct that makes an inverted-pyramid status update land.

When ambiguity is high, go live and go visual — don't write more. Some knowledge is too tangled to tap out on a table. Take an architecture decision or a gnarly bug. A five-minute live session — where the expert points at the actual diagram and the newcomer asks "wait, why that?" — transfers more than a 2,000-word doc ever will. It restores the glazed-over-face brake that async deleted. The goal isn't to replace your knowledge management system or your async handoffs — it's to grade the hard, ambiguous transfers up to a real conversation.

Capture the conversation so you only explain it once. The reason experts hoard knowledge in their heads is that re-explaining is exhausting. Record the live walkthrough, and the answer becomes a durable, searchable video knowledge base — grounding for the next person who hits the same wall, in the expert's own words and gestures.

This is the bet behind Coommit: the hardest knowledge moves when you can put a person on live video, point at a shared canvas, and let contextual AI capture the answer in one motion — instead of writing a doc nobody can decode. The expert sketches, the newcomer interrupts, and the misunderstanding dies in the room rather than three days later in production.

The curse never fully lifts

You will never stop being cursed by what you know — that's the trap, and even market incentives only dent it. The expert who built the system will always hear a song the newcomer can't. The mistake is believing you can out-document the gap. More words, written by the same cursed expert, just tap the same rhythm louder.

The teams that win the knowledge-transfer game don't write more; they close the loop. They test for the listener, ask people to play it back, and reserve their live, face-to-face minutes for the moments when a doc would only deepen the confusion. Treat the curse of knowledge as a transmission problem, build the return channel, and your remote team stops guessing at the tune — and finally hears the song.