Key Takeaways — Chapter 2: Audience

The summary card. Read this to re-ground before the next chapter or before a writing task.

The one idea

There is no "good writing" in the abstract — only writing that is good for a specific reader, doing a specific task, in a specific amount of time. Quality is a relationship between a text and a reader, not a property of the text. Once you see this, you stop asking "is this good?" and start asking "is this good for this reader, doing this thing?" That instinct is the whole chapter.

The framework: K-R-A-C

Before you write a word, answer four questions:

Question It forces this decision
K — Knowledge What do they already know? (domain, jargon, context — three separate dials) Which terms to keep, define, or replace
R — Role/goal Who are they, and why are they reading? What to put first
A — Action "After reading, they will ____." (an action, not a vibe) What to include and what to cut
C — Context Skim or study? Screen or print? Friendly or hostile? Now or later? The form: headings, length, tone, findability

One finding → four documents

The same technical result becomes four genuinely different documents. The facts stay constant; the framing, order, vocabulary, and depth change with the reader.

Reader Lead with Jargon
Expert / peer Method and result Full — it's precision
Manager / decider The recommendation + the one key number Almost none
Client The finding + what it means for them Minimal, reassuring, forwardable
General public A hook or analogy A term or two, max

If your four versions share most of their sentences, you adapted vocabulary but not what each one leads with — that's the deeper skill.

The curse of knowledge

Once you understand something, you can't easily imagine not understanding it (Newton's tappers predicted ~50% success; listeners got ~2.5%). It hits experts hardest and operates below awareness, so defeat it with mechanics, not willpower: (1) name the jargon — list every term, mark each keep/define/replace; (2) define on first use — one parenthetical rescues the novice and the expert's eye skips it; (3) the smart-friend test — what would you skip explaining out loud to a sharp non-specialist?; (4) test on a real non-expert — watch where they slow down.

Purpose: pick one of four (don't default to "inform")

  • Inform ("what is the case?") → lead with the key fact. Reference, status report.
  • Persuade ("what should I do?") → lead with the recommendation. Proposal, recommendation memo.
  • Instruct ("how do I do this?") → lead with the goal, then step 1. Tutorial, SOP.
  • Record ("what happened / why?") → complete and traceable. Minutes, incident log, ADR.

The classic failure — the Challenger mistake — is writing an inform document when the situation demanded persuade: the engineers were right about the cold-weather O-ring risk but delivered peer-level documentation when the deciders needed one unmissable, decision-ready conclusion. Being right is not enough.

If you remember three things

  1. Answer who, and to do what, before you write anything.
  2. The finding is not the document — one result, different readers, different documents.
  3. You can't feel the curse of knowledge, so use the tactics every time.