Async-First Principles (GitLab, Basecamp & Beyond)

"Async-first" is a set of cultural and operational norms that invert the default mode of workplace communication: writing is the primary channel, meetings are the exception. The idea was forced into practice during COVID-era distributed work but had been developed for years by remote-native companies like GitLab, Basecamp, Automattic, Zapier, and Doist. The frameworks and handbooks these companies publish have become the de facto reference for async-first operations, and they work equally well for co-located teams that value deep work and reduced meeting load.

Async-first vs sync flow: triage decision and the steps for each path with criteria for sync

Origin

GitLab — Founded in 2014 as an all-remote company, grew to 1,500+ employees across 60+ countries. Their public handbook (handbook.gitlab.com) is the most comprehensive async-first documentation in the world — 2,000+ pages covering every aspect of operations. It has become a reference for every distributed-first company since.
Basecamp (37signals) — Jason Fried and David Heinemeier Hansson have been practicing and writing about async work since the mid-2000s. Remote: Office Not Required (2013) and It Doesn't Have to Be Crazy at Work (2018) codify their approach.
Automattic — Maker of WordPress.com, Tumblr, and WooCommerce. Fully distributed since 2005. Their "creed" emphasizes async communication and written-first decision making.
Doist — Maker of Todoist and Twist. Has published extensively on async practices; their "async manifesto" is widely cited.

The common thread: companies that were remote-first from day one developed async norms because they had to. The rest of the industry is catching up because the same norms produce better outcomes even in co-located settings.

The Core Principles

Writing as Default

Default to writing.
If you would schedule a meeting, try a document first.
If you would DM, try a public channel or comment first.
If you would walk to someone's desk, try an async message first.

Writing has several advantages over synchronous communication:

- Forces clarification of thinking before expression
- Creates a durable record that scales to any audience size
- Lets recipients engage at their best cognitive time
- Works across time zones without any participant penalized
- Enables introverts and non-native speakers to participate fully
- Can be referenced and re-read

It has real costs too (slower for ambiguous, emotional, or exploratory topics), so async-first is a default, not an absolute.

Single Source of Truth

Every decision, process, policy, and team agreement has one canonical location. That location is linked, not copied. When the policy changes, one place updates.

Sub-principles:
- If it's not written down, it doesn't exist
- Links, not copies
- Public by default (within the org)
- The doc is the decision; chat/email are signals

Low-Context Writing

Because readers are distributed across time zones and may not have the live context, writing must be low-context:

- Assume the reader missed every related conversation
- State the topic, the audience, and the intent upfront
- Link to background (don't summarize inline when a link suffices)
- Use full names, not pronouns ambiguous about who you mean
- Date-stamp meaningful claims ("as of Q2 2025, we...")
- Avoid insider jargon without definition

A low-context message can be read by a new joiner in 6 months and make sense.

Handoffs, Not Meetings

Work flows through handoffs (written artifacts passed between people) rather than meetings (synchronous conversations).

Pattern:
  Person A writes -> publishes -> tags Person B
  Person B reads (on their time) -> comments/responds -> tags Person C
  ...

Meetings are reserved for:
  - Unresolved disagreements after async discussion
  - Highly emotional or relationship-sensitive topics
  - Creative brainstorming (sometimes)
  - Building rapport

Documentation as a First-Class Artifact

Writing the doc IS the work, not an overhead on top of the work. Time to write is budgeted explicitly:

- Projects include doc-time in estimates
- Engineers are measured on the quality of their written artifacts
- Promotion criteria include written influence, not just code shipped
- Reading time is also budgeted — expect people to read before meetings

Defaults That Respect Time

- No-notification by default; notifications opt-in per channel
- Response-time expectations: 24h for normal, 2h for urgent
- "Deep work" hours respected; meetings bounded to specific windows
- Public channels preferred to DMs (allow lurking, reduce FOMO)
- Timezone-aware scheduling rotation (if sync is required)

How to Use It

Adoption at the Team Level

1. Audit current meetings. List every recurring meeting. For each,
   ask: "Could this be a shared doc + async comments?"

2. Pilot a written alternative. Pick one recurring meeting; replace
   it with an async ritual for 4 weeks. Evaluate.

3. Establish a team handbook. A single place that documents your
   team's processes, decisions, roles, and norms.

4. Default to public. Move DM conversations into public channels
   where relevant.

5. Write before meeting. If a meeting is needed, write the context,
   the decision needed, and the options first. Distribute 24h prior.

6. Document decisions. Every decision gets an ADR (or equivalent)
   within 48h.

Adoption at the Organization Level

Organization-wide adoption is harder and usually requires leadership commitment:

- Leaders must default to writing (they are modeled)
- Calendar norms: meeting-free mornings, core-hour windows
- Tooling investment: a wiki or handbook, not just Slack
- Training: async writing is a skill, not automatic
- Measurement: reduction in meeting load, improved decision quality
- Patience: cultural shifts take 6-12 months minimum

Tech & Company Example

A 30-person engineering team transitions from meeting-heavy to async-first:

Before (meeting-heavy):

  Monday:     90-min sprint planning
  Tuesday:    60-min architecture review
  Wednesday:  60-min retrospective
  Thursday:   60-min 1:1s x 5
  Friday:     45-min demo
  Daily:      15-min standup

  Total: ~10 hours/week in sync meetings per engineer.
         Plus 30-60 min each of context-switching overhead.

After (async-first):

  Sprint planning:     Async — PM publishes proposed sprint doc
                       Thursday; engineers comment Fri-Mon;
                       30-min confirmation meeting Monday if needed.

  Architecture review: Async — RFC posted with 1-week comment window.
                       Meeting scheduled only if reviewers disagree
                       after written discussion.

  Retrospective:       Hybrid — async writing of start/stop/continue
                       3 days before; 45-min sync for discussion only.

  1:1s:                Sync (these stay sync — relationship work).

  Demo:                Async — videos posted to channel; questions in
                       thread; live demo only for launches.

  Standup:             Async — written daily standup in channel; live
                       meetings only for coordination-heavy days.

  Total: ~3-4 hours/week in sync meetings per engineer.
         Meetings that happen are higher-signal because written
         pre-work filtered out the ones that didn't need to be meetings.

Engineer-productive hours went up, decision documentation improved, and — counterintuitively — team cohesion remained strong because the remaining sync time was higher quality.

The DRI Overlay

The Directly Responsible Individual (DRI) model, originated at Apple, pairs naturally with async-first. For any decision or outcome, exactly one named person owns it. Apple's rule: "Someone on the meeting notes is the DRI for each action item."

Without DRI:
  "The team will look into this" — nobody does.
  "We should probably..." — nobody decides.
  "Let's discuss in next meeting" — the can is kicked forever.

With DRI:
  "Priya is DRI for the caching redesign."
  "Sam is DRI for getting legal sign-off by Friday."
  "Jordan is DRI for the handbook section on onboarding."

DRI works especially well async because it prevents the "many eyes, no owner" failure mode that written threads produce. Every async thread with a decision needs a DRI.

The Shape Up Overlay

Basecamp's Shape Up methodology (2019) is a decision/product framework that pairs well with async-first practices:

Key Shape Up norms:
  - Pitches (not meetings) are the unit of proposal
  - 6-week cycles of focused work, 2-week cooldown
  - Appetite (how much time we're willing to spend) set before
    solving — not after
  - "Hill charts" as async progress signal
  - Betting table (small group) decides which pitches to fund each
    cycle — the only major sync ritual

The Shape Up philosophy overlaps heavily with async-first: written pitches do the work of "selling" internally; the meeting (betting table) is only for the actual decision, not discussion.

When It Works

Distributed teams, especially multi-timezone
Knowledge work with complex decisions
Teams with strong writing culture
Organizations willing to invest in tooling (wiki, handbook)
Teams whose work has long feedback loops (decisions that matter for weeks/months)

When It Does Not Work

Safety-critical real-time work — Incident response, surgery, air traffic control. Sync is non-negotiable.
Early-stage exploration — The ambiguity of a blank page often benefits from a whiteboard and a live conversation.
Highly emotional topics — Conflict, feedback, grief. Writing can make them worse.
Cultures that undervalue writing — If reading long docs is seen as beneath "real work," async-first will fail.
Very short-loop work — Hourly operational coordination where sync is faster than written context-switches.

Common Failure Modes

Adoption

"Async" as Cover for Chaos — Abandoning meetings without replacing them with written rituals. Work dissolves because no one knows what's happening.
Async Without Handbook — Switching to writing without a canonical location for it. Decisions scatter across Slack, email, Notion, Google Docs. No one can find anything.
Leadership Holdouts — Leaders continue defaulting to meetings; the rest of the org models on them. Async-first fails from the top.

Practice

Walls of Text — Async writing that is long but unstructured. Readers cannot scan or reference it.
Context Collapse — Writing that assumes the reader has all the context the author has. Unreadable to anyone who wasn't in the last four conversations.
Notification Overload — Async done with maximum notifications is not async; it is just sync done in writing.
Slack-as-Handbook — Using a chat tool to store decisions. Impossible to find, scroll-bound, ephemeral in practice.

Cultural

Presence Theatre — Managers measuring "engagement" by visible online activity. Async-first requires trusting output, not monitoring activity.
Meeting Creep — Slowly adding "sync checkpoints" back until the calendar is full again. Needs active defense.
Timezone Colonialism — The "async-first" team still schedules critical meetings in one timezone's business hours, forcing others to attend outside theirs. Rotate or decouple.

Over-Application

Async for Everything — Forcing async on topics that genuinely benefit from sync. 1:1s, hard conversations, and relationship work often need synchronous time.
Documentation Tyranny — Requiring a formal doc for every tiny decision. Creates more overhead than it saves.

GitLab Handbook Model — The published reference; most comprehensive.
Basecamp Shape Up — Product/decision framework that pairs with async.
Amazon 6-pager culture — Async in spirit (silent read) but fundamentally meeting-based.
Written-first culture (Stripe, Square) — Less fully-async but shares many norms.
Atlassian "Team Playbook" — Specific playbooks for team rituals, many of which have async variants.
DRI (Apple) — The ownership overlay.
RFC/ADR practice — See Decisions & Alignment topic; pairs naturally with async-first.
Deep Work (Cal Newport) — The individual-productivity philosophy underlying async-first org design.