Overview

A method for replacing recurring status meetings with written updates, short async video, and clear escalation rules.

When to use this

A meeting mostly exists so people can report progress, but decisions and blockers still need a reliable path.

Replace One Status Meeting This Week

Start with one recurring meeting that mostly reports progress. Post the update in the project source of record before the old meeting time, then use the freed slot only if a decision remains unresolved.

  • Owner:
  • Done since last update:
  • Blocked by:
  • Next step:
  • Decision needed:
  • Needs a reply by:

Keep Live Time For Decisions

Status belongs in a durable update that people can scan on their own time. Decisions need context, options, and an owner. If those two jobs stay mixed together, the team will keep a meeting because the decision path is unclear.

  • Tag each agenda item as status, decision, discussion, or escalation.
  • Move status to written updates first.
  • Keep synchronous time for unresolved decisions, not reporting.

Set Reply Windows And Escalation

Async work fails when people do not know what a good update contains or when to respond. Define normal response windows, urgent channels, and when a blocker moves from written update to live escalation.

  • Use video only for demos, walkthroughs, and nuanced context.
  • Add a written summary and explicit ask after every video.
  • Make urgent paths explicit instead of relying on chat noise.

Method

  1. Inventory recurring meetings and mark which agenda items are status, decision, discussion, or escalation.
  2. Replace one status meeting this week with a written update template: Owner:, Done since last update:, Blocked by:, Next step:, Decision needed:, Needs a reply by:.
  3. Use async video only when tone, walkthrough, or visual context would be lost in text.
  4. Define the response window for normal updates and the escalation path for urgent blockers.
  5. Keep one short synchronous slot only for decisions that remain unresolved after written context is shared.
  6. Review after one week and restore synchronous time only where async context failed to produce action.

Before you start

What to review

  • Meeting listStart with recurring meetings so you can move status updates without losing decision time.
  • Decision logUse the current decision record to keep async updates tied to durable outcomes.
  • Update templatePrepare the fields people will post so progress, blockers, and asks are easy to scan.
  • Escalation rulesAgree on when a blocker needs a faster reply or live conversation.

Helpful places to use

  • Shared docUse a durable page as the source of record for updates and decisions.
  • Team chatUse chat for notifications and urgent paths, not as the only decision archive.
  • Async videoUse video only when a walkthrough, demo, or tone would be lost in text.

Decision points

Which meetings should stay synchronous?
Keep meetings where disagreement, sensitive context, or fast tradeoff decisions matter. Move repeatable progress reporting and FYI updates async first.
Should an update be text, video, or a live conversation?
Use text for scanability and accountability, video for visual or tonal context, and live conversation when conflict or ambiguity remains after context is shared.

Common mistakes

  • Canceling meetings before creating a reliable decision and escalation path.
  • Replacing every update with long videos that are harder to scan than meetings.
  • Letting chat become the source of record for decisions.

Troubleshooting

Blockers are discovered too late after moving async.
Add a blocker field to every update and define an urgent escalation channel with expected response times.
People say they missed the context.
Create one source-of-record page per project and require update links to point back to it.

Sources

This playbook is authored from multiple references. Open the originals to inspect details, examples, and current guidance before adapting it.

Comments

0 comments
No comments yet.