Meetings Are a Luxury. Use Them Wisely.
Real-time meetings are the luxury. Async is the default.
The goal of async communication is to get things done without requiring everyone to be online at the same time — while still keeping everyone aligned. That means being more explicit, not less.
Most remote workers default to scheduling a call for anything that requires coordination. That’s the habit from the office — when someone walked past your desk, you just asked. Remote doesn’t work that way. But most of those calls could have been an message.
Here are the rules that replace the meeting culture.
The Async First Rule
Before you type “quick sync?” ask yourself three questions:
- Does this need a live discussion or back-and-forth?
- Can this wait 24 hours?
- Is this for alignment, decision, or just information?
If it’s information or alignment, write it. If it’s a decision with clear context, write it with a recommendation. Only schedule a meeting when you genuinely need real-time dialogue.
This one habit eliminates most unnecessary meetings. The calls you do have will be shorter, sharper, and actually necessary.
How to Write an Async Update That Gets Read
Most async updates fail because they’re too long, unfocused, or bury the ask. Use this structure for any status update, project note, or request you used to put in a meeting:
- Subject: One-line summary of what this is about
- Owner: Who’s responsible
- Status: Not started / In progress / Blocked / Done
- What happened: 2–3 sentences max. What actually changed?
- Blockers: Any person, resource, or decision holding things up — or “None”
- Next step: Who does what by when
- Feedback needed from: Names or “FYI only”
Example:
- Subject: Homepage redesign — dev handoff delayed 3 days
- Status: In progress (blocked)
- What happened: Design review added 6 new requirements. Dev team confirmed they need a scope adjustment before handoff.
- Blocker: Need product sign-off on reduced scope by EOD tomorrow or we miss the launch window.
- Next step: Review scope doc and approve/reject by 17:00 today.
- Feedback needed from: Product (approval), Dev team (confirmation)
This is the format. Fill it in, send it, done. No meeting needed.
Set Response Time Expectations — Don’t Assume Them
Ambiguous response time expectations cause more async anxiety than anything else. Set three tiers explicitly:
- Urgent: Production outage, deadline at risk — respond within 2 hours during work hours
- Normal: Questions, requests, updates — respond within 24 hours
- Low: FYI messages, no action needed — respond within 48 hours or don’t reply
The script to set these with a new team: “For me: I’ll respond to direct questions within 24 hours on working days. If it’s urgent, please say so explicitly. If I don’t hear back in 48 hours, I assume you’re heads-down — ping me again. Does that work for you?”
This conversation takes 30 seconds. It prevents weeks of anxiety.
Document Decisions Within 4 Hours
One of the biggest async failures: decisions made in a call that never get written down. For any decision — synchronous or async:
- Write it in the shared channel or project doc within 4 hours
- Include: what was decided, who decided, why (brief), and when it takes effect
- Tag it consistently: DECISION
This one habit prevents the “wait, I thought we agreed on X” spiral that derails remote teams.
The Bottom Line
Async-first doesn’t mean no meetings. It means meetings are the exception, not the default. Before you schedule a call, ask if it could be a written update. Before you send a message, ask if you’ve given the recipient enough context to act without follow-up.
The teams that run the best remote operations aren’t the ones with the most meetings. They’re the ones who wrote the meeting culture out of most of their work.
Get the templates to make this work:
Office Email Templates Bundle →
Ready-to-use templates for the exact formats described above — async standups, decision logs, meeting-free status updates, and more. Used by remote teams across 40+ countries.