Cutting Status Meetings by Writing Better Async Updates

Not every recurring meeting is a bad habit. Some genuinely need live discussion, like resolving a disagreement or making a decision that benefits from back-and-forth. Others exist purely to transmit status that one person already knows and the rest just need to receive. Sort your recurring meetings into those two buckets honestly before deciding what to cut; converting a genuine decision-making meeting into a written thread usually just slows the decision down.

A useful test: imagine canceling the meeting and instead sending everyone a two-paragraph summary of what would have been said. If nothing important would have been lost, it was a status meeting wearing a decision meeting's time slot, and it's a strong candidate to cut.

A meeting lets people ask follow-up questions in real time, which means the original update can be sloppy and still work. A written update has to anticipate those questions up front: what changed, what's blocked, what decision is needed from whom, and by when. Skipping any of those four elements is why so many attempts at "just write it up instead" fail and teams drift back to live meetings within a month.

A common mistake is writing the update from the perspective of the person who already knows the context, rather than the reader who doesn't. If a teammate in a different time zone has to ask a follow-up question to understand what was actually decided, the update didn't do its job, no matter how detailed it looked to the person who wrote it.

• What shipped or moved since the last update: concrete, not a restatement of the plan.
• What's blocked, and on whom: name the person or team, not a vague dependency.
• What decision is needed, and by when: if nothing is needed, say so explicitly rather than leaving it implied.
• What's coming next: one or two items, not the full backlog.

Keeping updates to this shape means someone eight time zones away can read it in two minutes and know exactly what, if anything, is expected of them.

The most common failure isn't the format, it's that updates get written right before the deadline with no real content, just a restatement of the plan from last week. That's usually a sign the update is being written to satisfy a process rather than to actually inform anyone. If updates are consistently thin, the fix is smaller and more frequent updates tied to real milestones, not a longer template that people will fill in with more empty language.

Watch for the same handful of blockers showing up update after update without resolution. A blocker that's been listed for three consecutive updates without movement usually means the written format has quietly replaced the conversation that was supposed to happen to actually unblock it, which is the opposite of what async was meant to fix.

Scattering async updates across Slack threads means they're unsearchable within a week. Centralizing them in a project tool like ClickUp, attached to the actual work item they describe, means a new team member or a stakeholder catching up after vacation can read the history in context instead of asking someone to summarize it live, which quietly recreates the meeting you were trying to cut.

For teams still building the habit, a checklist-style prompt in a tool like Process Street can walk someone through the four required elements each time, until writing a complete update without the prompt becomes automatic. Retire the prompt once it's no longer needed rather than leaving it in place indefinitely.