All articles Run the Business

Async vs. Sync Work: How to Decide What Needs a Meeting

By the FabricLoop Team  ·  May 2026  ·  4 min read

The default in most teams is to call a meeting. The default in async-first teams is to write a message. Both defaults are wrong in different situations, and both get applied without enough thought.

The question isn't "should we be async?" or "should we meet more?" It's: what does this specific situation actually require? Some things genuinely need real-time conversation. Many don't. Getting this right is one of the highest-leverage habits a team can build.

"Async by default, sync by exception — but know clearly what the exceptions are, or you'll be in meetings all day defending the principle."

A decision flowchart

Before scheduling a meeting or sending a Slack message, run through this sequence:

Does this require real-time back-and-forth to resolve?
No
Handle async — write it up clearly
Yes — continue
Is it emotionally sensitive or high-stakes for the relationship?
↓ Yes
Meet live — tone and nuance matter too much for text
↓ No
Does everyone involved need to hear it at the same time?
No
Async — write once, read when relevant
Yes — continue
Would a short async thread resolve this in under 24 hours?
Yes
Try async first — meet only if it stalls
No
Schedule a meeting — make it short and focused

What async does well

Async communication works best when the information is one-directional or when a back-and-forth can happen with reasonable time gaps between responses. Status updates, decisions that have already been made and need communicating, requests for input on a written document, routine approvals — all of these work well async.

The great advantage of async is that it respects deep work. A message that arrives at 2pm can be answered at 4pm. A meeting that's scheduled at 2pm costs everyone's focused afternoon regardless of what they were in the middle of. For teams doing complex creative or analytical work, protecting blocks of uninterrupted time is worth the slight delay in response time.

Async also creates a written record. A decision documented in a thread is findable in three months. A decision made in a meeting and not written down is effectively gone the moment the call ends.

What sync does well

Real-time conversation handles ambiguity and emotional complexity better than text. When the stakes are high, when the relationship is delicate, when the information is genuinely uncertain and needs people thinking together in real time — these are the situations where meetings earn their cost.

Brainstorming benefits from the energy of a live room (or call), where one person's half-formed idea triggers another's. Difficult feedback is better delivered live, where tone and expression carry as much meaning as the words. A negotiation with a client or a hard conversation with a team member — these should almost always happen synchronously.

The hybrid trap

The worst outcome is choosing neither mode cleanly — writing a message that's so long it needs a meeting to clarify it, or holding a meeting that produces no written record and leaves half the participants unsure what was decided. Pick the mode and commit to it. If you go async, write it clearly enough that a meeting isn't needed to interpret it. If you go sync, write up the outcome immediately afterward.

The 24-hour async test Before scheduling any meeting, ask: if I sent a well-written message on this topic right now, would we have a clear answer or path forward within 24 hours? If yes, send the message. Reserve the meeting for situations where the answer is no — where the back-and-forth is too rapid, too nuanced, or too emotionally charged for text.
Async doesn't mean slow "We're async-first" sometimes becomes an excuse for slow responses to time-sensitive things. Set clear norms: async messages should be responded to within X hours during working hours. Urgent things still get a live call — but "urgent" should mean genuinely time-critical, not "I want an answer right now."
How FabricLoop supports async-first teams FabricLoop is built for teams that want to default to async — threaded conversations, written updates, and shared task lists mean your team can stay aligned without constant calls. And when you do need to meet, the context is already written down so you spend the time deciding, not catching up.

10 things to take away from this article

  1. Neither "always meet" nor "always async" is right — the choice should depend on what the specific situation requires.
  2. Ask first: does this require real-time back-and-forth to resolve? If no, it belongs async.
  3. Emotionally sensitive or high-stakes relationship conversations should almost always happen live — tone matters too much for text.
  4. Async works best for one-directional information, routine approvals, and decisions that need communicating but not discussing.
  5. Async respects deep work — a message answered at 4pm costs nothing; a 2pm meeting costs everyone's afternoon focus.
  6. Async creates a written record. A decision in a thread is findable months later; a meeting decision that wasn't written down is effectively lost.
  7. Sync is best for genuine ambiguity, brainstorming, difficult feedback, and situations where nuance and tone carry as much meaning as words.
  8. The hybrid trap: writing a message so long it needs a meeting to interpret, or holding a meeting that produces no written outcome. Pick the mode and commit.
  9. Apply the 24-hour async test: if a well-written message would get a clear answer within a day, send the message instead of scheduling a meeting.
  10. Async-first doesn't mean slow — set clear response-time norms so the mode doesn't become an excuse for avoiding timely answers.