There's a team in one of our client companies that ships more per engineer than any other team in the organization. They have developers in New York, Sao Paulo, and Buenos Aires. They hold two synchronous meetings per week. Total meeting time: 90 minutes.
The rest of their communication happens in writing. Design docs, Loom videos, detailed PR descriptions, daily async standups in Slack. They produce more, ship faster, and have fewer misunderstandings than teams that spend three hours a day in video calls.
This is not an accident. They chose async communication deliberately and built their processes around it.
The meeting tax
Every meeting has a cost beyond the time on the calendar. There's context switching before the meeting. There's recovery time after. A one-hour meeting doesn't cost one hour. It costs roughly two hours of productive work when you factor in the disruption to focused time.
For a developer, this is especially expensive. Writing code requires deep focus. Getting into a flow state takes 15-25 minutes. A meeting in the middle of the morning destroys the entire morning's productive window.
Now multiply this across time zones. A "quick sync" that works for New York at 10 AM is 12 PM in Sao Paulo and might land right in someone's lunch break. Finding a time that works for everyone becomes a logistics problem that eats into everyone's best working hours.
What async actually means
Async communication means sharing information in a way that doesn't require everyone to be present at the same time. The recipient reads and responds when it fits their schedule, not when a calendar invite dictates.
In practice, it looks like this:
- Design decisions happen in written RFCs (request for comments). Someone writes up the proposal, the team comments over 24-48 hours, and the decision is documented before any code is written.
- Daily standups happen in Slack. Each person posts what they did yesterday, what they're doing today, and any blockers. Takes two minutes to write, one minute per person to read.
- Code reviews include detailed PR descriptions. Not just "fixed bug." Instead: what the bug was, how they found it, what they changed, and how to test it.
- Complex explanations use Loom videos. A five-minute screen recording replaces a thirty-minute meeting and can be watched at 2x speed.
Why async wins for distributed teams
It respects time zones. When your team spans UTC-3 to UTC-5, synchronous overlap might be just 4-5 hours. Async communication uses the full workday for everyone instead of cramming everything into the overlap window.
It creates a written record. Decisions made in meetings evaporate unless someone takes notes. Decisions made in writing exist forever. Three months later, you can search Slack or your docs and find exactly why the team chose Approach A over Approach B.
It produces better thinking. Writing forces clarity. When you have to explain your idea in writing, you discover the gaps in your thinking before anyone else does. Meeting discussions often skip over details because the social pressure to keep things moving is strong.
It protects focus time. Developers can batch their communication into specific windows and spend the rest of their time in flow state. Two hours of uninterrupted coding produces more than six hours of coding interrupted by meetings and Slack pings every thirty minutes.
The async playbook
Switching to async doesn't mean eliminating all meetings. It means making async the default and sync the exception.
Rule 1: Write first, meet only if writing doesn't resolve it. Before scheduling a meeting, write up the question or decision in a shared doc or Slack thread. If the thread resolves it, you just saved everyone a meeting. If it doesn't, now you have a clear agenda for the meeting.
Rule 2: Expect response within 4 hours, not 4 minutes. Async works when people trust that messages will be seen and responded to within a reasonable window. Define that window for your team and hold to it.
Rule 3: Over-communicate context. In a meeting, you can read body language and ask for clarification in real time. In async, you can't. So add the context upfront. "I'm proposing we switch from REST to GraphQL for the mobile app because [three specific reasons]" is better than "What do people think about GraphQL?"
Rule 4: Use the right format for the message. Short updates: Slack. Complex decisions: written RFC. Visual explanations: Loom video. Bug reports: detailed ticket with reproduction steps. Matching the format to the content makes async communication efficient instead of frustrating.
When sync is still better
Async is the default, not the only tool. Some things genuinely work better synchronously:
- Brainstorming sessions where ideas build on each other rapidly
- Conflict resolution where tone and empathy matter
- Sprint planning where the team needs to align on priorities together
- Pair programming for complex debugging or knowledge transfer
- One-on-ones for relationship building and coaching
The key is to use sync meetings for things that genuinely benefit from real-time interaction, not as the default for everything.
Making the switch
If your team currently defaults to meetings, you can't flip to async overnight. Start with two changes:
First, move daily standups to Slack. This alone saves 30-60 minutes per day across the team and sets the tone that writing is a primary communication channel.
Second, require written context before any meeting. "Let's hop on a call" becomes "I wrote up the problem here [link]. Let's discuss on a call if the thread doesn't resolve it." Half the time, the thread resolves it.
Within a month, your team will wonder why they ever spent so much time in video calls.
