Async by Default: How Remote Teams Stop Drowning in Slack
Here's a question worth sitting with for a moment: when was the last time you finished a workday and felt like you'd actually done your best work? For a lot of remote workers, the honest answer is "not for a while." We're online, we're responsive, we're "in" Slack from 9 to 6, and yet the actual deep work, the kind that moves a project meaningfully forward, keeps getting pushed to evenings and weekends.
The diagnosis isn't usually individual discipline. It's that the team operates synchronously by default, even though it's distributed. Everyone is expected to be reachable in real time, every question is asked in chat, every decision happens in a thread, and the result is that nobody has more than 25 uninterrupted minutes at a stretch. Research by Gloria Mark at UC Irvine has found that the average knowledge worker switches tasks every few minutes, and full recovery from an interruption takes more than 20.
Going "async by default" doesn't mean banning Slack or never meeting. It means inverting a few defaults so that real-time interruption becomes the exception, not the norm. Here's what that looks like in practice.
The four kinds of messages, and where each one belongs
Most teams treat Slack as the universal medium. It isn't. Workplace communication breaks down into four rough categories, and only one of them genuinely belongs in chat:
- Decisions and proposals. Anything that should be findable in three months. Belongs in a doc or a ticket, not in a Slack thread that disappears under the next message.
- Status updates and progress. Belongs in a shared place (project board, weekly written update). Slack #standup channels don't count, because they're not searchable in a useful way.
- Questions that need a thoughtful answer. Belong in email or async ticket comments. The "thoughtful" part is killed by chat's expectation of fast replies.
- Quick coordination. "Are you free for 15 min?" or "Can you push the deploy now?" This is what Slack is genuinely good at.
If you look at a typical engineer's Slack and tag every message by category, three-quarters of them are usually in the first three categories - in the wrong medium. Moving each to its proper place is the whole project.
Default 1: Write the decision doc before the discussion
The single highest-leverage habit a remote team can adopt is the short written proposal. Before you call a meeting or open a Slack thread to "discuss" something, write a one-page doc that includes:
- What you're proposing (one sentence)
- Why now (two sentences)
- Options considered and which one you recommend
- The decision you need and from whom
Share the doc, ask for comments by a specific date (usually 48 hours), and only schedule a meeting if comments reveal genuine disagreement. In our experience the doc-first habit kills about 60% of the meetings that would otherwise happen, because once the proposal is written down the answer is often obvious.
Default 2: Status goes in writing, on a schedule
The async equivalent of the daily standup is a written end-of-day or end-of-week update. The format doesn't matter much, but the discipline does. Something like:
- Shipped today: Two bullet points max.
- Working on next: One thing.
- Blocked on: Specific blockers and who can unblock.
Three things this fixes that a sync standup doesn't: it's searchable (you can scroll back six weeks to see how a project actually progressed), it's reviewable by people in other timezones, and it forces clarity. "I'm working on the auth refactor" sounds fine in a 30-second standup; written down, you realize it's been the same bullet for two weeks and something is stuck.
Default 3: Reply windows, not reply expectations
The hidden killer of deep work isn't actually the volume of messages. It's the expectation that each message be answered within a few minutes. If your team operates with that norm, nobody can ever close Slack.
The async fix is explicit reply windows. Each person publishes when they check messages - for example, "I respond to Slack at 11am, 3pm, and 5pm." Outside those windows, you're unreachable for non-emergencies. Emergencies use a different channel (a phone call, a paged on-call rotation), so the bar for one is genuinely high.
This sounds restrictive until you try it. What actually happens is that people batch their questions ("hey, three things I wanted to ask"), the questions get more thoughtful (because the asker had to think for a few minutes), and the team's collective focus time goes up several hours a week per person.
Default 4: Meetings have a written agenda or they don't happen
A meeting without a written agenda 24 hours in advance is, in practice, a meeting where one person already knows what they want and the rest are showing up cold. That's not collaboration, it's an audience.
An agenda is one sentence per item plus the desired outcome. "Decide on pricing for Tier 2 - approved or revise" is a complete agenda item. "Discuss pricing" is not. If the agenda can't be written, the meeting probably shouldn't happen yet; there's a decision doc to write first.
Default 5: The "no internal Slack on weekends" rule
For teams across timezones, the temptation to send "just one quick message" on a weekend is constant. Don't. Even if the recipient knows they don't have to reply, the message changes their weekend - they're now thinking about work.
The fix is mechanical: use scheduled send. Slack, Gmail, and most chat tools let you write a message now and have it deliver Monday morning. We made this a team norm and weekend Slack volume dropped 90% within a month. Nothing actually shipped slower.
What you'll lose, and why it's worth it
The honest tradeoff of going async-first is that some things genuinely take longer. A real-time conversation that would have wrapped in 10 minutes might take 24 hours when it moves to a doc with comments. For genuinely urgent decisions, that's a cost.
What you gain in exchange: meaningfully more deep work time per person, written history of how decisions were made, less timezone discrimination on globally distributed teams, and dramatically less anxiety about being "on" all day. GitLab's public handbook is the best-documented example of a fully async-first company at scale - it's worth reading even if you have no plans to adopt all of it.
Where to start
If you're a manager, start with default 1 (decision docs) and default 4 (agendas required). Those two together cut your team's meeting load enough that they'll have the room to adopt the others. If you're an individual contributor on a sync-heavy team, start with explicit reply windows in your own profile. Most teams will respect them once they see they don't break anything.
The goal isn't to become a stoic monk of remote work. It's to make the default mode of operation one where real work can happen, and to keep real-time interruption as a tool used deliberately rather than the air everyone breathes.