i

Description

Les mains d'un pianiste posées sur les touches d'un piano, en noir et blanc.

Source

Jamille Queiroz · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

The Curse of Knowledge

What seems obvious to us is only obvious because we already know it, and we forget what it was like not to know.

In short

• What: people who know overestimate what others know and underestimate the effort required to understand.
• Why: once knowledge is acquired, it can no longer be “unlearned” to simulate ignorance.
• Detect: “it's obvious,” acronyms never defined, documentation only its authors understand.
• Avoid: have a novice review it, watch someone try, explain step by step, measure rather than assume.

On this page

1. Definition
2. The mechanism
3. The “tappers” and “listeners” experiment
4. Where we encounter it
   1. In project management
   2. In management
5. Famous cases
   1. The Stanford tappers 1990
   2. When the expert predicts the novice's time 1999
   3. Markets where you can no longer “forget” 1989
6. Detection signals
7. Avoidance reflexes
8. With AI: detect, fix, mitigate
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to integrate into your workflow
   5. How to integrate them
   6. Precautions
9. Limits
10. Sources and verification
11. See also
    1. Combines with, or reinforces
    2. Related biases
    3. Counterweights and related reflexes

Definition#

Fictitious illustration

Fictitious illustration

The curse of knowledge (curse of knowledge) is the difficulty an informed person has reasoning from the point of view of someone who is not informed. As soon as we know something, we find it simple, assume others know it too, and forget the steps that were needed to get there.

The expression was popularized in economics by Colin Camerer, George Loewenstein, and Martin Weber (1989): in a market experiment, agents informed about a company's future results were unable to ignore that information to guess what uninformed agents would estimate. In developmental and cognitive psychology, the same phenomenon appears in adults (Birch and Bloom, 2007). It is close to the illusion of transparency, but it concerns knowledge rather than emotions.

It is neither bad faith nor arrogance: it is a mechanical effect, and it hits harder the more competent you are.

The mechanism#

• Knowledge cannot be put on pause. To imagine a novice's state of mind, we start from our own and try to correct it. As with anchoring, the correction is insufficient.
• Knowledge becomes invisible. The older and more automated a skill is, the less we remember it was learned: experts “compress” steps (chunking) and no longer see what used to be hard.
• We judge difficulty from the outside based on the outcome. A reader looking at a document they already understand finds it clear; they might have found it obscure before.
• Feedback signals are missing. People who do not understand do not always dare say so, especially in front of an expert or a superior; the expert takes silence as understanding.

The “tappers” and “listeners” experiment#

Where we encounter it#

In project management#

• Documentation and README: “run the build script” without saying where, with which version, or with which permissions. The author has done these steps a hundred times and no longer sees them.
• Onboarding: the veteran explains the architecture in twenty minutes, with internal acronyms, then concludes “any questions?” The newcomer manages to say “no” out of embarrassment.
• Specifications and tickets: “handle the usual case,” “as usual.” The developer discovering the topic has to guess what “usual” means.
• Error messages and interfaces: “Error 4021” speaks to the team that wrote the code, not to the user.
• Estimation: the expert estimates how long a novice will need to learn a tool based on their own time. Hinds (1999) observed that experts underestimated the time novices needed to use a device, and that their confidence in their predictions was high.
• Code review: the reviewer who knows the module finds the code “readable”; the next one, who does not know it, spends a whole day on it.

In management#

• Instructions and delegation: “can you handle this?”, without context, success criteria, or deadline, because all that is obvious to the manager.
• Feedback: “be more strategic,” “more leadership”: the manager knows what they mean, the employee does not know what to change.
• Training and support: an expert who became a trainer skips steps; trainees nod and tune out.
• Change announcements: leadership has spent months thinking through the reorganization; it is announced in ten minutes as if the reasoning were self-evident.
• Handover: the person leaving writes a three-line note about a role they know by heart.

Famous cases#

Detection signals#

• The words “obvious,” “trivial,” “of course,” “as everyone knows.”
• Documentation that only its authors understand, or that no one dares criticize.
• Acronyms, code names, and internal abbreviations that are never defined.
• New hires always ask the same questions, or ask none at all.
• “But we explained it!” after a misunderstanding.
• Onboarding announced as one week that ends up taking two months.

Avoidance reflexes#

1. Have a novice review it. A document is finished only when someone unfamiliar with the topic can use it on their own. Watch them without helping.
2. Test instead of asking “is that clear?” Ask them to rephrase, repeat the step, or say what they would do first. A “yes” proves nothing.
3. Define before using. Every acronym is defined on first use; include a glossary and an overall diagram at the start of the document.
4. Explain the why, not just the what. Context, objective, and success criteria provide what the expert thinks is obvious.
5. Give one complete example. One concrete end-to-end case, with values, is worth ten abstract paragraphs.
6. Track new people's questions. Every beginner question is a gap in the documentation; fix it the same day.
7. Scale up your training estimates. For ramp-up time, start from observed time on recent arrivals.

With AI: detect, fix, mitigate#

Prompts to integrate into your workflow#

1. Novice reviewer. Run on a document before sharing it (without confidential data).

You are [a junior developer / a new project manager / a non-technical client] discovering this topic. You have no context outside the text below.
1. List all terms, acronyms, and references you don't understand.
2. Point out every place where you're missing a step, a prerequisite, or an example to succeed on your own.
3. Write the first ten questions you would ask the author.
4. Don't fill in gaps: if information is missing, say so rather than guessing.

Text: [document]

2. Context-free comprehension test. To verify that a text stands on its own.

Here is a procedure. Using only what is written in the text, answer the questions below. For each question, indicate whether the answer appears in the text (quote the passage) or does not appear there.
Questions: [for example: what do you do first? with what permissions? what should you do if step 3 fails? how do you know it's finished?]

Text: [procedure]

How to integrate them#

• When writing: prompt 1 serves as a first review, even before asking a colleague.
• Before sharing: prompt 2 checks that the document is self-contained.
• At the end: a real novice should still review it; AI doesn't replace a human reader, it comes before one.

Precautions#

• Don't paste documents containing personal data, secrets, or client information into an unauthorized tool.
• Specify the audience level: without that, AI assumes an average reader and misses gaps.
• AI readily fills blanks with plausible assumptions: explicitly ask it to flag what's missing rather than guess it.
• It has its own form of “curse”: its explanations use expert vocabulary unless you constrain it.

Limits#

• The effect is well established, but its magnitude varies by task; correction strategies (“imagine you don't know”) have modest effectiveness, which argues for external mechanisms (review, test) rather than goodwill.
• The tappers story is a dissertation result, shared mainly through popularization books: the order of magnitude is solid, but the details of the conditions are less well documented than in a published article.
• Simplifying is not dumbing down: an expert audience appreciates a dense document. The goal is to adapt to the real audience, not explain everything to everyone.

Sources and verification#

• Camerer, Loewenstein & Weber (1989), “The Curse of Knowledge in Economic Settings: An Experimental Analysis”, Journal of Political Economy, 97(5)
• Birch & Bloom (2007), “The Curse of Knowledge in Reasoning About False Beliefs”, Psychological Science, 18(5)
• Hinds (1999), “The curse of expertise: The effects of expertise and debiasing methods on prediction of novice performance”, Journal of Experimental Psychology: Applied, 5(2)
• Newton, E. L. (1990), doctoral dissertation, Stanford University (title cited in several forms depending on the source, including The Rocky Road from Actions to Intentions, and also in the Heath brothers' book) — the tappers experiment.
• Heath, C. & Heath, D. (2007), Made to Stick: Why Some Ideas Survive and Others Die, Random House — account of Newton's experiment (3 tunes recognized out of 120).
• Pinker, S. (2014), The Sense of Style, Viking — the curse of knowledge as the main cause of opaque writing.

See also#