How to Write a Status Update Nobody Skips

The test is whether anyone responds. An update that produces no reaction was either unnecessary or unread, and both are worth knowing.

Quick answer: A status update gets read when it opens with a clear position — on track, at risk or off track — states what changed since last time, names what is blocked and who can unblock it, and ends with a specific ask. Updates get ignored when they list activity rather than consequence, and when the same document goes to everyone regardless of what they need.

Why Status Updates Get Ignored

Updates fail because they report activity rather than what it means, because they are structured for the writer's convenience, and because one version goes to audiences with different needs.

They report activity, not consequence

"Completed the data migration, held three workshops, drafted the specification" tells the reader what happened and not what it means.

The reader wants to know: are we on track, has anything changed, do I need to do anything. An activity list requires them to work that out themselves, and most will not bother.

They are written for the writer

Chronological updates follow the order the writer experienced the week. That order is almost never the order of importance to the reader.

Writing for the reader means starting with the conclusion. This inverts how most people naturally write and is the single biggest improvement available.

Everyone gets the same one

An executive and a delivery colleague need different things. Sending both the same document means it is too detailed for one and too shallow for the other.

The result is that both stop reading, and the writer concludes that nobody cares about updates.

The Structure That Works

Section Contains Length Headline

The headline: on track, at risk, off track

one sentence One line

What changed since last time

Material developments since the last update 2–4 bullets Blocked What is stuck, with whom, since when 0–3 bullets

What you need from the reader

Specific asks with names and dates 0–2 bullets Next What happens before the next

Common Status Update Mistakes

2–3 bullets

The team wants detail

Optional, linked rather than included Link

Writing Each Section

Open with the position, report changes rather than activity, name blockers with owners, and end with a specific request.

The headline: on track, at risk, off track One word plus one sentence of explanation. "At risk — the vendor integration has slipped two weeks and we are assessing the impact on the September date."

This is the only part some readers will read, so it must carry the essential message. Vague headlines defeat the purpose; if you cannot commit to a position, that itself is the position.

What changed since last time Not everything that happened. What changed materially, relative to the last update.

If your team completed forty tasks and none of them altered the trajectory, the honest answer is that nothing changed. That is a legitimate update and considerably more useful than forty bullet points.

What is blocked and who can unblock it

Each blocker: what is stuck, who it is with, and how long it has been there.

The duration is the part usually omitted and the part that prompts action. "Waiting on legal review" is background; "waiting on legal review since 4 March" is a request.

What you need from the reader The most frequently missing section. If the update asks for nothing, the reader has no reason to respond.

Be specific: who needs to do what, by when. Updates with clear asks get responses; updates without them get read and forgotten.

Adapting for Different Audiences

Executives want the exception and the decision required, peers want dependencies affecting them, and the team wants operational detail.

Executives want exceptions and decisions

Senior readers need to know whether to worry and whether they must act. Everything else is noise to them.

Five lines: status, the one thing that changed, the one decision required. Detail available on a link for anyone who wants it. Longer updates to executives are read less thoroughly, not more.

Peers want dependencies

Other teams care about what affects them: what you will deliver to them and when, what you need from them, and what has moved.

Their version can skip your internal progress entirely and focus on the interface between you.

The team wants detail The people doing the work need operational specifics — what changed in scope, what the decisions were, what is coming next.

This version can be longest, and for many teams it is not a written update at all but simply the board, kept current.

Making Updates Sustainable

Generate the update from work data rather than retyping it, keep a fixed slot and format, and remove people who never read them.

Generate from the work, do not retype it

If writing the update means manually collecting what happened, it takes an hour and will eventually stop.

Where the project tool holds current status, most of the content already exists — completed items, blocked items, upcoming dates. Pulling from that, or linking to a live view, turns an hour of compilation into fifteen minutes of interpretation. That interpretation is the part that needs a human.

Fixed slot, fixed format

Same day, same time, same structure. Readers learn where to look for what they need, and the writing gets faster because the shape is settled.

Irregular updates get skipped because readers have no habit around them.

Stop sending to people who do not read them

Distribution lists accumulate. Ask occasionally whether people still want it, or check whether anyone opens it where the tool tells you.

A shorter list of engaged readers is worth more than a long list of people who filter it automatically.

Common Status Update Mistakes The three failures are reporting green until the week something fails, listing everything that happened, and never asking for anything.

Green until the week before it fails

The most damaging pattern in project reporting. A status that stays green and then turns red without warning destroys trust in every future update.

Report at risk early. A project flagged at risk in month two and recovered is a well-run project; one that reports green until month five is a surprise, and surprises are what stakeholders remember.

Listing everything that happened

Comprehensive activity lists feel diligent and read as noise. The reader cannot separate the significant from the routine.

Report the material. If nothing material happened, say so.

No ask, so no response

An update that requests nothing invites no engagement, and over time readers stop opening it.

Even when you need nothing, saying "no action needed this week" is better than silence — it tells the reader they can stop reading with confidence.