Status Updates Nobody Reads: Four Reasons, Four Fixes

You write a good update. It is short, it has dates in it, the ask is in the first paragraph. You send it every Monday. Nobody replies, nobody references it, and in the retro someone says they had no visibility.

The advice you will find for this is to write a better update. That advice assumes the failure is in the document, and three times out of four it is not.

Four questions, in this order. Stop at the first one that returns a bad answer, because they compound and the later fixes do nothing while an earlier one is broken.

1. Did it arrive somewhere people read?

Ask it precisely: name three people who should have read last week’s update, and say where they were when they would have seen it.

If you cannot answer for all three, this is your problem and it is not about writing.

The specific failure is almost always one of these. The update goes to a project channel that exists for the project team, so the stakeholders outside the project — the ones who actually needed the date — were never in it. Or it goes to a broad channel that most people have muted, which is functionally the same as a folder. Or it lives in a document whose URL is posted once, at creation, and updated silently thereafter, so the notification everyone got was for a version that no longer exists.

The repair. Pick the place your readers are already in for other reasons, and paste the body of the update into it. Not a link. Not a thread reply under a link. The text.

If your readers are split across two places — a team channel and a leadership channel, say — post it twice. Cross-posting feels sloppy and it is worth doing anyway: you are trading a small amount of your own dignity for the whole point of the exercise. Post the full text in both. A pointer in the second place is a way of telling the more senior audience that they are the secondary one.

Then check, once, four weeks in: open the channel and look at whether anyone has ever reacted, replied or quoted. If the answer is nobody, ever, you are writing into a room with the door shut and no amount of editing changes that.

2. Did it ask for anything?

Take last week’s update and find the sentence that requires someone other than you to do something. If there isn’t one, you did not send an update. You sent a report, and reports get filed.

This is the most common failure among people who write well, because a well-written report is genuinely satisfying to produce and it feels complete. It is complete. That is the problem: a document with nothing outstanding in it gives the reader nothing to do, so they do nothing, and then you experience their doing nothing as being ignored.

The repair. Every update carries either an explicit ask or an explicit statement that there is none.

An ask has four parts and it fails without any of them:

The consequence is the part people leave out, and it is the part that works. Without it, your deadline is a preference. With it, silence has a price and the reader is choosing to pay it rather than failing to notice it.

And on the weeks when you genuinely need nothing: write nothing needed from anyone as its own line. That line is what makes the weeks with an ask visibly different. If every update looks the same, the reader learns that none of them require attention, and they are learning it from you.

3. Did the bad news arrive early enough to be bad news?

Find the worst fact in last week’s update. Count how many words come before it.

If the answer is more than about thirty, that fact was not communicated. It was included, which is a different thing, and the difference will become extremely clear the first time someone says “you never told us”.

The mechanism here is not laziness on the reader’s side. It is that a document opening with progress establishes a frame, and a reader who has decided in the first two lines that things are fine will read a slip in paragraph five as a detail inside a broadly fine situation. You did not hide it. You just placed it where it could not do its job.

The repair. Put it first. Not softened, not prefaced, not after a paragraph of context that explains why it is understandable.

Where it is: behind. Realistic date is 28 April, ten days later than plan.

Then the context, then the recovery, then the good news. The whole of the reordering is that.

Two things make this hard and both are worth naming. It feels like leading with failure every week, and on a bad project it is leading with failure every week — that is what the project is. And there is a real cost: a durable record of the date slipping is a durable record, quotable later, by someone who is not on your side. That cost is genuine. It is still smaller than the cost of the version where the news arrives in May, all at once, from someone else.

4. Is the reader the audience you wrote for?

The last question is different from the first three, because there is no edit that fixes it.

Ask: what does this reader do with the update? Not “why should they care” — what action, in their week, does the document change?

Sometimes the answer is nothing. The person is on the distribution list because they were on it when the project started, or because their name is in the org chart above yours, and your project does not intersect their decisions in any given week. They are not ignoring you. They are correctly triaging a document that has no bearing on their work, and they will keep doing it however you write it.

This is not a writing problem, and the whole genre of advice that treats it as one is why people spend six months polishing an artifact that was never going to land. You cannot write your way into someone’s priorities. The document is fine. The match is wrong.

The repair is not a rewrite. It is one of three things.

Split the audience. Two artifacts: a detailed weekly one for the people doing the work and the two people who decide, and a monthly four-line one for everyone else with dates and nothing but dates. The monthly one is the one senior readers actually read, and it is short enough that not reading it is not an option they need.

Attach the update to a decision they already own. People read documents that block them. If your update never touches anything the reader is accountable for, it never becomes urgent — but the moment it carries a sign-off, a budget line, or a date they have committed to externally, it does. That is not manipulation; it is finding the true overlap and putting it in the first line.

Or take them off. Genuinely. A distribution list padded with people who have no stake is not harmless — it is what makes the update feel unread, it is what tempts you into writing for a general audience, and writing for a general audience is how updates become vague. Cut the list to the people who act on it. The number is usually between three and eight.

What to do this week

Run the four questions on your last update, in order, and stop at the first bad answer. Do not do all four. Doing all four at once is how you end up rewriting a document whose only actual problem was the channel.

If you get through all four with good answers and it is still being ignored, you have the interesting case: a well-written, well-placed, correctly addressed document that a specific person will not read. That is a different problem with a different procedure, and it is the one this site was built for.