How to Write an Async Status Update Worth Reading

Async work runs on writing, and the status update is the most frequent piece of writing most people on a distributed team produce. Get it right and the team stays aligned with almost no meetings. Get it wrong and you generate either noise nobody reads or vagueness that forces a follow-up conversation, which is exactly the synchronous overhead async was supposed to remove.

Here is how to write a status update people can actually act on.

The Three-Part Structure

Almost every good status update answers three things: what changed, what is next, and what is blocked. That is the whole structure, and its simplicity is the point. It forces you to say something useful and keeps the update short enough to skim.

What changed is the progress since your last update — concrete, finished things, not a narration of effort. What is next tells the team where your attention is going. What is blocked surfaces anything stopping you, ideally tagged to whoever can help. A reader should get all three in under a minute.

Write for Someone Two Time Zones Away

The single best test for a status update: could a colleague who is asleep right now act on this without asking you a clarifying question? That framing changes how you write. It pushes you toward specifics and away from the vague shorthand that only makes sense if the reader can immediately reply.

"Still working on the integration" fails the test. "Integration is built; blocked on the API review from the platform team — can someone there look today?" passes it. The second version lets a reader help without a back-and-forth, which is the entire value of writing the update instead of holding a standup.

Be Specific About Blockers

Blockers are the highest-value part of any update, and they are where vagueness does the most damage. A good blocker names the thing, names who can unblock it, and says what you need. That lets the right person act the moment they read it.

Vague blockers — "waiting on some stuff" — are worse than no blocker at all, because they signal a problem without giving anyone a way to solve it. If you are blocked, make it trivially easy for someone to unblock you.

Cut the Effort Narration

The most common bloat in status updates is describing how hard you worked rather than what resulted. Nobody needs "spent the morning digging into the caching layer, then tried a few approaches, then realized..." They need the outcome: what is now true that was not true yesterday. Respecting the reader's time is part of writing a good update.

Keep It Short Enough to Skim

The reason written updates beat meetings is that people read them in two minutes and skip what does not concern them. A long update destroys that advantage — if every update is three paragraphs, people stop reading them, and you are back to needing a meeting to convey the same information.

Aim for a few tight lines. If something genuinely needs more depth — a design decision, a detailed proposal — that belongs in a document, with the update linking to it. The update itself stays skimmable.

Post It Where People Look

A perfect update in the wrong place is invisible. Updates need one durable, consistent home that everyone checks, not a different channel each time. Scattering them across direct messages and threads recreates the problem written updates were meant to solve. A single update feed — the kind Woyce is built around — keeps progress in one accumulating, searchable place.

Be Honest, Especially About Problems

The temptation in any status update is to make things sound better than they are. Resist it. The value of a written record is that it is accurate; an update that hides a slipping deadline or a quiet blocker just delays the reckoning and erodes trust in the whole system. "This is behind and here is why" is a far more useful update than an optimistic one that papers over the truth.

A Reusable Habit

A status update worth reading is short, specific, structured around what changed, what is next, and what is blocked, written so a colleague in another time zone can act on it, and posted somewhere durable. None of that is hard, but it takes a small amount of discipline each time. Build the habit across the team and most async friction disappears, because the writing does the work the meetings used to.