Provide context when communicating

You already know what you mean. That's the problem.

In 1990, a Stanford graduate student named Elizabeth Newton designed an experiment so simple it became one of the most cited studies in communication research. She assigned people to one of two roles: tappers or listeners. Tappers received a well-known song — "Happy Birthday," "The Star-Spangled Banner" — and tapped out the rhythm on a table. Listeners tried to guess the song.

Before the results came in, tappers predicted listeners would identify the song about 50 percent of the time.

The actual success rate was 2.5 percent. Three out of 120.

The tappers couldn't believe it. How could anyone fail to hear "Happy Birthday" from such an obvious rhythm? The answer is that tappers were hearing the full song in their heads — lyrics, melody, orchestration — while they tapped. Listeners heard only isolated knocks on a table. The tappers had context the listeners did not, and they could not imagine what the experience was like without it.

This is not a quirk of musical rhythm. This is how you communicate every day. You send messages with a full orchestra playing in your head — the project history, the failed approaches, the political dynamics, the thing someone said in the hallway yesterday — and your audience hears only the taps.

The curse of knowledge is the default

Economists Colin Camerer, George Loewenstein, and Martin Weber coined the term "curse of knowledge" in their 1989 paper in the Journal of Political Economy. Their finding: once you know something, you cannot accurately reconstruct what it was like not to know it. Better-informed people systematically fail to predict the judgments of less-informed people — even when they have financial incentives to do so.

The curse operates constantly and invisibly. When you write a project update, you know which parts are new information and which are background. Your reader does not. When you present a recommendation, you have spent three weeks arriving at it. Your audience has spent three seconds reading the first sentence. When you write documentation, you understand the system. Your reader is encountering it for the first time.

The curse explains why expert communicators are often worse at providing context than beginners. The more you know about a subject, the harder it becomes to reconstruct the experience of not knowing. A senior engineer explaining a system she built will routinely skip three layers of context that a junior engineer needs to even understand the question being asked — not because she is careless, but because the knowledge has become so internalized she literally cannot see what she is omitting.

Common ground is not automatic — it must be built

Linguist Herbert Clark and psychologist Susan Brennan published a landmark paper in 1991 on what they called "grounding in communication." Their core argument: successful communication requires building and maintaining common ground — the shared mutual knowledge, beliefs, and assumptions between speaker and listener.

Common ground is not a given. It must be actively constructed. Clark and Brennan showed that communicators are constantly engaged in a coordination process — checking understanding, seeking confirmation, repairing misunderstandings — to maintain the illusion that communication is seamless. When this grounding process fails, the communication fails, regardless of how clear the content itself was.

This has a direct implication for context provision. Every time you communicate, you must ask: what is the common ground between me and my audience? Not what you think it is. Not what you hope it is. What you can actually verify.

The gap between your knowledge and your audience's knowledge is the space where context must live. If you leave that space empty, the audience fills it with assumptions — their own context, not yours. And their assumptions will be wrong in ways you cannot predict.

Context before content: the Minto structure

Barbara Minto, a former McKinsey consultant, built the most influential framework for business communication around a single insight: readers cannot evaluate your conclusion until they understand your context.

Her SCQA framework — Situation, Complication, Question, Answer — forces communicators to establish shared ground before presenting content:

• Situation: What the reader already knows and agrees with (establishing common ground)
• Complication: What changed, what went wrong, or what created a need (introducing new context)
• Question: The specific question this raises (focusing attention)
• Answer: Your recommendation or conclusion (the actual content)

Most people communicate backwards. They lead with the answer — "We should migrate to Postgres" — and let the audience figure out the situation, complication, and question on their own. Minto's framework says this is structurally wrong. Not stylistically wrong. Structurally wrong. The audience cannot interpret your answer without first understanding the context that produced it.

Minto's observation is deeper than it appears. She found that "people tend to be receptive to new ideas they might disagree with if you first provide them with a familiar context." Context does not just enable comprehension. It enables receptivity. A recommendation without context feels arbitrary. The same recommendation with context feels inevitable.

Why the best documentation captures "why," not just "what"

Software engineering has learned this lesson the hard way. The industry created Architectural Decision Records (ADRs) specifically because teams kept producing documentation that answered "what" without answering "why" — and the documentation became useless within months.

An ADR captures not just a decision but the context surrounding it: what alternatives were considered, what constraints existed, what trade-offs were made, and what consequences were expected. The reason is articulated by a principle from software architecture: "why" is more important than "how."

The distinction matters because "what" documentation decays. A description of how a system works today will be wrong tomorrow. But the context behind a decision — why this approach was chosen over alternatives, what constraints made it necessary — remains useful even after the system changes. It tells the next person not just what to maintain, but what matters.

This applies far beyond engineering. Any communication that omits the "why" forces the recipient to either guess at your reasoning or follow your instructions blindly. Both lead to poor outcomes. Context is what turns an instruction into understanding.

The best knowledge-transfer practices distinguish between three types of knowledge: explicit (documented procedures), implicit (undocumented workflows that can be articulated when asked), and tacit (experiential insight that is difficult to express at all). Most communication attempts to transfer only explicit knowledge. But the context — the implicit and tacit layers — is where the real understanding lives. Providing context means surfacing the implicit: the assumptions, the history, the "why we do it this way" that turns a procedure into competence.

The cognitive load of missing context

Reader-centered writing research provides the mechanism for why missing context is so damaging. When a reader encounters a message without sufficient context, they must simultaneously hold the content in working memory while constructing the missing context from their own knowledge. This doubles the cognitive load.

Research on working memory and audience awareness shows that high-capacity writers — those who can hold more in mind while composing — naturally produce more reader support and context. They anticipate gaps because they have the cognitive bandwidth to model their reader's experience. Low-capacity writers produce leaner, more self-referential messages — not because they intend to omit context, but because they lack the capacity to track what the reader needs while simultaneously formulating their own thoughts.

This means providing context is not just a communication skill. It is a cognitive skill. It requires the ability to hold your own perspective and your reader's perspective simultaneously — and to identify the gaps between them. If you are rushing, stressed, or cognitively depleted, you will provide less context. This is predictable and preventable, but only if you build a systematic habit rather than relying on moment-to-moment awareness.

AI proves the rule: context determines output quality

The rise of AI interaction has made the context principle undeniable. When you prompt an AI system, the quality of output is almost entirely determined by the quality of context you provide. A vague prompt produces vague output. A prompt with clear context — the goal, the constraints, the audience, the format, the relevant background — produces output that is often indistinguishable from expert work.

The AI industry has formalized this. What began as "prompt engineering" — crafting individual instructions — has evolved into what Shopify CEO Tobi Lutke calls "context engineering": the art of providing all the context necessary for a task to be plausibly solvable. Technologist Simon Willison crystallized the distinction: "Context engineering is what we do instead of fine-tuning."

The parallel to human communication is exact. When you communicate with a person, you are prompting a biological neural network that, like an AI model, can only work with the context it has access to. If you provide rich, relevant context, the person can interpret your message correctly, ask good follow-up questions, and take aligned action. If you omit context, the person fills the gap with their own priors — and their response will reflect their context, not yours.

Research on structured prompting shows that proper context provision reduces AI errors by up to 76 percent. The same principle applies to human communication. The percentage may vary, but the direction is absolute: more relevant context produces fewer misunderstandings.

This is not a metaphor. It is the same cognitive operation. Whether your audience is a human or a machine, you are providing a context window from which they must reason. The quality of the reasoning cannot exceed the quality of the context.

The five layers of context

Not all context is equal. Here is a hierarchy, ordered from most commonly omitted to most commonly provided:

1. Intent — Why you are communicating at all. What action, understanding, or decision you want from the audience. This is omitted more than any other layer. People state conclusions without stating the purpose of the communication.

2. Background — What happened before this moment. The history, the previous decisions, the failed approaches, the constraints. Without this, the audience cannot distinguish between a first attempt and a last resort.

3. Scope — What is and is not included. What you are proposing versus what you are not proposing. The "We should switch to Postgres" example fails because scope is missing. Switch what? When? All of it?

4. Audience fit — Adjusting the level of detail, terminology, and emphasis for the specific person receiving the message. A message to your technical cofounder and a message to your board require different context, even when the content is identical.

5. Emotional context — The stakes, the urgency, the tone. "We should discuss the Q3 numbers" means something different when the quarter was good than when the quarter was bad. If you know the emotional context and your audience does not, you must bridge that gap or they will fill it with anxiety.

What this makes possible

When you systematically provide context, several things change:

Decisions improve. When people understand not just your recommendation but the context that produced it, they can evaluate whether the reasoning still holds when conditions change. A team that understands why you chose Postgres can independently recognize when that reasoning no longer applies. A team that only knows what you chose will follow the decision blindly or reject it reflexively.

Alignment happens faster. Most disagreements in organizations are not disagreements about conclusions. They are disagreements about context — different people holding different information, different assumptions, different mental models of the problem. Providing context collapses these false disagreements before they become real conflicts.

Your thinking sharpens. The act of articulating context forces you to examine your own reasoning. When you write down the situation, complication, and question that led to your answer, you will sometimes discover that your answer does not follow from your own context. This is not a failure of context provision. It is context provision working as a thinking tool — the same generation effect described in earlier lessons.

AI amplifies your work. When your context provision skills are strong, every AI interaction becomes more productive. You naturally structure prompts with intent, background, scope, and constraints — because that is how you communicate with humans. The skill transfers directly.

The protocol

1. Before writing, list your assumptions. What do you know that the reader might not? What decisions led to this point? What constraints exist? Write these down before you write the message itself.

2. Apply the SCQA test. For any communication longer than two sentences: Can the reader identify the Situation, the Complication, the Question being addressed, and the Answer? If any layer is missing, add it.

3. Use the "cold reader" check. Reread your message as someone who has no project context, no conversation history, and no knowledge of your intent. Every sentence that requires insider knowledge to interpret correctly is a sentence that needs context added.

4. Scale context to stakes. A quick Slack reply might need one sentence of context. A strategy document needs a full SCQA introduction. A high-stakes email needs all five layers — intent, background, scope, audience fit, and emotional context. Match the context investment to the consequence of being misunderstood.

5. When in doubt, over-provide. The cost of too much context is a few seconds of reading. The cost of too little context is a meeting that didn't need to happen, a decision made on wrong assumptions, or a relationship damaged by misinterpretation. The asymmetry always favors more context, not less.

The curse of knowledge will never fully lift. You will always struggle to imagine what it is like not to know what you know. But you can build a systematic practice that compensates for the curse — checking for gaps, providing layers, testing with cold readers. The goal is not to eliminate the bias. The goal is to build a protocol that catches it before it reaches your audience.