"If it's not written down, it didn't happen."

Context switching for remote teams: async-first, until it breaks

Five differences from co-located teams that change the context-switching calculus:

• Time zones concentrate interruptions. When teams span four or more time zones, synchronous availability windows are narrow (often 2-3 hours). All coordination meetings pile into those windows, creating the back-to-back meeting patterns that fragment maker time most severely.
• Async is not a choice, it is the default. A team spanning London, New York, and Singapore cannot ask a question and get a same-minute response for most of the working day. Async is not a preference; it is the physics of the configuration.
• Slack amplifies Class 3 interruption risk. Without physical presence as a signal of availability, teams over-rely on Slack as a presence proxy. The red dot notification replaces the visible colleague at a desk, but with more urgency and less context.
• Video fatigue is real and measurable. Bailenson's 2021 research (Technology, Mind, and Behavior) found that continuous video calls impose cognitive load not present in face-to-face interaction: mirror self-view anxiety, reduced physical mobility, and close-up face proximity that triggers threat-response circuitry.
• Documentation replaces hallway conversation. In a co-located team, ambient context (overhearing a conversation, seeing a colleague's screen) transfers information passively. In remote teams, every piece of context transfer requires active writing. The writing quality determines whether the team functions.

The concrete mechanics of async-first in a distributed team:

• Decisions documented before (not after) the sync discussion. The written proposal circulates first; the meeting discusses it, not introduces it.
• Status updates async. End-of-week written post per engineer. No standup. Engineers who want to know someone's status read the post; they do not interrupt the person.
• Meetings require pre-reads sent at least 24 hours in advance. No pre-read, no meeting.
• Recorded Looms or Zencastr replace most 1:1 updates where presence adds no value (project status, decisions-already-made).
• Team-wide 'written first' norm even for internal proposals. The idea is written as a proposal before it is discussed. Thinking happens in writing, not in meetings.

GitLab's public handbook (handbook.gitlab.com) is the canonical reference implementation of async-first at scale. At approximately 5,000+ pages of public documentation, it covers communication standards, operating cadence, hiring, decision-making, compensation, and technical processes in explicit detail. The handbook-first principle - "if it's not in the handbook, it doesn't exist as policy" - is the most rigorous implementation of the "written first" norm.

What to extract from GitLab for a smaller team: the norm of writing before discussing; the merge-request-based decision process (propose via MR, async comments, merge when ready); the explicit communication about working hours and response-time expectations. What not to copy: the full handbook scale. A 5,000-page handbook requires a dedicated team to maintain and actively works against clarity for a 50-person company.

The principle, not the page count, is what transfers.

Four distributed-first companies that have published their operating models:

Automattic (makers of WordPress.com, 1,900+ employees, fully distributed) uses a P2 blog-based internal communication system. Team updates, proposals, and decisions circulate as blog posts in a private company blog, not in Slack. Synchronous meetings are used for human connection, not information transfer.

Zapier (fully remote since founding) publishes their async playbook publicly. Key feature: a "no-hello" policy where messages immediately state their content ("I'm working on X and hit Y - any context?") rather than "Hello" waiting for acknowledgment.

Buffer (distributed, open-book company) has published extensive writing on their async culture, including explicit policies for when sync is required versus async. Their transparency includes publishing salary data and operational metrics publicly.

Doist (makers of Todoist, fully remote) publishes detailed async-first content including their "Async Manifesto." Smaller than the others (~100 people) and more accessible as a model for small teams.

Five failure modes with recommendations for each:

When synchronous meetings are necessary, the scheduling discipline matters more for distributed teams than for co-located ones, because the synchronous window is narrower and more precious:

• Rotating meeting hours so no single time zone always absorbs the early morning or late evening meeting slots.
• Recorded meetings by default; attendance optional. Engineers in inconvenient time zones catch up via recording, not via repeat meeting.
• Agenda and pre-read required. No pre-read = meeting cancelled or rescheduled.
• 30 minutes default; 60 minutes only with explicit justification.
• Quarterly no-meeting weeks (not a day - a full week) for deep project work. GitLab and Automattic both use variants of this.

Jeremy Bailenson's 2021 paper "Nonverbal Overload: A Theoretical Argument for the Causes of Zoom Fatigue" (Technology, Mind, and Behavior, Vol 2, No 1) identified four mechanisms that make continuous video calling more fatiguing than equivalent face-to-face interaction: close-up eye gaze that triggers threat response, reduced mobility compared to in-person conversation, seeing your own face in a mirror while speaking, and the cognitive overhead of maintaining the impression of being engaged to the camera.

Practical interventions with research support: camera off is legitimate and should be explicitly normalised for calls where video adds nothing (audio-only 1:1s are fine for established relationships). Walking meetings for 1:1 calls. External window hiding the self-view. Explicit permission to not stare at the camera throughout a long call.