Writing updates people can use

Most internal updates are written for the writer, not the reader.

They describe what was done, in the order it was done, with the level of detail the writer is closest to. The reader has to sort through it, extract the parts that matter to them, and infer what is being asked of them. By the time they have done that work, they have read the update more carefully than the writer wrote it.

A useful update respects the reader’s time by doing that sorting in advance.

State the headline first. If someone reads only the first sentence, they should still come away with the most important thing. “We shipped the feature on Friday.” “We are blocked on legal review.” “We are on track for next Tuesday.” Context and detail come after. The headline is what the update is for.

Separate status, decisions, and asks. A reader should be able to see at a glance: what is happening, what has been decided, what is needed from them. Mixing those three together into one narrative is how asks get missed.

Name what changed, not just what happened. Readers are already aware that work is ongoing. What they need is the delta: what is different since the last update, what decisions were made, what new risks have appeared.

End with the next step. Even if the next step is “no action needed from anyone,” say so. An update that does not tell the reader what to do with the information is not a finished update.

Good updates are boring to write. They are also the spine of any team that does not spend half its time in recovery meetings.