8 Async-First Companies and What Their Engineering Teams Do Differently

What Does Async-First Actually Mean?

Async-first does not mean no meetings. It does not mean no real-time communication. It means that written, asynchronous communication is the default — and synchronous communication is the exception used for high-bandwidth collaboration that cannot be done any other way.

This is distinct from remote-first (where the default is remote work, but the culture may still be synchronous) and from hybrid (where some people are in-office and some are remote). An async-first company could have an office. The distinguishing feature is the default communication mode: if you need to make a decision, transfer knowledge, or get alignment, your first instinct is to write it down, not call a meeting.

Async-first cultures tend to share several structural features: comprehensive documentation, no-meeting-by-default norms, written communication as a first-class artifact, and explicit policies around response time expectations. The companies below have each published significant writing about how they operate. What follows draws on their public handbooks and blog posts.

8 Async-First Companies and Their Engineering Practices

1. GitLab

GitLab is perhaps the most documented async-first company in the world. Their public handbook runs to thousands of pages and covers everything from how to write an issue to how to handle a performance review.

For engineering specifically, GitLab defaults to asynchronous communication in issues and merge requests. Every piece of work — feature, bug, architecture discussion — lives in an issue with full context written out. Merge requests include a summary of what changed and why. Code review is asynchronous by default. The expectation is not that someone will be available immediately, but that they will respond within a reasonable window and with enough written context that the reviewer can give a meaningful response without a live call.

GitLab also practices "handbook-first" communication: if something important is decided, it goes in the handbook before it goes in Slack. The written record is the source of truth.

2. Automattic

Automattic (the company behind WordPress.com, Tumblr, and WooCommerce) has been fully distributed since its founding. Their engineering teams have operated without physical offices or mandatory synchronous meetings for nearly two decades.

Automattic uses P2 — a WordPress-based internal blogging platform — as their primary communication tool. Announcements, decisions, technical proposals, and retrospectives all happen on P2 threads that are persistent and searchable. This creates a written institutional memory that persists across team changes.

Their approach to code review and deployment is also async by default: changes are proposed in PRs with full context, reviewed asynchronously, and deployed on schedules that don't require coordinated presence.

3. Basecamp / 37signals

Basecamp's founders, Jason Fried and David Heinemeier Hansson, have written extensively about async work — most notably in their books Remote and It Doesn't Have to Be Crazy at Work. Their engineering culture is one of the most explicitly documented anti-meeting cultures in the industry.

37signals practices what they call "calm company" principles: no Slack (they use their own product, HEY, for asynchronous communication), no standing meetings, and a deliberate policy against interruption-driven work. Their engineering team writes detailed "kickoff" documents for every project — explaining what is being built, why, and what success looks like — before a single line of code is written. This document replaces the kickoff meeting.

4. Doist

Doist, the company behind Todoist and Twist, has published some of the most detailed writing about async-first culture from a product engineering perspective. Their chief communication officer Brenna Loury coined the term "asynchronous-first" to describe their approach.

Doist uses Twist (their own async communication tool) instead of Slack, explicitly because Slack's design rewards immediate responses and punishes anyone who doesn't monitor it in real time. In Twist, threads are organized by topic and have no expectation of immediate response. Engineering discussions happen in threads that can span days and are read by everyone on their own schedule.

Doist also practices explicit "communication calendars" — blocks of time reserved for focused work where messages are not expected to be read. The organizational norm is that two to four hours of uninterrupted work time per day is a right, not a luxury.

5. GitHub

GitHub engineering is a notable example of async-first practices inside a large organization. Before the Microsoft acquisition, GitHub was nearly entirely async in how it ran engineering. Design proposals, technical RFCs, and major decisions happened in public or internal GitHub issues where anyone could comment on their own time.

The RFC (Request for Comments) process GitHub popularized in the open-source world — write a detailed proposal, open it for asynchronous comment, refine based on written feedback, then merge or close — has been adopted by many engineering organizations as a model for high-context async decision-making.

6. Notion

Notion's engineering team has been open about their use of their own product for internal documentation. Every project begins with a project brief in Notion. Every technical decision gets a dedicated doc. Meetings produce action items in Notion, not just memories of what was said.

The engineering culture at Notion is notable for treating writing as a core engineering skill, not just a nice-to-have. Engineers are expected to produce clear written context for their work — not just code — because the written context is what enables async review, async debugging, and async onboarding.

7. Buffer

Buffer is one of the most transparent companies about their internal operations, publishing annual culture surveys and detailed blog posts about how their team works. As a fully distributed team across 15 time zones, they have had to build async infrastructure by necessity.

Buffer engineering uses daily updates — not standups — where engineers write what they worked on, what they are working on next, and any blockers. These updates happen in a shared channel and are the primary mechanism for team awareness. Managers read updates instead of scheduling check-in meetings. The written record replaces the meeting.

This is structurally identical to what StandIn formalizes: a structured end-of-day state record that creates continuity across the team without requiring presence.

8. Zapier

Zapier is fully remote across 30+ countries and has published detailed writing about how their engineering organization runs. Their practice of "default to async" means that before any meeting is scheduled, the organizer must answer: can this be a document instead?

Zapier engineering uses weekly "snippets" — brief written updates from each team covering what shipped, what is in progress, and what is upcoming. These snippets replace the weekly status meeting for teams that are spread across enough time zones that a meeting would require someone to join at an unreasonable hour.

They also practice explicit documentation of architectural decisions using ADRs (Architecture Decision Records) — a practice adopted from the open-source community that creates a searchable history of why the system is the way it is.

What These Teams Have in Common

Despite their different sizes, industries, and specific tooling, these eight async-first engineering teams share five structural patterns:

1. Documentation as a core engineering practice

All eight teams treat writing as engineering work. Not as overhead, not as something done after the real work, but as part of delivering a feature. The written context — the issue, the PR description, the design doc — is as much a deliverable as the code itself.

2. No-meeting defaults

None of these teams have daily standups in the traditional sense. Some have brief check-ins, but they are optional, infrequent, or explicitly limited in scope. The default is: if it can be async, it is async. Meetings require justification, not the other way around.

3. Structured written communication

Each of these teams uses structured formats for key communications — not freeform Slack messages. GitLab has issue templates. Automattic has P2 threads. 37signals has kickoff documents. Zapier has snippets. The structure ensures that written communication contains enough context to act on without follow-up questions.

4. Explicit response time norms

Async-first cultures break down without explicit norms about when responses are expected. All of these teams have published policies: responses expected within X hours, certain channels monitored at certain frequencies, urgency escalated through specific paths (e.g., SMS or a specific emergency channel for true emergencies, not Slack for everything).

5. End-of-day handoffs or state updates

Every team that has sustained high output across time zones has some version of an end-of-day state update — whether it's Buffer's daily updates, Zapier's snippets, or GitLab's MR descriptions. The mechanism varies. The function is the same: ensure that whoever comes next has enough context to work without interrupting whoever just left.

How Smaller Distributed Engineering Teams Can Apply These Patterns

You don't need to be a 500-person company to implement async-first practices. The core practices scale down to a team of six.

Start with the daily state update

Before introducing new tools or rewriting your culture doc, start with a single habit: every engineer leaves a five-minute written update before closing their laptop. What they worked on, what is blocked, what the next shift needs to know. Do this for 30 days and see what changes. In most distributed teams, this single practice eliminates the majority of coordination overhead.

For teams building toward a fuller async standup format, this daily update is the foundation.

Replace one regular meeting with a written format

Pick one meeting — the weekly status check, the project standup, the monthly team sync — and replace it with a written update format for two months. Measure whether decisions got worse, or whether they actually improved because everyone had more time to read and think. Most teams are surprised.

Build your decision log

Start capturing architectural decisions in a shared doc. When a significant technical choice is made — a framework decision, a schema change, a scope trade-off — write it down: what was decided, why, and what alternatives were considered. This single practice eliminates a large fraction of "why is the code like this?" confusion and repeated debates. It is also the foundation for async governance that scales.

Choose tools that reward written communication

If your primary communication tool is designed for real-time chat (i.e., Slack), it is working against your async-first goals by design. This doesn't mean abandoning Slack — but it means being intentional about which communications belong there and which belong in a tool with better async semantics: issues, documents, structured handoffs.

Teams ready to formalize their async handoff infrastructure and see how the practices above translate into a working system can get early access to StandIn — purpose-built for distributed engineering teams that need continuity across time zones without the overhead of synchronous coordination.