Curse of Knowledge
Once you know something, it is hard to imagine not knowing it, so experts explain too little, too abstractly.
To an executive
People who know a subject well badly overestimate how much others understand. Messages that feel clear to the sender often land poorly, so test them on someone new.
To an engineer
Write documents and decision records for a reader who was not there. Use examples and plain words, and get a newcomer to read them before you publish.
The idea
Economists Colin Camerer, George Loewenstein and Martin Weber named the curse of knowledge in 1989: better-informed people find it hard to reason as if they knew less. Chip and Dan Heath made it famous with a Stanford experiment by Elizabeth Newton.
In 1990, Newton asked people to tap out the rhythm of well-known songs while listeners guessed the tune. Tappers predicted listeners would get about half. They got roughly one in forty. The tappers could hear the melody in their heads; the listeners heard only knocks on a table.
Architects are tappers. After months on a design, its terms, constraints and reasons feel obvious — to them.
Why it works
It explains why clear experts aren't clear. The problem isn't effort or intelligence; it's that you can't unknow what you know.
It points to concrete fixes. Since you can't imagine the listener's state reliably, you test instead: examples, plain words, and feedback from someone new.
Where it applies
- Architecture documents and ADRs, read months later by people who weren't there.
- Presentations to the business, where every acronym is a lost listener.
- Onboarding, where the newest person sees what everyone else stopped seeing.
How to apply
- Lead with a concrete example before the abstract principle.
- Strip out jargon and acronyms, or define them the first time.
- Explain why before how — the reasons are what experts forget to say.
- Test on a newcomer: ask them to explain it back, and fix what they miss.
Example scenario
A platform team's design doc for "multi-tenant isolation via cell-based routing" got polite nods and no adoption. A new joiner admitted she hadn't understood the first page.
The team rewrote the opening around one example: "If one customer floods us, only the customers in their cell slow down — today everyone does." Adoption conversations started the same week.
Questions to ask
- What would this mean to someone who wasn't in the design sessions?
- Which acronyms and terms here would a newcomer need explained?
- Can I give a concrete example instead of the abstract principle?
When not to use it
- Expert-to-expert detail, such as a component design reviewed by its own team, where shared context is real and shorthand saves time.
How it misleads you
Overcorrecting leads to talking down to people. The aim is not to explain everything from scratch, but to check what your audience already knows — ask, rather than assume either way.
Further reading
Last reviewed · Suggest an improvement