The Curse of Knowledge: Why Expert-Written Documents Don't Land for Newcomers, and What to Do About It

• Intended readers: Technical writers, documentation owners, and engineering leads facing the situation where “an expert wrote it but new hires can’t follow it”
• Assumed background: A working understanding of Pattern I in “Building Your Organization’s Context Supply Capability: An Implementation Guide”
• Reading time: Full read about 13 minutes / skim about 4 minutes

Overview

Documents written by your “compensating individuals” don’t make sense to a new hire. Too many premises are skipped, terms aren’t defined, there are no diagrams. This isn’t a personal writing-skill problem — it’s a structural bias.

Camerer, Loewenstein, and Weber’s 1989 Journal of Political Economy paper¹ reported the curse of knowledge: the cognitive bias that, once you know something, you can no longer imagine the state of someone who doesn’t. Documents written by experts almost always carry this bias.

This article expands Pattern I from “Building Your Organization’s Context Supply Capability: An Implementation Guide” into a standalone deep dive. The focus is on document design that assumes the bias exists — mandatory pair documentation, new-hire reviewers, audience and prerequisite fields, and a glossary.

Symptoms: expert documents that don’t land

Typical symptoms:

• New hires can’t execute a procedure even after reading the expert-authored runbook
• Terms aren’t defined (“aggregation,” “reconcile,” “roll-forward” appear without definitions)
• Required prior setup is missing (the writer assumed it)
• No diagrams — complex structures are explained in prose only
• Error handling is missing (the writer never hit it)
• Logical leaps: “X, therefore Y,” skipping intermediate reasoning
• No references to related documents (the writer remembers them)

These aren’t writer skill problems — they are cognitive bias. The higher the writer’s expertise, the more pronounced the symptoms.

Mechanism: the curse of knowledge

The original source: Camerer et al. 1989

The 1989 study by Camerer, Loewenstein, and Weber¹ showed in an economics setting that participants holding information systematically over-predict how well uninformed others will judge — a cognitive distortion of the form “if I know it, surely they have similar understanding.”

Heath & Heath’s Made to Stick

Chip and Dan Heath’s Made to Stick² popularized the curse of knowledge for general readers. The book features Elizabeth Newton’s famous experiment (her 1990 Stanford dissertation): tappers tap out the rhythm of a song, and listeners try to identify it. Tappers predict 50% accuracy; the actual rate is 2.5%.

The tapper hears the full song (melody, lyrics) inside their own head and assumes the listener hears the same. The listener only has a series of taps. That gap is the essence of the curse of knowledge.

Experts have it worst

The deeper your expertise:

• The more your knowledge feels like “common sense”
• The harder it gets to imagine the state of someone who doesn’t have it
• The more you decide “this doesn’t need to be written”
• The more terms you use without defining them
• The more steps you skip in your reasoning chain

The result is documents that don’t land for new hires. The higher the writer’s capability, the more pronounced the symptoms.

“Use simpler language” is a misread of the problem

“If you write in plain language, it’ll get through” is a misread. The problem is not word difficulty — it is omitted premises. Even prose written in simple words won’t reach a newcomer if implicit premises (background knowledge, prior steps, related context) are skipped.

Directions for the fix

1. Make pair documentation mandatory

Separate the writer from the questioner — pair documentation:

• Writer: the holder of the specialist knowledge
• Questioner: someone who doesn’t know the area, or is still learning it
• The questioner keeps asking “what does this mean?” “why is this needed?” “what happens next?”
• The writer answers; the questioner writes those answers down
• After a draft is complete, the writer reviews

This is the same approach as Stripe’s documentation culture³ and the “interview-based documentation” lineage in technical writing. Distributing the writing responsibility mitigates the curse.

2. Appoint new hires as document reviewers

Make recently joined people document reviewers:

• Their job: flag “what I don’t understand” and “where the premises are missing”
• Precisely because they’re new, they aren’t under the curse
• Feed the review back into document improvement
• New hires also benefit — understanding organizational knowledge in depth becomes part of onboarding

This can be built into onboarding itself. Build a norm that says “thank you for flagging what’s unclear.”

3. Make audience and prerequisites explicit

Build them into the document template as required fields:

## Audience
- e.g., 2+ years of engineering experience, basic SQL, first time touching this system

## Prerequisites
- Basic concepts of xx
- Hands-on experience with yy
- Read the zz document first

## Glossary
- A: ...
- B: ...

This is especially important in Diátaxis-framework⁴ Tutorials and How-to documents. Forcing an explicit audience also makes the writer ask “would this person actually follow this?”

4. Auto-link domain terms to a glossary

Operationalize automatic linking from documents to a glossary:

• Link specialized terms to the glossary on first appearance
• Centralize the glossary into one source for the organization
• Anyone can add or update terms
• When you use a term, check the glossary out of habit

That way, even if a writer drops a term assuming it’s understood, the reader can verify the definition after the fact.

5. Cognitive training for writers

Provide training on the writing side too:

• A workshop where writers experience “this doesn’t land for newcomers”
• Demo the Heath & Heath tapper experiment
• Have new hires read the writer’s past documents and flag what’s unclear
• 1-on-1s focused on the writer’s recurring curse patterns

The first step is dismantling the conviction “I write clearly.”

Anti-patterns

Pattern	What happens	Fix
“An expert wrote it, so we’re good”	The curse leaves it unreadable for newcomers	Mandatory pair documentation
“The reader is at fault (didn’t study enough)”	An endless stream of impenetrable docs	Recognize the writer-side bias
“Writing training will solve it”	Treats it as individual skill, ignores structure	Structural design (pair, new-hire review)
“Plain language solves it”	The problem is omitted premises, not vocabulary	Make audience and prerequisites explicit
Hire a technical writer to fix it	The curse re-emerges in the writer’s dialogue with the expert	Use the technical writer as the questioner role

Summary

• The curse of knowledge: once you know something, you can no longer imagine the state of someone who doesn’t
• Camerer et al. 1989 demonstrated it in an economics setting; Heath & Heath generalized it
• Higher expertise → more pronounced symptoms. It’s structural bias, not lack of skill
• “Plain language” is not the answer — the problem is omitted premises
• Fixes: mandatory pair documentation / new hires as reviewers / explicit audience and prerequisites / auto-linking to a glossary / cognitive training for writers

Related articles

• Building Your Organization’s Context Supply Capability: An Implementation Guide — Parent article
• The Tacit Knowledge Holder’s Status Anxiety — Pair documentation design (connects with the status-anxiety treatment)
• Documentation Theater — Dead documents and the curse
• ADR / Pitch / Kickoff Memo Implementation Guide — Diátaxis and document design

References

1. The Curse of Knowledge in Economic Settings: An Experimental Analysis — Colin Camerer, George Loewenstein, Martin Weber, Journal of Political Economy, vol. 97, no. 5 (1989). DOI: 10.1086/261651. [Reliability: High] ↩︎ ↩︎²

2. Made to Stick: Why Some Ideas Survive and Others Die — Chip Heath, Dan Heath, Random House (2007). ISBN: 9781400064281. Generalizes the curse via the tapper experiment. [Reliability: Medium-High] ↩︎

3. From kickoffs to retros and Slack channels — Stripe’s documentation best practices with Brie Wolfson — First Round Review (2023). [Reliability: High] ↩︎

4. Diátaxis: A systematic framework for technical documentation authoring — Daniele Procida (continuously updated). The four-way classification of Tutorial / How-to / Reference / Explanation. [Reliability: Medium-High] ↩︎