Writing a status update people actually read
· Andrey Guenov
A status update people read has one job: convey the state of things to a skimmer. That means bottom-line-up-front (the verdict in the first line), ruthless jargon removal, a fixed skimmable structure, and writing for the person who'll spend fifteen seconds on it — not the person who'll study it. With before-and-after examples of the same update, badly and well written.
Most status updates are written as if the reader will study them. They won't. They'll skim — fifteen seconds, on a phone, between two other things — and either absorb the point or file it unread. Once you accept that the reader is a skimmer, writing a good update becomes a solvable craft problem. Here's the craft.
Rule 1: Bottom line up front
The single biggest improvement you can make is to put the conclusion in the first line. Not the last, not "after some context" — first.
Compare:
"This week the team continued work on the payments integration, completed testing on the login flow, and began scoping the reporting module. The payments work encountered some complexity around the refund edge cases…"
versus:
"On track. Payments is a week behind but has slack; everything else is on schedule."
The first makes the reader assemble the verdict from clues. The second hands it to them in four words, and then offers detail for anyone who wants it. Skimmers read the first line and stop; make that line carry the answer.
Rule 2: A fixed, skimmable shape
Readers absorb a familiar structure faster than a bespoke one. Pick a shape and reuse it every time, so the reader learns where to look:
- Status: the verdict.
- What changed: the two or three things that actually matter this period.
- What's next: where focus goes now.
- What I need from you: decisions, approvals, or nothing.
When the shape is constant, a returning reader knows the "need from you" line is always at the bottom and can jump straight to it. Novelty is the enemy of skimming.
Rule 3: Delete the jargon, every time
Your reader does not know what "PROJ-2291," "the auth refactor," or "we're blocked on the webhook" means, and making them feel that gap is a small act of exclusion that makes them read less, not more. Translate everything into the reader's world:
- "Closed 14 tickets" → "finished the account-settings screens."
- "Blocked on the webhook" → "waiting on the payment provider before we can continue."
- "PROJ-2291 moved to Done" → delete entirely; it means nothing to them.
If a detail can't be said in plain language, it probably doesn't belong in a stakeholder update at all.
Rule 4: Write for fifteen seconds
Assume the reader gives you fifteen seconds and design for that budget. Every extra sentence spends some of it. This is why length is deceptive: a long update feels thorough to you and reads as a wall to them. If something genuinely needs depth, link it or offer it on request — push the essentials, let the detail be pulled.
The test: read your update, then imagine only the first two lines survive. Do those two lines still convey whether things are okay and whether the reader needs to act? If yes, you've written for a skimmer. If not, your point is buried where a skimmer will never find it.
The before and after
Bad:
"Update: The team made good progress this week. We worked through several items in the backlog including the login flow and some of the payments work. Payments is proving a bit tricky due to edge cases around refunds and we're coordinating with the provider. We also started looking at reporting. Next week we'll continue payments and hopefully wrap up the provider coordination. Let me know if you have questions."
Good:
On track. Login is done. Payments is about a week behind — refund edge cases turned out to be fiddly — but it has slack, so the launch date holds. Next: finish payments, start the reporting screens. From you: nothing this week.
Same information. The second respects the reader's fifteen seconds, answers "are we okay?" in the first word, and tells them there's nothing to do. That's an update someone actually reads — and, not coincidentally, one that makes you look more in command of the project, not less.
You don't need a tool for this. You need to write for the skimmer you actually have, lead with the verdict, cut the jargon, and keep the shape the same every time. Do that and your updates stop being filed and start being read.
I'm Andrey. I write about communicating clearly with the non-technical people who depend on technical work.
FAQ
- How do I write a good project status update?
- Lead with the bottom line — the overall status — in the very first line, before any detail. Then keep a fixed, skimmable structure (status, what changed, what's next, what you need), strip out jargon and ticket references, and write for someone who'll skim it in fifteen seconds. The update's job is to be absorbed quickly, not to document everything.
- What does BLUF mean in a status update?
- BLUF stands for 'bottom line up front' — you state the conclusion first and the supporting detail after, rather than building up to it. In a status update it means opening with the verdict ('On track') instead of making the reader work through a list of activities to infer how things are going.
- How long should a status update be?
- Short enough to skim in about fifteen seconds and understand the essentials. If the reader needs more, they can ask or follow a link. Length signals importance to you but creates work for the reader, so default to brief and let detail be pulled rather than pushed.