Async-first: fewer meetings, decisions that actually last

It’s 2pm. You just entered deep focus mode. Your ticket is moving forward. Then: a meeting invite for ten minutes from now. “Quick sync on topic X.” You join the call. It runs 25 minutes. It could have been a three-line message.

This scenario is common. So common that we’ve come to accept it as part of the job. It shouldn’t be.

An async-first culture changes this relationship with meetings. Not by eliminating communication, but by deliberately choosing when communication needs to be synchronous - and when it doesn’t.

Async-first is not isolation

The most common misconception about async-first: equating it with lack of communication or solitary work. It’s the opposite.

Async-first requires more communication, not less. It requires more careful, more explicit, more contextualized communication.

When you send an asynchronous message, you need to include the context you would have expressed verbally. You need to anticipate questions. You need to write in a way that someone reading in six hours - or six weeks - can understand the issue without asking you.

More effort to write. Less collective effort overall. Every meeting saved represents the sum of all participants’ time - and their interrupted focus.

The problem with synchronous by default

Most teams operate synchronous by default. A meeting is the first reflex for anything beyond two sentences.

This mode carries costs that are rarely measured.

Deep work interruption. States of deep concentration are rare and fragile. A 30-minute meeting in the middle of an afternoon doesn’t cost 30 minutes - it costs the time to find the thread before and after. Some studies estimate this cost at over an hour for a 20-minute interruption.

Implicit exclusion. Teams distributed across multiple time zones can’t all join a meeting at 10am Paris time. Synchronous by default creates an implicit hierarchy between those who can attend and those who receive the notes two days later.

Decisions that disappear. How many decisions were made in meetings, without notes, and became “we decided X” vs “no, I remember we said Y” three weeks later? Synchronous without a written trace generates retrospective disagreements that shouldn’t exist.

The tyranny of immediate availability. Synchronous by default creates an expectation: you must be available right now. This expectation pushes people to constantly check their messages, to interrupt their work to respond instantly, to never truly enter a state of sustained focus.

What async-first changes in practice

An async-first culture doesn’t eliminate meetings. It reserves them.

Meetings remain useful for:

• Topics that genuinely require real-time discussion (brainstorming, conflict resolution, sensitive decisions)
• Onboarding and building connections between team members
• Direct collaborative work sessions (pair programming, live code review)
• Retrospectives and review phases where direct dialogue has emotional value

Everything else can be asynchronous. Here’s how.

Decisions written on pages. Every architecture, product, or process decision deserves a dedicated page. Not a meeting summary - a structured page: context, options considered, decision made, reasons. This page is searchable, versioned, accessible to someone who joins the team six months from now.

Issues with complete context. An issue without context forces someone to schedule a meeting to understand the topic. A well-written issue, with the problem clearly stated, constraints identified, and open questions listed, lets whoever picks it up start working without asking for clarification.

Structured threads instead of status meetings. “Let’s meet to catch up on X” is often replaceable with a thread where each concerned person shares their progress and blockers. Synchronization happens, but each person contributes when they’re available.

Asynchronous reviews. A code review, architecture review, or spec review can happen through written comments. The discussion unfolds over hours or a day rather than requiring a slot in five people’s calendars.

The practices that make async work

Async-first doesn’t happen by itself. It rests on a few practices that, if missing, shift the culture toward isolation rather than collaboration.

Respond within a reasonable timeframe. Async doesn’t mean responding whenever. In most teams, a few hours for non-urgent messages is reasonable. Urgent messages have a dedicated channel, separate from everything else.

Write for the future reader. Every message, comment, and decision is written imagining someone will read it three months from now without having followed the preceding conversation. Is the context there? Is the decision clear?

Name decisions explicitly. In a thread, the final decision must be explicitly stated. “I think we’ll go with option B” is not a decision. “Decision: going with option B for reasons X and Y.” is.

Distinguish urgent from important. Async-first works when the team has a clear convention on what justifies an immediate interruption. Without this convention, everything becomes urgent by default, which cancels out the benefits of async.

Async-first and human connection

A common objection: async reduces human interaction. Teams lose cohesion. Members feel isolated.

This objection is real. Poorly practiced async can lead to teams where people don’t really know each other, where conflicts crystallize in written threads rather than resolving in direct conversation.

Async-first doesn’t mean async-always. Informal interactions, moments of cohesion, exchanges that aren’t “about a topic” have their place. These are often synchronous moments that don’t cost meetings: a virtual coffee, an informal chat channel, optional co-working sessions.

The difference: these moments are chosen, not imposed by a calendar. They add to the work instead of interrupting its most focused part.

Async-first with Sinra

Async-first relies on tools that allow contextualizing and structuring information.

In Sinra, pages let you document decisions and link them to the relevant issues and capabilities. An architecture decision is a page - not a meeting memory. Issues include their full context at creation, reducing back-and-forth to understand what’s being asked.

Cycles provide a clear time frame: every team member knows what’s expected in the period, without needing constant synchronization. The cycle objective is written. Cycle issues are visible. Progress is readable directly in the tool.

This isn’t async for async’s sake. It’s the conviction that good decisions, well documented, let everyone work with autonomy and clarity - without waiting to be summoned to a meeting to know what to do.

Meetings have their use. A real one, for topics that deserve it. The problem isn’t meetings. It’s the default meeting, the synchronous reflex that consumes collective focus without producing proportional value.

Async-first means making the opposite choice: write first, meet when necessary. Not the other way around.