Async standup updates people actually read

An async standup update people actually read does three things: it says what changed, it names the one thing blocking you, and it reads in thirty seconds. That is the entire trick. The rest of this piece is about why those three are hard to write and easy to fake.

Async standups were supposed to fix the standup meeting. No more ten people holding coffee while someone reads their calendar out loud. Mostly we moved the calendar reading into a channel, where it is easier to ignore and sticks around forever.

Here is the uncomfortable part. Most standup updates are not written to be read. They are written to prove the writer was busy. Readers can smell that, so they skim for their own name and scroll on. If nobody would notice your update missing for a week, the update is the problem, not the ritual.

Say what changed, not what you did

The first line of an update should say what is different since your last one. Not where your time went. What changed.

Activity and progress feel identical from the inside, and they read completely differently. "Worked on the checkout flow" is activity. "Checkout now survives a card decline" is a change in the world. The second one lets a reader decide whether it affects them. The first one asks them to trust you and move on, which they will.

Watch what the usual verbs actually say:

• "Worked on the importer" says time passed near the importer.
• "Continued the migration" says the migration still exists.
• "Synced with design" says a meeting happened.
• "Looked into the flaky tests" says the tests remain flaky.

The fix is mechanical. Before you post, reread your first line and ask what a teammate now knows that they did not know yesterday. If the answer is "that I was busy", rewrite it or delete it.

I keep a ledger for Unvent: every time something ships, one line about what changed. Reading a month of it back is a cheap education in this. The lines that name a change are still useful. The lines about effort tell me nothing, and I am the one who wrote them.

Put the blocker where nobody can miss it

A blocker buried in your third paragraph might as well not exist. Give it its own line, and make it concrete enough that someone can act on it without asking a follow-up question.

The blocker is the only part of a standup that someone else can do something about. Everything else is information. This is the part that pays for the whole ritual, and it is also the part people write most vaguely, because naming a blocker feels like admitting failure.

It is the opposite. Stalling quietly for three days and surfacing it in a retro is the failure. An update that asks for help on the day the help is needed is what the format is for, and asking early is cheaper for everyone, including you.

A blocker line that works names things plainly:

• The thing you are stuck on, in one sentence.
• The person or decision that would unstick it.
• The date it starts costing something.

"Blocked on legal review" gives nobody anything to do. "I need a yes or no on the retention copy from whoever owns it by Thursday, or the release slips a week" is a request someone can pick up and close.

Thirty seconds, then links

A standup update should read in about thirty seconds. Past that people skim, and skimmed is where blockers go to die. Length reads as indecision: you could not pick what mattered, so now the reader has to.

Depth belongs in links. Link the pull request or the doc and let the one person who needs the detail click through. The update is the trailer, not the film.

Things that can go first when you trim:

• Anything the reader can already see in the tracker.
• The story of how you found the bug, which belongs in the pull request.
• Plans further out than tomorrow, which will change anyway.

If your tool threads replies, use that. Post the short update, put the detail in the first reply. The people who need it will find it, and everyone else gets the short version.

When an update of mine balloons anyway, I run it through Unvent right in the box I typed it in and take the Direct version. It is usually the same update minus the apology for its own length.

When nothing moved, say so

"No movement, still on the importer, nothing needed" is a complete update, and a good one. It costs you four seconds of looking unproductive, and it buys something worth more: a reputation for only posting information.

Padding a quiet day into a paragraph teaches people that your updates are noise, and they will remember that on the day you post an important one. The trust you spend padding Tuesday is the trust you need on Friday.

I will go further, and this is the part people push back on. If your team's daily updates are mostly filler, the problem is not discipline. You are reporting more often than things actually change. Twice a week with real content beats a daily ritual everyone skims, and a cadence is not sacred just because it is daily.

The best thing that can happen to a standup update is a reply. Not a thumbs up: a question, or a "wait, that affects me." Updates written as proof of work never get replies, because there is nothing in them to reply to. Post one worth answering and see who shows up.