Async-First Doesn’t Mean Async-Only
Key Takeaways Asynchronous discussions can lose momentum because participants are focused on different tasks. For complex or important topics, it’s often better to switch to synchronous communication. At least in my experience working in a Japanese-speaking organization, AI-generated messages are often still too verbose to send as-is. As writing becomes cheaper, it’s even more important to reduce the cognitive load on readers. Async-first does not mean async-only. Keeping written records while introducing short meetings when necessary can reduce the overall cost of communication. Context I currently work from Vancouver, Canada, for a fully remote and fully flexible organization based in Japan. Since everyone works on their own schedule, much of our day-to-day communication, decision-making, and discussion happens asynchronously. There are many benefits to this way of working. People can think at their own pace, and discussions naturally leave a written record. As someone who is fairly introverted, I also appreciate having time to think through my ideas before sharing them. Recently, however, I’ve started to realize that keeping every discussion asynchronous is not always the most efficient approach. Complex discussions are expensive to read When discussing multiple options, I usually start by sharing my recommendation, then document the reasoning behind it and the pros and cons of alternative approaches. The more complicated the topic becomes, the longer the document becomes. Writing requires effort, but so does reading. Someone has to understand the background, process the trade-offs, form an opinion, and respond. Lately, I’ve become more aware of the reader’s cost than the writer’s. In our company, Japanese is the shared language, and much of our written communication is now assisted by AI. While AI makes it easier to produce long documents, the resulting text can still be unnecessarily verbose or difficult to follow. AI makes writing cheaper. It does not necessarily make reading cheaper. On top of that, everyone already has their own priorities. When a message arrives, people are often in the middle of something else. Replies become spread out over hours or days. Discussions can lose momentum, and important but non-urgent topics may eventually fade away without reaching a conclusion. Write first, then talk To address this, I’ve started scheduling short meetings whenever a discussion becomes too complex to resolve asynchronously. This doesn’t mean abandoning written communication. I still document the background, context, and available options. AI helps me draft these documents quickly, but I always review and simplify them before sharing. Once everyone has the necessary context, a short meeting allows the team to focus on the same problem at the same time. I’ve found that questions that would otherwise require many rounds of messages can often be resolved in just a few minutes of conversation. There’s another benefit as well. In a fully remote, fully flexible environment, opportunities to talk to teammates naturally become less frequent. Even when the purpose is purely technical, real-time conversations can help build mutual understanding and trust. Async-first doesn’t mean avoiding meetings I used to believe that if a team was designed around asynchronous communication, then most discussions should stay asynchronous. I don’t think that anymore. Asynchronous communication is a tool, not the goal. If a topic is simple, asynchronous communication works well. If a discussion becomes complex, stalls, or requires multiple rounds of clarification, a short synchronous conversation can be the more efficient option. I’ve learned not to hesitate to schedule a meeting when it helps move an important discussion forward. Being async-first doesn’t mean avoiding synchronous communication. It means choosing the communication style that minimizes the overall cost for the team.
This is a summary aggregated from Dev.to. Read the complete article on the original site:
Read full article at Dev.to