Guides / Guide

Writing change communications that survive being read by the people affected

By Michael Shreeves · 9 May 2026 · Transformation & Change · 5 min read

Background

Most change communications fail for a structural reason, not a tone one. They're written in the order the project team thinks about the change - why we're doing this, what the new process looks like, when it goes live - and that order buries the one question every reader actually has first: what does this mean for me, specifically, on Monday. By the time the draft gets there, if it gets there at all, the reader has already decided the message is corporate spin and stopped reading closely.

Asking an AI tool to "make this announcement more positive" makes the problem worse, not better - it's the same order with softer adjectives, which reads as more spin, not less. The actual fix is asking it to reorder around the reader's real question first, and then hold itself to a hard rule: no claim in the message that isn't backed by something specific enough to be checked later.

Setup

The shape that produces comms people actually trust:

  • Role - someone writing to be believed, not to sound reassuring.
  • Context - the real detail of what's changing, including the parts that are still genuinely unresolved.
  • Inputs - who's affected, what changes for them specifically, and what genuinely hasn't been decided yet.
  • Task - reorder around "what does this mean for me" before "why are we doing this".
  • Constraints - no vague reassurance standing in for a fact you don't have yet.

The first announcement

You're drafting the first communication about an operational change to the
people it affects - not to leadership, not a press release.

Context: return a message that leads with what changes for the reader,
specifically, before it explains why the change is happening. Plain
language throughout - no "exciting journey", no "transformation", no
"we're on a mission".

Inputs:
- What's changing: [DESCRIBE THE ACTUAL CHANGE]
- Who's reading this and what changes for them specifically:
  [ROLE/TEAM -> WHAT'S DIFFERENT FOR THEM]
- When it takes effect: [DATE]
- What genuinely hasn't been decided yet: [LIST HONESTLY - DON'T SKIP THIS]
- Why it's happening, in one paragraph: [THE REAL REASON, NOT THE PR
  VERSION]

Task: open with what changes for the reader and when. Then the reason,
briefly. Then what's still unresolved, stated as unresolved rather than
implied to be settled. Close with where to actually ask a question and get
a real answer, not a generic "reach out if you have concerns".

Constraints: nothing in the message may claim something is decided if the
inputs say it isn't. Flag any input you were given that reads like a
euphemism ("streamlining", "right-sizing") and suggest the plainer word
instead.

The FAQ that answers the question people are actually asking

The questions a project team anticipates and the questions people actually ask are rarely the same list. Build the FAQ from what will really be asked, not from what's comfortable to answer.

You're building an FAQ for a change announcement, anticipating the
uncomfortable questions, not just the tidy ones.

Context: I'll give you the announcement and the audience. Generate the
questions a sceptical reader in that audience would actually ask, then
answer them honestly - including "we don't know yet" as a valid answer
where it's true.

Inputs:
- The announcement: [PASTE THE DRAFT ABOVE]
- Audience and what they stand to lose or gain: [DESCRIBE]
- Facts you have and don't have yet: [LIST BOTH]

Task: generate 8-10 questions ranked by how likely and how uncomfortable
they are, most pressing first (job security, workload, timeline, who
decided this). Answer each with the actual facts you were given. Where the
honest answer is "not decided yet", write that plainly rather than
padding it with reassurance that isn't backed by a fact.

Constraints: never invent a reassurance not supported by the inputs (e.g.
"no roles will be affected") unless that's genuinely true and given to
you as a fact. If a likely question has no honest answer available yet,
say so and flag it as something to resolve before this goes out, not
something to word around.

Checking a draft for spin before it goes out

Before anything goes out, run it back through as a sceptical reader rather than the author.

You're reading this change announcement as a sceptical member of the
audience, not as the person who wrote it.

Context: I'll paste a draft. Flag anything that would make you distrust
it if you were on the receiving end.

Inputs:
- Draft: [PASTE]
- What you know to be true that isn't in the draft: [LIST ANYTHING
  MISSING OR SOFTENED]

Task: flag every vague reassurance not backed by a specific fact ("this
will make things better for everyone"), every euphemism standing in for a
plainer word, and any place the order buries what happens to the reader
under context they don't need yet. Rewrite each flagged sentence plainly.

Constraints: don't soften your own critique - the point of this pass is
to catch what a genuinely sceptical reader would catch, not to confirm the
draft is fine.

Edge Cases & BCP

  • "We don't know yet" is a legitimate, trust-building answer - don't let a review pass talk you out of it. A reviewer or the model itself will often suggest filling that gap with something more confident-sounding. Resist it; a wrong confident answer costs more credibility later than an honest gap costs now.
  • The model will smooth a genuinely hard message into something gentler than the facts support, because that's what "sounds better" in isolation. If the real news is bad for some readers, a version that reads as reassuring to everyone is probably no longer accurate for the people it's actually bad for. Check the redraft against the facts, not against how it feels to read.
  • A message tested only on the steering group will pass every time, because the steering group already has the context that makes it read as fine. Test the FAQ questions on someone who genuinely wasn't in the room, or as close to that as you can manage, before it goes wide.
  • Timing beats wording. The best-written message, sent an hour after people heard the news secondhand from a colleague, reads as damage control regardless of what it says. Get the sequencing of who hears it first agreed before spending more time on the copy.

← All guides