Most remote teams say they work asynchronously. In practice, they’ve replaced office interruptions with Slack interruptions and scheduled meetings across every time zone until nobody has a contiguous focus block left. We did this too, for about a year, before we sat down and rebuilt our communication stack from scratch.
This is what we use now, why each piece exists, and what went wrong before we got here.
The core principle: default to async, escalate to sync
Every communication channel in our stack has a clear purpose and an expected response time. The goal isn’t to eliminate real-time conversation — it’s to make real-time the exception rather than the default.
Here’s the hierarchy we follow:
- Long-form documentation (Notion) — decisions, specs, processes. Permanent. No response expected.
- Async updates (Loom, written updates in Notion) — status, walkthroughs, context-sharing. Response within 24 hours if needed.
- Threaded discussion (Slack) — questions, quick coordination, social. Response within a few hours during overlap.
- Synchronous (Google Meet) — reserved for high-bandwidth conversations: conflict resolution, brainstorming, relationship-building.
The key rule: if something can be resolved at a lower level, it stays there. You don’t jump to a meeting when a Slack thread would work. You don’t start a Slack thread when a Notion doc would be better.
The tools and how we use them
Notion: the source of truth
Notion is where anything that matters long-term gets written down. We use it as our team wiki, project tracker, and decision log.
The critical distinction: Notion is for reference and record, not for conversation. We tried using Notion comments for discussions early on — it was a mess. Comments get buried, notification reliability is spotty, and you end up with important decisions scattered across inline threads nobody checks.
What lives in Notion:
- Team handbook and onboarding docs
- Project briefs and specs
- Meeting notes (written after the meeting, not during)
- Decision logs — what was decided, why, and who was involved
- Process documentation for recurring workflows
We have a rule: if you make a decision in Slack or a meeting, it gets recorded in Notion within 24 hours. The decision doesn’t “exist” until it’s documented. This sounds bureaucratic, but it’s saved us from relitigating the same choices multiple times.
For more on how we structure Notion specifically, see our Notion team wiki setup guide.
Loom: async video for context-heavy updates
Loom fills a gap that text can’t always cover. When you need to walk someone through a UI change, explain your reasoning on a complex decision, or give a project update that benefits from tone and emphasis, a 3-minute Loom is faster to record and easier to absorb than a 500-word write-up.
Our rules for Loom:
- Keep it under 5 minutes. If it’s longer, it should probably be a doc or a meeting.
- Always include a written summary. Not everyone will watch the video. A 2-3 sentence TL;DR posted alongside the Loom link means people can decide whether the video is worth their time.
- Use it for walkthroughs, not status updates. Weekly status is better as a written template (we cover ours in the weekly sync article).
The mistake we made early: using Loom for everything. Video is high-bandwidth, but it’s also unsearchable and slow to skim. If the information needs to be referenced later, it should end up as text in Notion regardless.
Slack: coordination, not conversation
Slack is the most dangerous tool in a remote stack. It’s where async discipline goes to die. We’ve restructured our Slack setup twice, and the current version works — but only because we enforce strict rules.
The full breakdown of how we structure channels, notifications, and escalation is in our Slack guide. The short version:
- Channels are organized by purpose, not by team. We have
#proj-channels for active projects,#ops-channels for operational concerns, and#social-for non-work talk. - Threads are mandatory. Top-level messages in project channels are announcements or questions. Everything else goes in a thread.
- @here and @channel require justification. If you’re pinging everyone, you need to explain why it’s urgent.
- DMs are discouraged for work topics. If it’s about a project, it goes in the project channel where others can see it.
The hardest Slack habit to break: treating it as a chat room. When people sit in Slack waiting for messages, response time expectations inflate and suddenly everyone feels like they need to be “on” all day. We actively encourage people to close Slack during focus blocks and check it 2-3 times per day.
Google Meet: the last resort (not the first)
We use Google Meet for synchronous calls, and we try to keep them rare. Our weekly team sync is 25 minutes (here’s the format). Beyond that, we schedule calls for:
- 1:1s (biweekly, 30 minutes)
- Brainstorming sessions where rapid back-and-forth actually adds value
- Conflict resolution or sensitive conversations
- Onboarding sessions for new hires
We don’t schedule calls for status updates, document reviews, or decisions that can happen asynchronously. The test: “Could this be a Loom or a Notion comment thread?” If yes, it shouldn’t be a meeting.
What broke before we got here
The system above didn’t appear fully formed. Here’s what went wrong in our earlier iterations:
Problem 1: No clear channel ownership. We had Slack channels for everything but no rules about what went where. Important updates got buried in general chat. Project decisions happened in DMs. Nobody knew where to look for anything.
Fix: We wrote a one-page “communication map” in Notion that defines where each type of communication goes. New hires read it on day one. It’s not complicated — just a table like this:
| If you need to… | Use… | Expected response |
|---|---|---|
| Record a decision or process | Notion doc | None (it’s a reference) |
| Walk someone through a visual change | Loom + written summary | Within 24 hours |
| Ask a project question | Slack thread in #proj- channel | Within a few hours during overlap |
| Resolve a disagreement or brainstorm | Google Meet (scheduled) | Sync — schedule in advance |
Problem 2: Loom overload. For about three months, we were sending 15-20 Looms per week across the team. People stopped watching them. Important walkthroughs got the same treatment as casual updates.
Fix: We limited Loom to situations where visual context genuinely matters. If you can say it in text, say it in text.
Problem 3: Meetings as a safety net. When async felt slow or uncertain, people defaulted to scheduling a call. This gradually filled calendars until some team members had 3-4 hours of meetings per day — which is antithetical to the whole point of working async.
Fix: We implemented a “meeting tax” — not literally, but every meeting request needs a one-line justification for why it can’t be async. Most can, and saying that out loud is enough to redirect people.
Making it stick
The tools matter less than the rules. You could replace Notion with Confluence, Loom with Screencastify, and Slack with Teams — the same principles apply. What makes an async-first stack work:
- Default expectations are documented. Everyone knows where to put things and how fast to respond.
- Sync is opt-in, not default. The burden is on scheduling a meeting, not on avoiding one.
- Written records are non-negotiable. If it wasn’t written down, it didn’t happen.
- You actually close the real-time tools. Async only works if people have uninterrupted time. That means closing Slack, not just muting it. Cal Newport’s Deep Work makes the research case for this — context-switching between messages and focused work has a real cognitive cost.
This system isn’t perfect, and we adjust it every quarter based on what’s friction and what’s working. But the baseline — document, update async, discuss in threads, meet rarely — has held up across three years and several team changes. It works because it’s simple enough that people actually follow it.