What is async work, and why is it the default for distributed teams?
Async work is a collaboration model where communication happens on each person's own schedule rather than in real time. Instead of expecting an immediate reply to every message, async teams write things down, post updates to shared boards, and trust that teammates will read and respond during their own working hours. The work moves forward continuously - it just doesn't require everyone to be online at the same time.
This isn't a new idea, but it has become the dominant collaboration model for distributed teams for a straightforward reason: time zones make synchronous communication unsustainable. A team spread across London, New York, and Tokyo has roughly two hours of overlapping business hours. Filling those two hours with standups, syncs, and status meetings leaves zero time for the actual work those meetings are supposed to coordinate. Async-first flips the equation: the default is written, persistent, and self-serve. Synchronous time is reserved for the rare conversations that genuinely need real-time back-and-forth.
The shift to async isn't just about accommodating time zones. It protects deep work. Software engineering, design, writing, and strategy all require sustained concentration. Research on developer productivity consistently shows that each involuntary context switch - a Slack ping, a tap on the shoulder, a "quick question" meeting - costs roughly 23 minutes of recovery time. A single unnecessary meeting doesn't just cost the 30 minutes on the calendar. It costs the meeting plus the cognitive ramp-up on both sides. Async communication lets people batch their responses and protect their focus blocks.
Async is a communication model, not a schedule
A common misconception is that async means everyone works whenever they feel like it with no structure. That's not async - that's chaos. Effective async teams have clear expectations about response times (respond within one business day, for example), well-defined ownership (every card has an assignee), and a single source of truth that anyone can check without asking someone. The structure is in the system, not in the meeting schedule.
Another misconception: async means slow. In practice, async teams often move faster than synchronous ones because decisions don't wait for the next scheduled meeting. A developer finishes a feature at 4 PM, posts the update on the board, and the reviewer picks it up at 9 AM the next morning in their timezone. Total elapsed time: 17 hours, but actual waiting time: zero. In a synchronous team, the same handoff waits for the next standup or the next Slack conversation when both people happen to be online.
The async toolset: boards, logs, comments, and recorded decisions
Async work only functions when information is visible, persistent, and attached to the right context. Scattered Slack threads, buried email chains, and verbal agreements that nobody wrote down are the enemies of async - though a proper Slack integration that funnels messages into board cards can turn Slack from a distraction into an async input channel. The toolset that makes async work viable has four pillars:
Kanban boards as the single source of truth
The kanban board is the centerpiece of async collaboration. It answers the questions that synchronous standups exist to answer: what's in progress, what's blocked, what's done, and who's working on what. When the board is the source of truth, nobody needs to ask "where is this task?" or "what's the status of that feature?" The answer is always on the board - visible to everyone with access, updated in real time when changes happen.
For async to work, the board must be the authoritative source. If people update the board sometimes but also track work in spreadsheets, Slack messages, and their heads, the board becomes unreliable and the team reverts to asking each other for status. The discipline is simple: if it's not on the board, it's not happening. Every task gets a card. Every status change gets a column move. Every decision gets a comment on the relevant card.
Activity logs as the async standup
The activity log records every mutation: cards created, cards moved between columns, titles updated, comments posted, labels applied. Each entry includes a timestamp, the user who made the change, and a before-and-after snapshot of what changed. This log is the async replacement for the daily standup. Instead of fifteen people spending fifteen minutes saying "yesterday I worked on X, today I'm working on Y," everyone reads the activity feed at their own pace.
The advantage over a verbal standup isn't just time savings - it's fidelity. A verbal standup relies on memory and self-reporting. The activity log is a machine-generated record of what actually happened. There's no forgetting to mention something, no misremembering the sequence of events, and no ambiguity about timing. The log is the ground truth.
See how Flux's event-sourced activity log works.
Card comments for threaded, contextual discussion
Conversations about a task should live with the task. When discussion happens in a Slack channel, it gets buried under unrelated messages within hours. When it happens in an email thread, new team members never see it. Card comments keep every question, decision, and update attached to the card it concerns. When someone picks up a card three weeks later, the entire discussion history is right there - no searching, no asking for context.
Card comments also create a natural async discussion rhythm. One person posts a question at 2 PM. Another responds at 6 PM. A third adds context the next morning. The conversation unfolds over hours or days, and every participant contributes during their peak working hours. Compare that to a synchronous meeting where someone zones out while waiting for their turn to speak.
Recorded decisions: write it down or it didn't happen
The biggest failure mode in async teams isn't slow communication - it's lost decisions. A decision made in a video call but never written down might as well not have been made. Two weeks later, nobody remembers the specifics, and the team rehashes the same discussion. Async teams develop a writing culture: every decision is recorded as a card comment, a card description update, or a checklist item. The record is permanent, searchable, and linked to the work it affects.
This writing culture is also an onboarding superpower. When a new team member joins, they don't need weeks of knowledge transfer meetings. They read the board, scan the activity log, and browse the comment threads. The institutional knowledge is in the system, not in people's heads.
When synchronous communication is still the right call
Async-first doesn't mean async-only. Some situations genuinely need real-time conversation, and pretending otherwise leads to frustration and slow resolution of urgent problems. The key is knowing when to escalate from async to sync - and having the discipline to go back to async when the synchronous moment is over.
Situations that need real-time discussion
- Incident response. When production is down, you need people making decisions together in real time. Async comments won't cut it when every minute of downtime costs money or trust.
- Interpersonal conflict. Tone is hard to read in text. If a disagreement is escalating in card comments, a 10-minute video call often resolves what would take days of increasingly terse messages.
- Complex design decisions. When a problem has multiple viable solutions and the tradeoffs are nuanced, a 30-minute whiteboard session (even virtual) can reach alignment faster than a week of async back-and-forth.
- Onboarding orientation. A new team member's first week benefits from synchronous walkthroughs of the codebase, the board structure, and the team's working norms. After the first week, async takes over.
- Brainstorming. Free-form ideation benefits from the rapid back-and-forth of real-time conversation. The energy of building on each other's ideas doesn't translate well to async comments.
The escalation rule
A useful heuristic: if an async conversation has gone back and forth three times without resolution, escalate to a synchronous call. Write the decision in a card comment immediately after the call ends so the async record stays complete. This prevents the two failure modes of pure async (endless back-and-forth) and pure sync (undocumented verbal decisions).
SSE-powered boards: the bridge between async and real-time
The cleanest implementation of async-first with real-time when needed is a board that adapts to both modes automatically. When your teammate is in a different timezone and offline, the board is the async record - they see every change when they log in. When you're both online at the same time, the board becomes real-time: their card moves, title edits, and comment posts appear on your screen instantly via server-sent events (SSE).
This dual-mode behavior is important because most teams don't have a clean async/sync divide. A globally distributed team might have three hours of overlap where two sub-teams are both online. During those three hours, the board behaves like a real-time collaborative workspace. Outside those hours, it's the async communication layer. You don't switch tools or change modes - the same board serves both purposes.
Flux uses SSE for all board-level mutations. When someone moves a card, creates a column, updates a title, or posts a comment, the server pushes the event to every connected client within a second. Combined with optimistic updates (where the UI responds immediately before server confirmation) and optimistic concurrency control (which prevents conflicting edits), the result is a board that feels instant for the person making changes and live-updating for everyone else watching.
Learn how Flux's real-time sync works under the hood.
Building a writing culture: card descriptions, comment threads, and documentation
Async work lives or dies on writing quality. A card titled "fix the thing" with no description forces someone to ask for context - which is a synchronous interruption in disguise. A card titled "Fix pagination bug on /dashboard - returns 0 results when page > 5" with a description that includes reproduction steps, expected behavior, and relevant links is fully self-serve. Anyone can pick it up without asking a single question.
Card descriptions as micro-specs
Treat every card description as a micro-specification. It should answer: what needs to happen, why it matters, what "done" looks like, and any constraints or context the assignee needs. This takes an extra two minutes when creating the card and saves twenty minutes of back-and-forth later. Over a week, across an entire team, the compounding time savings are substantial.
Comment threads as decision logs
When a question arises about a card, post it as a comment - not in Slack, not in email, not in a DM. The answer belongs with the card. When a decision is made (in a comment thread or in a meeting), record the decision as a comment. When context changes - a dependency shifts, a deadline moves, a requirement is clarified - post the update as a comment. The card's comment thread becomes the complete narrative of how the work evolved from idea to completion.
Checklists for multi-step work
For tasks that involve multiple steps, use a checklist within the card. Checklists make progress visible without requiring verbal updates. A card with 7 of 10 checklist items completed tells you more about progress than a status field that says "in progress." Each checked item is a signal to the rest of the team - visible in the board view as a progress indicator, and recorded in the activity log with a timestamp.
The cumulative effect of good writing practices is a team that can operate at full speed across any number of time zones without information bottlenecks. The board, the activity log, and the comment threads form a complete, searchable, permanent record of everything the team has done, decided, and discussed.
Getting started with async-first collaboration
Transitioning to async doesn't happen overnight. Start with one change: replace your daily standup meeting with a board-and-activity-log check. Each team member spends five minutes reading the activity feed instead of fifteen minutes in a meeting. Track whether information quality goes up or down after two weeks. Most teams find that the log provides better coverage than the verbal standup - and reclaims an hour per week per person.
Next, establish the writing norms. Every card gets a description. Every decision gets a comment. Every meeting (the few that remain) ends with someone posting the decisions and action items as card comments. Use a meeting agenda template to structure the synchronous meetings that do remain, so they produce written outcomes by default. These habits compound. Within a month, the board contains enough context that new questions can be answered by searching the board rather than interrupting a teammate.
For a deeper look at how to replace specific meeting types with async alternatives, see the meeting alternatives guide. For the rituals that keep distributed teams aligned without constant meetings, see the remote team rituals guide.