There is a persistent myth in office culture that the team with the most meetings, the fastest Slack response times, and the most synchronized schedules is the most productive. It is not. Some of the most effective engineering and product teams in the world operate with minimal real-time coordination, and they ship faster and with less burnout than their always-on counterparts. Here is what they actually do differently.
1. They Treat Written Communication as a First-Class Skill
In most offices, writing is what you do when you have to. You dash off a Slack message. You fire off a quick email. The assumption is that the important thinking happens in the meeting and the written record is just housekeeping. Async-first teams invert this. Writing is where the thinking happens, and the written artifact is the work product.
This matters because clear writing requires clear thinking in a way that verbal communication does not. You can stumble through a spoken explanation with filler words and backtracking and still get your point across in a meeting. You cannot do that in a well-structured document. When Basecamp formalized this into their company culture, they found that the forcing function of written communication surfaced bad ideas earlier and created better decisions with fewer people in the room. GitLab, which operates as a fully distributed company and publishes its internal handbook publicly, has a documented preference for writing over synchronous communication at almost every layer of the organization.
The practical consequence is that teams that write well move faster, because the information is already structured, searchable, and available to anyone who joins the conversation later.
2. They Distinguish Between Urgent and Important, and Almost Nothing Is Urgent
The pathology of real-time communication is that it flattens everything into urgency. A Slack ping and a production outage both demand your attention right now. The cognitive cost of that constant interruption is not just the time spent responding; it is the time spent re-entering concentration after the interruption. Research on how cognitive work actually functions suggests that the interruption cost is often far higher than people intuit.
Async teams establish explicit norms around response time. A message gets a response within a few hours, not within a few minutes, unless it is explicitly flagged as urgent (and the bar for “urgent” is genuinely high, usually meaning production is down or a deadline is slipping in real time). This is not about being slow. It is about protecting the concentrated work windows that produce actual output.
When you remove the expectation of instant response, something interesting happens: people send fewer, better messages, because they have to think about what they actually need instead of lobbing half-formed questions into a chat window and waiting for someone else to do the thinking.
3. They Design Meetings to Make Decisions, Not to Exchange Information
The meeting that could have been an email is a cliche because it is true and because nobody has actually fixed it. Async teams do fix it, by making information exchange entirely asynchronous and reserving synchronous time for the specific thing that synchronous communication is actually good at: real-time negotiation and decision-making.
A useful forcing function here is requiring a written pre-read for every synchronous meeting. Not an agenda, a document. The meeting then starts with the assumption that everyone has read the document, skips the information-sharing phase entirely, and goes straight to disagreements and decisions. This compresses a sixty-minute status meeting into fifteen minutes of actual deliberation. It also creates a written record of the context before the decision, which is useful when you are debugging why a decision was made six months later.
This approach also makes it easier to include people across time zones without penalizing anyone for being in the wrong timezone. The work has already happened asynchronously. The meeting is just the final synchronization point.
4. They Build Documentation Infrastructure Before They Need It
Most teams document reluctantly and retroactively, usually after something goes wrong. Async teams treat documentation as infrastructure, meaning they build it before they need it and they maintain it the same way they would maintain code.
The analogy to code is genuinely useful here. Nobody argues that comments and documentation in a codebase are optional nice-to-haves. You write them because the next person who reads this code might be you in six months, and you will not remember what you were thinking. The same logic applies to decisions, processes, and institutional knowledge. If it is not written down and findable, it effectively does not exist for anyone who was not in the room.
The teams that do this well have a single source of truth (a wiki, a handbook, a structured set of shared docs) that is actively maintained, not a graveyard of outdated Google Docs with conflicting information. The maintenance burden is real but it pays for itself quickly once you stop spending synchronous meeting time re-explaining context that should already be written somewhere.
5. They Use Time Zone Differences as an Advantage, Not a Constraint
The standard complaint about distributed teams is that time zone differences make coordination harder. This is only true if you are trying to replicate synchronous office patterns across time zones. Async teams reframe the distribution: if your team spans twelve hours of time zones, you effectively have a relay race where work is always in motion.
A team that spans the US West Coast, Europe, and Asia can hand work off across time zones so that something moves forward during every waking hour without anyone working unusual hours. This requires disciplined handoff documentation (see point 4) but the payoff is real. The async team does not have to wait for the next business day for a review or a decision; it can arrive in someone’s inbox while they sleep.
The office that never sleeps but runs on synchronous communication burns people out because being always available is required for everything to function. The async team that spans time zones gets the coverage without the burnout because availability is structured, not constant.
6. They Normalize Long-Form Thinking Over Short-Form Reaction
Slack and its equivalents are optimized for fast responses. The default interaction is a short message, a reaction emoji, a quick reply. This is fine for social coordination. It is terrible for anything that requires actual analysis.
Async teams develop a muscle for long-form writing: the internal memo, the RFC (Request for Comments, a format borrowed from engineering standards processes), the pre-mortem document. These formats force the author to think through second-order consequences, anticipate objections, and provide enough context that a reader can engage substantively without a real-time back-and-forth.
Amazon’s famous practice of writing six-page memos that are read in silence at the start of meetings is a version of this. The memo is not bureaucracy; it is a forcing function that requires the idea’s owner to actually think it through before presenting it. Teams that adopt some version of this, even informally, report that it surfaces bad ideas before they consume significant resources and makes the good ideas much easier to actually ship.
