Async-first work — when you stop scheduling synchronous meetings

Most companies still default to "schedule a meeting" when work needs to happen. Async-first companies default to "write it down." The difference looks small but shapes everything: who can contribute, how long things take, how distributed teams stay aligned.

For finding meeting times when you do need them, the meeting planner is the tool. The rest of this post is about when not to use it.

What async-first actually means

Async-first is a working culture where:

1. The default is written communication (documents, threads, recorded videos)
2. Meetings are reserved for cases where sync is genuinely better (real disagreements, brainstorming, urgent escalation)
3. Decisions are made in writing and explicitly logged
4. Status updates are posted, not announced
5. Response time expectations are explicit and reasonable (e.g., "within 24 hours during business days")

Companies that pioneered async-first include GitLab, Automattic (WordPress), Doist, and Buffer. Many of these have published their playbooks publicly.

Why teams move to async-first

Three main reasons:

1. Distribution. When team members are in 3+ time zones, synchronous meetings exclude someone every time. Async lets everyone contribute on their own schedule.

2. Deep work. Constant meetings fragment the day. Async means longer blocks of focused work without interruption.

3. Decision quality. Written communication forces clearer thinking. People who don't speak first in meetings (introverts, non-native English speakers, junior team members) contribute more.

The shift is gradual. Companies don't go from "10 meetings a day" to "0" overnight. The transition takes 6-12 months of explicit cultural investment.

What works async, what doesn't

Works async:
- Status updates (written daily/weekly)
- Code review (PR comments)
- Design review (Figma comments, design docs)
- Project planning (GitHub Issues, Linear, Jira)
- Documentation (in source control)
- Knowledge sharing (recorded videos, written posts)
- Most decisions (RFC docs)
- Regular feedback (1:1 doc shared between manager and report)

Doesn't work async (or poorly):
- Genuine disagreements (better to talk it out)
- Crisis response (someone is breaking; you need answers now)
- Brainstorming (the messy back-and-forth doesn't capture in writing)
- Onboarding new hires (the first 1-2 weeks need real-time)
- Difficult interpersonal conversations
- Building team rapport (some sync time is needed)

The pattern: anything that benefits from immediate clarification or emotional nuance is sync. Anything that's information transfer or decision-tracking is async.

The minimum sync meetings

Even strongly async teams have a few synchronous meetings:

Weekly all-hands or team meeting. 30-60 minutes. Status updates, announcements, Q&A. Usually held during the broadest overlap window.

1:1s. Manager and report meet weekly or biweekly for 30 minutes. Both prepare a shared doc beforehand.

Sprint planning (or equivalent). Every 1-2 weeks. The planning session itself is sync; the prep is async.

Retrospectives. Every 1-2 sprints. Discuss what went well/poorly, plan improvements.

Major project kick-offs. When starting a significant new initiative, gather the team for a sync session.

Crisis response. When something is broken in production, sync.

That's roughly 2-3 hours of meetings per week. Compared to 10+ hours typical at meeting-heavy companies.

Tools that enable async-first

For writing:
- Google Docs / Notion / Coda (collaborative editing)
- Linear / Jira / GitHub Issues (project management)
- Figma / Excalidraw (visual collaboration)
- Loom / Tella / OBS (recorded videos for nuance)

For threading:
- Slack / Teams (with strict thread discipline)
- Discord (for community-style work)

For decisions:
- RFC documents (request-for-comment)
- ADRs (architecture decision records)
- Pull requests (for code-related decisions)

For coordination:
- Status pages (each team posts weekly)
- Roadmaps (visible, shared)
- Calendars (with time zones, working hours)
- The meeting planner for the rare sync sessions

What async culture requires

For async-first to work, the team needs:

1. Strong writing skills. Or willingness to develop them. Async amplifies poor writing into communication breakdowns.

2. Explicit response-time expectations. "I'll respond within 24 hours during business days" is reasonable; "respond immediately or you're not committed" is async-incompatible.

3. Trust. Managers must trust that team members are working without being visible. Some companies struggle with this and revert to surveillance.

4. Documentation discipline. Decisions must be recorded somewhere findable later. "We discussed this in Slack" is bad; "We decided this in [doc link] on [date]" is good.

5. Tolerance for slowness. Async decisions take longer. A choice that would take 30 minutes in a meeting might take 2-3 days async. The trade-off is depth and inclusion.

6. Clear meeting rules. When meetings do happen, they're consequential. Have an agenda. Take notes. Share the notes.

Common mistakes

1. Cargo-culting the form without the substance. Adopting async tools (Notion, Loom) without changing the underlying meeting culture. The team still has 10 meetings a week, plus now also writes lots of docs.

2. No follow-up on async decisions. A document with 5 questions sits unanswered for 2 weeks because nobody's accountable. Async requires explicit "decision deadline."

3. Slack as a sync tool. When Slack threads expect immediate replies, it's not async — it's sync via text. Real async means asynchronous, with response time measured in hours or days.

4. Penalizing slow responses. If a manager judges performance based on response speed, async breaks. Performance should be judged on quality and outcomes.

5. No explicit "meeting trigger." Without rules for when to schedule a meeting, default behavior creeps back in.

The transition

Companies moving toward async-first typically:

- Month 1-2: Set explicit rules for which decisions need meetings vs documents
- Month 3-4: Meeting count drops by 30-50%; team adjusts to writing
- Month 5-6: Decision-tracking tools become standard
- Month 6-9: Async cadence becomes natural; new hires onboard into the culture
- Month 9-12: Async is the default; sync is the exception

The 6-month mark is when the cultural shift typically takes hold.

When async is wrong

Some companies and roles fundamentally need sync:

- Emergency response (firefighters, surgeons, infrastructure on-call)
- Real-time creative collaboration (some music production, live broadcasting)
- High-stakes negotiation (M&A, contract talks, legal disputes)
- Onboarding period (first month of a new hire)

For these, sync is right. For most knowledge work, async-first is better.

FAQ

How do I know if my team should go async-first?

Three signs: (1) team members are in 2+ time zones, (2) people complain meetings interfere with deep work, (3) decisions get made by whoever is loudest in meetings. If two of three apply, async is worth trying.

What about pair programming?

Pair programming is sync by design. Some async teams use it for specific complex tasks. Most don't. Code review (PRs) is the async equivalent and works for most cases.

Will async work for sales teams?

Less well. Sales benefits from real-time relationship building. Some sales teams use async for internal coordination but sync for customer interaction.

What about junior employees?

Junior employees often need more sync time for mentorship and learning. Don't expect a 6-month-tenure engineer to thrive in fully async culture. Build in dedicated mentorship time.

How do I get started?

Pick one meeting on your calendar that could be a doc. Replace it with a doc. Track results. Iterate. Don't try to convert the whole company at once.

Is async-first the same as remote work?

Related but distinct. You can be remote and meeting-heavy (just synchronous meetings via Zoom). You can be co-located and meeting-light. Async-first describes the meeting culture, not the location.

Bottom line

Async-first reduces the number of synchronous meetings, moves most decisions to written documents, and respects time zones by not requiring everyone to be online simultaneously. It works well for knowledge work; less well for emergency response or real-time collaboration. The transition takes 6-12 months and requires explicit cultural change.

For the meetings that genuinely need to happen synchronously, the meeting planner handles cross-zone scheduling.