Async Communication: When to Slack, When to Doc, When to Meet

A 12-person remote engineering team spent three weeks debugging a decision that had been made in a Slack thread six months earlier. The thread was buried under 4,000 other messages. Nobody remembered who had signed off, or why. When they finally found the original conversation, they discovered it had resolved with a thumbs-up emoji and no written rationale. Two hours into reconstructing the context, someone asked: "Why didn't we write this down somewhere?"

The answer was: nobody had agreed where "somewhere" was.

Teams that communicate well don't use better tools than the teams that communicate poorly. They've decided, as a group, which tool handles which kind of communication, and they actually follow the decision. GitLab's handbook on asynchronous communication is one of the most detailed public examples of how a fully distributed team codifies these norms at scale. That's it. That's the whole thing. The strategic version of this question — whether async-first culture delivers better business outcomes than fully remote-first culture — is worth reading separately: async-first vs. remote-first.

The 3-factor decision

Before building channel norms, you need a framework your team can apply in the moment. Three factors determine which channel to use:

Factor 1: Urgency Does this need a response within 4 hours? If yes, it belongs in a real-time channel. If it can wait until tomorrow morning, it probably doesn't.

Factor 2: Complexity Can this be answered in three sentences or fewer? If yes, it can go in Slack or Teams. If the response requires explanation, reasoning, or will spark a multi-turn discussion, a doc or a structured thread is almost always better.

Factor 3: Permanence Will someone need to reference this later? In three months? During onboarding? If yes, it needs to live somewhere searchable and structured, not in a Slack thread that will scroll off in a week.

Run any message through these three questions:

Urgent? Complex? Needs to persist? Use
Yes No No Slack/Teams direct message
Yes Yes No Short meeting or huddle
No No No Slack channel (async)
No Yes Yes Doc (Notion, Confluence, Rework)
No No Yes Doc or lightweight decision log
Yes Yes Yes Meeting, then document the outcome

Most people don't pause to run this analysis. They ping whoever's online because it feels faster. The channel norms you establish give your team a shortcut: "Is this a Slack message or a doc?" should have an obvious answer.

Step 2: Define your 4 channels and what each owns

Vague norms don't survive contact with a busy week. Define exactly what each channel is for, and equally importantly, what it's not for.

Slack or Teams: real-time, short, ephemeral Use for: Time-sensitive questions with short answers, quick coordination ("can you review this PR before 3pm"), social and team connection, links to docs that need someone's attention. Don't use for: Decisions, complex proposals, anything that needs a permanent record, information that new hires will need to find in three months. Expected response time: Within 4 business hours during working hours. After hours is opt-in, not expected.

Email: external, formal, or asynchronous threads over days Use for: External clients and vendors, formal communications, conversations that will span multiple days and involve people outside the team. Don't use for: Internal decisions, quick coordination, anything your team needs to act on today. Expected response time: 1 business day.

Docs (Notion, Confluence, Rework): reference, decisions, processes Use for: Any decision with a rationale that needs to persist, process documentation, meeting notes, project plans, specs. Don't use for: Quick questions, time-sensitive coordination. Update cadence: Within 24 hours of a decision being made.

Meetings: real-time alignment, conflict, complex multi-person decisions Use for: Anything that requires reading emotional tone, resolving conflict between two positions, decisions that need 5+ people to align simultaneously, topics that have been going in circles in async channels. Don't use for: Status updates, approvals that could be async, anything that could be a Loom video. Default length: 25 minutes, not 30 or 60.

Step 3: Write the norms as a team, not as a manager decree

Here's where most managers get it wrong. They draft the channel norms over the weekend, send them out Monday morning as a Google Doc titled "Communication Guidelines v1.0," and wonder why nobody follows them by week three.

Norms that get followed are norms people helped write. Run a 30-minute working session with your team to establish them. The format:

  • (5 min) Each person writes down one communication frustration they had in the last two weeks, silently, no discussion yet
  • (10 min) Read them aloud and group by theme. You'll quickly see the same 3-4 problems recurring
  • (10 min) For each theme, agree as a group: what's the right channel for this, and what's a specific rule that would have prevented the frustration?
  • (5 min) Appoint one person to write up the norms in plain language and share them back within 48 hours

The manager's job in this session is to run the discussion, not to present. Resist the urge to have answers ready. Ask questions. "Where do you think this should have gone?" usually gets you to a better norm than the one you would have written alone.

Step 4: Handle the exceptions

Norms break down at the edges. You need agreed answers for the edge cases before they happen, not after.

Urgent docs: Something that normally lives in a doc but needs a response today. The fix: post the doc link in Slack with "@team this needs a decision by 4pm" and set a clear deadline. Urgency doesn't change the destination. The doc is still the source of truth, but the notification goes through Slack.

Sensitive Slack threads: Sometimes a conversation that should be in Slack gets too long or too political and needs to move. The rule: once a Slack thread hits 15+ replies or the conversation has been going for 24 hours without resolution, someone calls for a move to a doc or a 20-minute meeting. Name who calls it.

Async video (Loom, Rework's async video features, Notion screenshare): Useful for walkthroughs, code reviews, design critiques, or any explanation that benefits from showing rather than telling. Add Loom as a fifth channel in your norms and define when it applies: "complex explanation that doesn't need back-and-forth, but is hard to read in text." Teams that consolidate their documentation and async video into one workspace tend to have fewer lost-context problems — the case for tool consolidation covers how COOs are approaching that decision right now.

Late-night or off-hours messages: The norm here isn't about what hour people send messages. It's about what hour they're expected to respond. Write this explicitly: "Messages sent after 6pm are not expected to receive a response until the following morning." Without this norm, people feel obligated to respond at 11pm, which creates ambient pressure that erodes focus outside work hours.

Step 5: The 3 anti-patterns to ban immediately

These specific behaviors break communication norms faster than anything else. Name them explicitly in your team norms as things you don't do.

"Just hop on a call" This phrase kills async culture. It trains people to expect real-time responses to anything non-trivial, which means nobody can block off focus time without feeling like they're dropping the ball. Before suggesting a call, require that the person sending it first tries to resolve the question in a doc or a structured Slack thread with clear context. If that fails, then schedule a call with an agenda.

The Slack thread that needed a doc Easy to spot in retrospect: a thread with 20+ replies that includes context, alternatives, and a conclusion, but now the conclusion is buried at the bottom and nobody can find it. The fix is a real-time intervention: when a thread hits 10 replies with no resolution, the norm should be that anyone can say "I'm moving this to a doc" and take responsibility for doing it. The thread then links to the doc.

The meeting that should have been a Loom Two people spend 30 minutes on a screen share explaining a system to a third person, when a 7-minute Loom covering the same ground would have done the job. Doist's research on async-first culture found that teams defaulting to synchronous explanation for complex topics consistently reported higher context-switching costs than those that defaulted to recorded walkthroughs. Before any meeting where the primary activity is "one person shows or explains something," ask: "Could this be a Loom?" If yes, make it one and save the meeting slot for actual discussion.

Step 6: Onboarding new hires into the communication norms

The norms you establish will be tested every time someone new joins the team. New hires default to the norms they learned at their last job. Without explicit onboarding into your communication norms, they'll bring Slack-first cultures into Notion-first teams, or vice versa.

In the first week, new hires should read the channel norms document, see a concrete example of each channel being used correctly, and have 15 minutes with their manager or buddy to ask questions about edge cases. A structured 30-60-90 day onboarding plan is a natural place to embed those communication norm check-ins so they don't get skipped.

In the second week, add a specific exercise: the new hire brings one communication decision they weren't sure how to handle, and the team talks through which channel it should have gone to and why. This is less about correcting the mistake and more about showing the team's reasoning in a real-world situation.

This is also where you'll catch gaps in your norms. If a new hire consistently asks about the same edge case, that edge case should probably be added to the norms document.

Common pitfalls

Building rules nobody follows: The most common failure mode is a beautiful norms document that gets referenced once at the all-hands and then ignored. The solution isn't to enforce rules. It's to make the right choice the easiest choice. If creating a Notion doc is harder than firing off a Slack message, Slack wins every time. Reduce friction for the channels you want people to use.

Making it too complex: A 4-page communication policy is not a norm. Nobody can internalize 40 rules. The effective ceiling is about 6 rules that cover 90% of situations. Keep the edge cases light and judgment-based.

Manager exempting themselves from the norms: If you tell your team to keep decisions in docs and then make major decisions over DM, the norms are dead. The manager is either the model for the norms or the fastest path to killing them. Pick one.

Norms drift: Communication norms decay naturally over 3-4 months as new tools appear, team composition changes, and old habits reassert themselves. The Microsoft Work Trend Index has consistently found that without explicit reinforcement, teams revert to synchronous defaults even when they've adopted async tools. Build a quarterly review into your team retrospective: "Are we following our communication norms? Where are we slipping?" This keeps the norms alive without making them feel like surveillance.

What to do next

Run one retrospective focused entirely on communication channel choices. Pick three real examples from the last two weeks: a decision that went well and landed in the right place, a decision that created confusion because it ended up in the wrong channel, and one example you're not sure about. Walk through each one with the 3-factor framework (urgency, complexity, permanence) and see where the norms hold and where they need clarifying.

That single conversation will surface the gaps in your current norms better than any workshop or template. Adjust the norms based on what actually happened, not what you hoped would happen. Then schedule the next communication norms review for 90 days out.

Learn More