How to run async standups that people actually read

Moving your standup to async is the easy part. Pick a Slack bot, write three questions, and the DM starts arriving at 9 a.m. local time. The hard part is the one nobody talks about: getting your team to actually read the digest.

When an async standup degrades into a muted channel full of copy-pasted “working on the auth stuff” entries, it’s worse than the meeting it replaced. At least the meeting forced eye contact. The muted channel just wastes a Slack notification slot and makes everyone feel like they’re keeping up when they’re not.

Here is what makes the difference between a standup people read and one they treat as inbox furniture.

What kills most async standups

The surface-level reason is noise. The deeper problem is that the standup answers the wrong question.

Most teams set up a bot and ask everyone what they did yesterday, what they’re doing today, and whether they’re blocked. But nobody else on the team actually cares about those answers in aggregate. An engineering manager might, but a teammate in a different project area mostly wants to know two things: is my PR being reviewed, and is something on fire that I can help with.

When the daily digest becomes a list of ten people summarizing their individual task lists, the signal-to-noise ratio is terrible. Everyone skims for their own name, maybe their direct collaborator’s name, and closes the tab. The standup is not serving the team. It is serving a reporting habit.

Trying to replace a verbal standup one-for-one with a text version is the second killer. A live standup works because it’s a social ritual. You see faces, you hear tone, someone cracks a joke. A text digest has none of that. If you treat it like a form to fill out, people will fill it out like a form: minimally, mechanically, and only until you stop enforcing it.

How to write a standup update that’s worth reading

Start by cutting the prompts to two or three at most. A standup with seven questions takes too long to answer and produces a wall of text nobody will scroll through. The best sets we’ve seen:

1. What’s one thing you’ll finish today (not “work on,” not “make progress on” — finish)
2. What do you need from someone else to unblock it
3. Anything the team should know (optional, open-ended)

This format does three things. It caps the response length because you’re picking one thing, not summarizing twenty. It forces the writer to name a specific dependency, which makes the standup actionable instead of passive. And the third question catches the stuff that doesn’t fit a template: a flaky test someone should look at, a dependency upgrade that broke staging, a customer escalation that just landed.

Write updates as if someone reading them has four seconds and wants to know whether to scroll further. Lead with the dependency or the blocker, not the context. “Blocked on PR #412 review — back-end work for the search endpoint” is useful. “Yesterday I continued working on the search feature and made some progress on the pagination logic, then updated the API schema, and now I’m waiting for a review on PR #412 which is the back-end part” is a small essay that buries the only actionable sentence.

Making the digest scannable at speed

The digest itself needs to be structured so scanning it takes under a minute. The best approach we’ve seen uses sections:

Blockers (do this first). A bullet list of people who need something from someone, with the ask in one sentence and a link to the relevant PR, issue, or doc. If nobody is blocked, this section is one line: “No blockers today.”

Done. One line per person, one thing each. Not the whole list, just the one thing that moved the needle.

FYI. Links to things worth knowing: a design doc that just went up, a postmortem draft, a decision log entry. This section is empty most days. That’s fine.

The key structural rule: the most useful information goes first. If someone opens the digest and the top three lines are blockers they can unblock, they take action. If the top is a wall of task logs, they close the tab. This isn’t rudeness. It’s design.

Keeping it running past the first month

The honeymoon period is real. For the first two to four weeks, everyone fills out the standup enthusiastically because it’s new and because it means they skip a meeting. Then the novelty wears off and the fill rate starts to dip.

The fix that works is making someone responsible for the digest output, not the input. Don’t chase people to fill out their updates. Instead, have one person (rotating weekly) spend three minutes each day checking whether blockers from yesterday’s digest actually got resolved, then ping the relevant person directly if they didn’t. When people see that the digest produces action, not just archival text, they keep filling it out.

The rotating owner also scans for the “nothing to report” drift problem. When someone writes “working on stuff, no blockers” three days in a row, it’s usually not because they’re coasting. It’s because their work doesn’t fit the standup format anymore. A quick DM asking “hey, want to switch your update to the weekly summary instead of the daily?” keeps the daily digest clean without shaming anyone.

Async standups don’t fail because the tool is wrong. They fail because the ritual doesn’t produce enough value for the time it costs. A standup that takes two minutes to write and two minutes to read, where the read yields one blocker resolved or one dependency handed off, is a net win every day. A standup that takes five minutes to write and nobody reads is just busywork with a Slack bot attached.