Async status updates that replace a status meeting

Async status updates replace a status meeting with a short written update each person posts at an agreed time, in one agreed place, in three parts: done, next, blocked. They work when someone reads every update and each blocker gets a named person to resolve it, often in a short conversation. They fail when they become a diary nobody reads and blockers sit unanswered for days.

This guide covers switching a status meeting over step by step, a template, where updates should live, and what happens to the things a meeting did well. Notes from a standup that stays a meeting are a separate topic: see standup meeting notes.

How to switch a status meeting to async status updates

1. Say what the meeting was for. If it existed to share status, it can go async. If it existed to make decisions, it needs to stay a meeting, probably a shorter one.
2. Agree the format. Done, next, blocked. Short. The template is below.
3. Agree one place. A single channel, thread or page per team. Not a mix.
4. Agree a time. "By 10:00 in your time zone" gives a predictable point when the day's updates are complete.
5. Name a reader. Usually the team lead or whoever ran the meeting. Their job is to read every update and act on the blockers the same day.
6. Decide what happens to blockers. A blocker gets a named person and a direct conversation, a call if it needs one. It does not wait for the next update.
7. Keep one short meeting, if you need one. A weekly 25 minutes for decisions and anything the updates surfaced.
8. Review after three weeks. Are updates read? Do blockers get resolved faster or slower than before?

A template

**<name> — <date>**

**Done:** <what finished since the last update, one line each>
**Next:** <what you are working on until the next update>
**Blocked:** <what is stopping you, and who could unblock it — or "nothing">

A filled-in example from a fictional team:

**Tom Becker — 24 September**

**Done:** Export to CSV merged; release notes drafted.
**Next:** Fixing the date filter bug Northwind reported.
**Blocked:** Need a test account with Northwind's data shape — Priya?

Three things make it work:

• Short. If it takes more than two minutes to write, it has turned into a report. Link to detail rather than pasting it.
• Specific. "Working on the export" says little. "Export merged; release notes drafted" says what changed.
• Blockers name a person. "Blocked on the API" leaves everyone waiting. "Need Priya to confirm the field names" gives Priya something to do.

What a status meeting did that updates must still do

A status meeting has jobs that are easy to lose when it goes:

The last row matters most. Decisions made in reply threads are easy to miss. If a decision is needed, put it on an agenda and record it; the meeting agenda template and a decision log help.

Where to post updates

One place, the one the team already reads.

• A chat channel or daily thread works for small teams that already live in chat. A thread per day keeps the channel readable.
• A shared page or document works when updates need to be read later, or by people outside the team.
• The ticket tracker works for the "done" and "next" parts, but blockers get lost in ticket comments. Keep blockers where someone reads them daily.

Avoid spreading updates between tools. The reader should be able to see the whole team in one view.

Common problems

Nobody reads them. Name the reader and make it part of their day. Reading takes a few minutes for a team of eight.

Updates grow into reports. Reset the length: three lines, links for detail.

Blockers sit for days. A blocker posted at 09:45 should have a named person and a plan by lunchtime. If not, the reader has not been named or does not have the time.

People feel disconnected. Status meetings were also where people saw each other. Replace that on purpose, with a short weekly call that is not about status, rather than bringing status back.

Time zones. Async updates suit teams across time zones better than a meeting does. Set the deadline in each person's local morning, and accept that some blockers will be answered the next working day; say so, so nobody expects otherwise.

When to keep the meeting

Some status meetings should stay:

• During an incident or a launch week, when things change hourly.
• For a newly formed team, where people do not yet know each other's work well enough to read a three-line update.
• When the updates show constant disagreement about priorities. That is a planning problem, and it needs a conversation.

Replacing status meetings is one of the larger savings in having fewer meetings. It pairs well with no-meeting days, because the updates give people something to read instead of a meeting to attend.

Frequently asked questions

What is an async status update?

A short written update, posted at a set time in a shared place, that replaces saying the same thing aloud in a status meeting. People read it when it suits them rather than all at once.

What should an async status update include?

What you finished since the last update, what you are doing next, and anything blocking you, with who could unblock it. Three short parts are enough; a longer update stops being read.

Can async standups replace a daily standup completely?

For status, often yes. What they do not replace is the conversation a blocker or a disagreement needs. Most teams keep a short, occasional meeting for those, or talk one to one when a blocker appears.

How do you stop async updates being ignored?

Name someone to read every update each day and act on the blockers. Updates that nobody reads decay within weeks.

Where should async updates be posted?

In one place the team already reads, such as a dedicated chat channel or thread, or a shared page. One place per team; updates scattered across tools get missed.