The Async-First Docs-First Manifesto

TL;DR: If your workforce is global but your work habits are local (read: meeting-centric, “ping me now,” and memory-powered), you’re running yesterday’s playbook on tomorrow’s field. The companies scaling remote-first—GitLab, Stripe, Remote, Automattic, Zapier—win by being async-first and docs-first. This isn’t optional hygiene; it’s a competitive advantage backed by evidence and hard-won practice [1–3, 5–11, 13–16, 19–20].

Preamble: We Interrupt This Meeting To Bring You Work

Somewhere, someone is trapped in a 12‑person status call across seven time zones, while the real work waits patiently in a tab marked “Later.” Meanwhile, an engineer in Singapore is wide awake, an analyst in Dublin is just sitting down, and a designer in São Paulo is finally in flow—until the calendar invites arrive like glitter: hard to remove, everywhere, and vaguely accusatory.

Modern SaaS is borderless. Your customers span continents; your team does too. Running that team synchronously is like insisting everyone use the same socket adapter. Asynchronous communication—paired with a culture of documentation—is the adapter. It turns time zone differences from a tax into compound interest: work progresses while you sleep; decisions persist after you log off; and brilliance is captured in writing rather than evaporating in air.

This is a manifesto, yes, but also with receipts: policies you can copy, steps you can run tomorrow, and outcomes others have already measured.

The Claim (Bold but Boringly True)

Remote-first + global workforce ⇒ async-first + docs-first, or you are paying a massive opportunity cost.

Why?

1. Throughput beats talkput. Async lets work “follow the sun,” turning handoffs into a 24‑hour conveyor belt instead of a twice‑a‑day standup [6, 10].
2. Writing is thinking. When decisions are written, they’re clearer, easier to critique, and easier to reuse. Stripe didn’t just say this—they engineered for it, from internal memos to Markdoc-powered docs [7–8, 13, 15].
3. Documentation is the operating system. GitLab literally runs the company from a public handbook and issues; “if it’s not in an epic/issue/MR, it doesn’t exist” [1–2].
4. Flow is fragile. Interruptions spike stress and degrade performance; structured async reduces context switching and preserves focus [15, 19].
5. Inclusion isn’t a poster; it’s a process. Async + documentation are accessible defaults that benefit everyone and are particularly impactful for neurodivergent teammates [14, 16–17, 20].

Part I — The Case for Async: Let The Work Work While You Don’t

Time is the rarest shared resource on a global team

If your company spans UTC‑8 to UTC+8, insisting on real‑time discussions privileges one band of clocks. Leaders who rotate all‑hands times, default to recorded meetings with written agendas/outcomes, and reserve synchronous time for high‑bandwidth moments (e.g., conflict resolution, pairing) remove time-zone bias and speed actual delivery [1].

Writing > winging it

Documents are not the “paperwork after the real discussion.” They are the discussion. Stripe institutionalized narrative memos, exec emails with footnotes (!), and literate docs to drive decisions across distance without drama [7, 15].

Flow matters (and interruptions don’t care about your KPIs)

Controlled studies show interrupted knowledge work increases stress and perceived workload; people compensate with speed, but quality and well‑being suffer [19]. Async norms reduce the “Are you there?” pings and tilt the day toward deep work.

Manager translation: Async isn’t a vibe; it’s a throughput strategy.

Part II — The Case for Documentation: Your Single Source of “Oh, That’s How We Do It”

• Documentation = memory. People leave; calendars are busy; Slack scrolls away. The doc remains.
• Documentation = scale. Every answer you write once is a hundred questions you never have to answer again.
• Documentation = equity. Written, searchable processes reduce gatekeeping and “who you had lunch with” as a success factor.

GitLab: “Handbook-first” as a company design

GitLab runs the business from a public handbook (thousands of pages), with handbook-first communication and public-by-default norms. They explicitly train teams that “asynchronous communication is documentation,” and that GitLab issues/MRs are the single source of truth. If it’s not in an epic/issue/MR, it doesn’t exist [1–3]. Onboarding is an issue template—literally—so the first week teaches the system, not exceptions [4].

Stripe: Writing as a core competency

Stripe treats writing as infrastructure. Former documentation leaders describe leadership modeling strong writing (yes, executive emails with footnotes), narrative memos for decisions, and relentlessly edited product docs. They rebuilt docs on Markdoc to keep authoring elegant while adding interactivity, because good docs aren’t a brochure—they’re a tool [7–8, 13, 15].

Part III — Evidence from Leading SaaS Companies

Below are practical steps the companies implemented and their observed outcomes. Copy shamelessly.

A. GitLab (DevSecOps platform; all-remote from day one)

What they implemented (GitLab)

• Handbook-first: Public, searchable handbook as operational source of truth; “answer with a link” culture [1–2].
• Async by default: Written proposals, agendas, and summaries; recorded meetings; rotating time zones; “three replies then meet” rule to protect flow [1].
• Issues/MRs as the rails: Work, onboarding, decisions tracked in issues/epics/MRs; if it’s not there, it’s not real [1, 4].
• Public by default: Communication defaults to open unless confidential; transparency as a design constraint [3].

Results they report (GitLab)

• Speed through iteration: Smaller changes + async → faster shipping (explicit executive guidance) [1].
• Reduced meeting drag and broader participation across time zones (meeting guidelines & practices institutionalized) [1].
• Cultural clarity: Fewer “tribal knowledge” choke points; easier onboarding via issue templates [4].

Why this travels (GitLab)

Because they wrote everything down, you can audit and adopt it—policy by policy, template by template [1–4].

B. Stripe (Payments & fintech; multi-hub + remote engineering)

What they implemented (Stripe)

• A remote engineering “hub” coequal with SF, Seattle, Dublin, Singapore—explicit organizational design, not a sidecar [5].
• Write-first culture: Narrative memos, edited internal posts, executive model behavior (footnoted emails), persistent decision records [7, 15].
• Docs as product: Replatformed on Markdoc to reconcile authoring ergonomics with interactive docs quality [8, 13].

Results they report (Stripe)

• Hired 100 remote engineers in the hub’s first year, tripling permanently remote engineers to 22% of engineering. The remote hub became the “backbone” of a company-wide model [6].
• Closer to customers, faster localization: Distributed teams improved non‑card payment support and local product fit (concrete examples in Checkout) [6].
• Team performance: A remote invoices team “quintupled their growth” after distributing across cities/time zones and moving decisions into writing; recurring meetings canceled without agendas [6].

Why this travels (Stripe)

Treat remote as a first-class hub; make writing the default interface for decisions; invest in docs tooling as if it were customer-facing (because it is) [5–8].

C. Remote (Global HR & EOR platform; remote-first)

What they implemented (Remote)

• Async work principles published for customers and teams: reduce scope, multiplex tasks, set response SLAs, reserve meetings for decisions, “default to action” in ambiguity [13].
• Neurodiversity playbooks: Practical, manager-facing guidance on how async + remote supports neurodivergent colleagues (control of environment, processing time, fewer forced social contexts) [14].

Results they report (Remote)

• Operational guidance codified into simple rules-of-thumb (e.g., when to choose sync vs async, documentation expectations) that customers adopt; cultural consistency at scale [13–14].

Why this travels (Remote)

Even if you don’t buy Remote’s product, the playbooks are turnkey culture accelerators.

D. Automattic (WordPress/WooCommerce; fully distributed since 2005)

What they implemented (Automattic)

• “The future of remote work is text.” Most comms are written and asynchronous; meetings are scarce and purposeful [10].
• P2 (WordPress‑native internal blogs) as the long‑lived discussion surface; Slack/Jira exist, but P2 holds the durable record [10].
• Transparency rituals: Leadership posts what they’re working on; decisions and board materials are documented for internal visibility [10].

Results they report (Automattic)

• Scale without offices: Over 1,700 employees with low meeting load; “growing quicker with fewer issues because we are distributed” (CFO) [10].
• Faster decisions: People stop saving updates “for the meeting,” because the meeting is the doc [10].

Why this travels (Automattic)

If you don’t have P2, pick any durable medium (GitLab issues, Notion, Confluence) and use it the same way.

E. Zapier (Automation SaaS; fully distributed)

What they implemented (Zapier)

• Default to async culture; Async (internal blog) + chat + internal docs; written clarity as a hiring bar and a management habit [11–12].
• Remote playbook open‑sourced for teams: guardrail policies, expectation setting, and async manager tactics [11].

Results they report (Zapier)

• Global scale (800+ teammates across 40+ countries) with heavy reliance on written, asynchronous workflows; public playbooks accelerate customer and community adoption [11–12].

Why this travels (Zapier)

Zapier’s guidance is pragmatic, specific, and lightweight—perfect for piloting async habits fast.

Table 1 — What they did & what they got (SaaS edition)

Note: Where numbers appear (e.g., Stripe’s 22% remote engineering), they are company‑reported metrics with links to the original source for context [6].

Part IV — Inclusivity Isn’t an Afterthought: Async + Docs for Neurodivergent Teammates (and Everyone Else)

Let’s say the quiet part out loud: the “9–to‑5, always‑on, cameras-on, have-an-opinion-now” office culture was designed for a very narrow slice of people. Async + documentation widens the aperture. Research and practitioner guidance converge on a few themes:

• Control over environment & schedule benefits people with sensory sensitivities, ADHD, or executive function differences—and incidentally benefits… everyone [14, 16–17].
• Clear written expectations & decision records reduce ambiguity tax; people can re-read instead of pretend they understood in real-time [14, 16–17, 20].
• Processing time enables thoughtful contributions from those who do their best thinking off‑call; again, that’s not just neurodivergent folks [16–17].

The punchline: These “accommodations” are actually performance features for the whole company. Harvard Business Review has long argued that neurodiversity is a competitive advantage; async and documentation are how you turn that from a slogan into a system [20].

Part V — The Manager’s Playbook (With Guardrails You Can Ship This Week)

You don’t “become async” with a sticker. You change defaults, tools, and expectations. Here’s a pragmatic rollout, tuned for SaaS product/engineering orgs.

Name the experiment (2–4 weeks), pick success metrics

• Outcomes: fewer recurring meetings, faster cycle time on small changes, higher doc search/use, lower “Where is X?” pings.
• Instrumentation: count recurring meetings removed, average PR/issue cycle time, doc pageviews/searches, qualitative pulse.

Write-first decisions

• For any proposal above a Jira ticket, require a one‑pager (context → proposal → options → risks → decision needed). Make comments the default venue; meetings require an agenda & pre‑reads.
• Provide templates (steal from GitLab/Stripe patterns) [1–2, 7, 15].

Create a single source of truth (SSoT)

• Pick one surface (GitLab issues/epics, Notion, Confluence). All decisions and artifacts live there.
• Rule: “If it’s not linked from the SSoT, it didn’t happen” (lifted from GitLab) [1–2]. Add a “Start here” index and /meta page explaining the system.

Meeting diet, not meeting shame

• Put every recurring meeting on the chopping block. If it survives, it needs: purpose, owner, cadence, agenda, pre‑reads, doc link, and a recording policy.
• Law of Three: after three async replies without convergence, schedule a short call—and document the outcome [1].
• Rotate & record global meetings (time zones, not just titles) [1].

Response SLAs & norms

• Set channel‑specific expectations (e.g., PR mention: 24h; project channel: 48h; @urgent: immediate).
• Ban “drive‑by” @mentions without context; link the doc/issues instead (GitLab-style “answer with a link”) [1–2]. Teach people to summarize long threads (“Recap:” at the top of an issue if >1,000 words is a GitLab pattern) [1].

Async‑first onboarding

• Convert onboarding to an issue/checklist with links to the SSoT and manager/team READMEs (mirroring GitLab) [4]. Record short “how this team works” loom videos; store with transcripts.

Tooling minimalism

• Fewer channels, more clarity. One chat, one doc wiki, one task/issue tracker. Integrate, don’t proliferate. If you build docs for customers, eat your own cooking (Stripe’s Markdoc ethos) [8, 13].

Inclusion by design

• Offer camera‑optional calls; ensure written alternatives for contributions. Normalize async brainstorming (doc comments first, then a short sync to resolve) to allow processing time [14, 16–17, 20].
• Publish a team working agreement (time zones, SLAs, meeting norms, accessibility preferences).

Leadership behaviors

• Execs write. Execs link. Execs cancel meeting blocks without agendas. Execs post decisions in the SSoT. Celebrate docs that unlocked outcomes (not just features shipped).
• Make writing a promotion criterion for leads and managers (Stripe‑style modeling) [7, 15].

Table 2 — Async Symptoms & Treatments

But Won’t We Be Slower Without Meetings?

Short answer: no—not if you do async correctly. Consider the field data:

• Stripe deliberately built a remote engineering hub; within a year they hit hiring goals (100 remote engineers), tripled remote share in engineering (to 22%), and report faster local product fit via distributed teams [6].
• Automattic grew past 1,700 employees with text‑first collaboration and fewer meetings, reporting they “grow quicker with fewer issues because [they] are distributed” [10].
• GitLab shows how small, iterative changes plus async communication accelerate shipping while keeping public accountability high [1].

Also, meetings are not collaboration; they are one form of collaboration. The async toolbox—docs, comments, annotated PRs, recorded demos, decision logs—does the heavy lifting. Use meetings for what they’re uniquely good at: trust, conflict resolution, and gnarly problems after a written pass.

Caveats, Challenges, and How to Not Blow It

• Async ≠ zero meetings. You still need real‑time for some things. Use it wisely (kickoffs, conflict, time‑sensitive decisions). Keep them short and documented [1,13].
• Docs rot if no one owns them. Add doc ownership (team/DRI), review cadences, and an “archive” policy. Stripe solved quality with editorial standards and better tooling (Markdoc) [8, 15].
• Beware tool sprawl. More apps ≠ more async. Choose one SSoT and be ruthless about linking to it [1–2, 13].
• Don’t weaponize “async.” It’s not an excuse to be unresponsive or to never decide. Set SLAs and decision deadlines.
• Social fabric still matters. Celebrate in writing and in the occasional synchronous social slot. Async doesn’t mean austere.

A (Short) Word on the Science of Focus

Context switching and interruptions carry cognitive and emotional costs. Controlled experiments show that interrupted work increases stress, frustration, and workload; people “make up” speed at the expense of experience quality [19]. Async defaults protect focus time and put writing in front of meetings, lowering the odds your team lives in the most expensive UI your company owns: the calendar.

The Manifesto (Stick This on the Fridge)

1. Write it down, or it didn’t happen. Decisions live in the doc/issue, not in someone’s memory [1–2].
2. Async by default. Meet on purpose, not by habit [1,10,15].
3. One source of truth. Many tools, one canonical home (link to it) [1–2].
4. Small changes, shipped often. Async thrives on iteration [1].
5. Rotate time, record outcomes. Time zones are a feature, not a flaw [1].
6. Inclusion is architectural. Design for neurodiversity and you’ll help everyone [14,16–17,20].
7. Leaders model the medium. Executives: write, link, cancel, and praise docs [7,10,15].
8. Measure throughput, not busyness. Count shipped decisions and deltas, not hours online.

Implementation Checklist (Copy/Paste)

• Create /operating-system page (or repo) with SSoT, templates, and working agreement
• Publish decision doc template; require it for cross‑team changes
• Convert onboarding into an issue/checklist with links to SSoT
• Define channel SLAs; pin them; enforce “no contextless @mentions”
• Kill or rewrite recurring meetings; rotate & record all‑hands
• Require “Recap:” summaries atop any doc >1,000 words
• Start leader writing cadence (weekly notes, public decisions)
• Add accessibility & neuroinclusion section to the working agreement (camera‑optional, processing time, written alternatives, sensory breaks)
• Instrument: track cycle time, doc search/views, meeting hours/person, and sentiment pulse

Final Nudge

The hardest part isn’t choosing tools or writing templates. It’s flipping the default. The moment you make writing the first draft of collaboration—and meetings the exception—you’ll feel the cultural click. Ship the first 10%: one template, one SSoT, one meeting policy. You can iterate the rest. (Yes, that’s also the GitLab way [1].)

The companies we admire didn’t arrive at async nirvana through vibes; they documented their way there. Now you can too.

Bibliography

[1] GitLab Handbook — “How to embrace asynchronous communication for remote work.” https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/

[2] GitLab Handbook — “The importance of a handbook-first approach to communication.” https://handbook.gitlab.com/handbook/company/culture/all-remote/handbook-first/

[3] GitLab Handbook — “Communication (public by default).” https://handbook.gitlab.com/handbook/communication/

[4] GitLab Handbook — “General Onboarding” (issue-based onboarding). https://handbook.gitlab.com/handbook/people-group/general-onboarding/

[5] Stripe — “Stripe’s fifth engineering hub is Remote.” https://stripe.com/blog/remote-hub

[6] Stripe — “Stripe’s remote engineering hub, one year in.” https://stripe.com/blog/remote-hub-one-year

[7] Slab — “How Stripe Built a Writing Culture.” https://slab.com/blog/stripe-writing-culture/

[8] Stripe — “How Stripe builds interactive docs with Markdoc.” https://stripe.com/blog/markdoc

[9] Increment (published by Stripe) — “About.” https://increment.com/about/

[10] TechCrunch — “The future of remote work is text (Automattic TC‑1, Part 4).” https://techcrunch.com/2021/10/19/automattic-tc1-remote/

[11] Zapier — “The Ultimate Guide to Remote Work.” https://zapier.com/resources/guides/remote-work

[12] Zapier — “Remote design: How Zapier is building a distributed design culture.” https://zapier.com/blog/remote-design-culture/

[13] Remote — “Why you should be working asynchronously.” https://remote.com/resources/insights-center/why-you-should-be-doing-async-work

[14] Remote — “How to support neurodivergence in the workplace with remote and async work.” https://remote.com/resources/insights-center/support-neurodivergence-workplace-remote-async

[15] Harvard Business Review — “Remote Work Should Be (Mostly) Asynchronous.” https://hbr.org/2021/12/remote-work-should-be-mostly-asynchronous

[16] Cambridge University Press (Industrial and Organizational Psychology) — “How can work from home support neurodiversity and inclusion?” https://www.cambridge.org/core/journals/industrial-and-organizational-psychology/article/how-can-work-from-home-support -neurodiversity-and-inclusion/4670A94662153943CEA21C02C45F1D37

[17] Microsoft Research — “Towards Accessible Remote Work: Understanding Work‑from‑Home Practices of Neurodivergent Professionals.” https://www.microsoft.com/en-us/research/publication/towards-accessible-remote-work-understanding-work-from-home-practi ces-of-neurodivergent-professionals/

[18] GitLab Handbook — “Live doc meetings” (sample regrets, agenda practices). https://handbook.gitlab.com/handbook/company/culture/all-remote/live-doc-meetings/

[19] Mark, G., Gonzalez, V. M., & Harris, J. — “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. PDF: https://ics.uci.edu/~gmark/chi08-mark.pdf

[20] Harvard Business Review — “Neurodiversity Is a Competitive Advantage.” https://hbr.org/2017/05/neurodiversity-as-a-competitive-advantage