Synchronous vs Asynchronous Workshops

The synchronous vs asynchronous workshops question is almost always asked backwards. Teams start from the calendar - who can make Thursday at two, and can we get the New York people before their standup - when the question that actually decides the format is what the work requires. Does this outcome depend on people reacting to each other in real time, or on people thinking carefully on their own?

The short answer: use synchronous time for negotiation, trade-offs and anything where a decision needs witnesses. Use asynchronous time for generating options, reading, drafting, ranking and any task that one person can do well alone. Almost every workshop contains both kinds of work, which is why the strongest format is usually a sequence rather than a choice.

This piece sets out what genuinely separates the two modes, when each one earns its place, the sandwich structure most distributed teams should default to, and the specific ways each format fails so you can recognise the failure early enough to recover.

What actually separates the two formats

The obvious difference is timing, but that is not the interesting one. The interesting difference is turn-taking. In a live room only one person can speak at a time, so a 60-minute session with twelve people gives each person five minutes of airtime at best, and in practice gives four people fifty minutes between them. Asynchronous formats remove the queue entirely: twelve people can all contribute in the same five minutes.

The second difference is exposure. Live, you contribute in front of your manager, in sequence, after hearing what everyone before you said. That sequencing is not neutral - the first substantive answer sets a reference point that later answers cluster around. Asynchronous contribution, especially when responses stay hidden until everyone has submitted, removes that anchor.

The third difference is repair. Live, when a conversation goes wrong you can see it happening and fix it in the moment: rephrase the question, split the group, take a break. Asynchronously you find out three days later that half the participants misread the prompt. That single difference explains most of the discipline async formats demand around instructions.

So the two are not fast and slow versions of the same thing. They produce different data from the same group of people, and choosing between them is choosing which distortion you would rather live with.

When a synchronous workshop earns the diary slot

Live time is the most expensive thing you will spend in a workshop. Twelve people for ninety minutes is eighteen person-hours, and that is before travel or context-switching. Spend it only where the interaction itself is the value.

Four conditions justify it. First, the decision requires trade-offs between people with competing interests - budget splits, roadmap sequencing, who owns what. Second, the topic is emotionally loaded and needs tone, pauses and faces to stay safe. Third, the group is new to each other and you need the forming stage to happen somewhere you can steer it. Fourth, the outcome needs to be witnessed, because a decision nobody watched being made gets relitigated a fortnight later.

If none of those apply, the live session you are about to book is probably a document being read aloud. Send the document.

When asynchronous is the stronger format

Asynchronous formats win whenever the task is fundamentally individual. Generating ideas is individual: the classic result from research on brainstorming is that groups shouting ideas out produce fewer distinct ideas than the same people working separately, because waiting for a turn to speak actively interferes with holding an idea in mind. Ranking is individual. Reading a proposal properly is individual. Writing anything is individual.

Async also wins on reach. A live workshop is capped by the largest group you can facilitate well, which for genuine discussion is somewhere around fifteen people. An asynchronous prompt can take input from two hundred without any facilitation load beyond reading the results.

And it wins on time zones. If your group spans more than about six hours, every live slot is unfair to somebody. A structured async sequence - the logic behind the Delphi method, where participants contribute in anonymous rounds and see a summary before the next one - lets people in Sydney and Dublin contribute with equal weight rather than one of them contributing at eleven at night.

The trade you are making is speed. A live workshop converges in ninety minutes. The async equivalent converges in four working days, and you have to actively chase the last three responses.

A side-by-side that respects both formats

Neither column is the good one. Read this as a checklist for which parts of your agenda belong where.

The sandwich: the default shape for most workshops

If you take one structure away from this article, take this one. Put the individual work either side of a short live session, and use the live session only for the parts that need everyone present at once. The pattern borrows from the flipped classroom idea: move the input and the private thinking out of the room, so the room is spent on the work only the room can do.

In practice this cuts a half-day workshop down to about ninety minutes of live time without losing output, and it usually improves the output because people arrive having already thought.

Timings that hold up in practice

Failure modes, and how to recover mid-flight

Asynchronous workshops fail quietly, which is what makes them dangerous. The classic pattern is that eleven of eighteen people respond, you proceed, and the seven who did not respond turn out to be the seven who disagreed. Silence read as agreement is the single most common async mistake. The recovery is unglamorous: post the current response count where the group can see it, name the people you are still waiting for without shaming them, and extend by exactly one day rather than indefinitely.

The second async failure is prompt drift. If two people ask a clarifying question in the first hour, your prompt is wrong for everyone, not just for them. Stop the round, rewrite the prompt in one sentence, repost it, and reset the deadline. Losing half a day beats collecting forty answers to a question you did not mean to ask.

Synchronous workshops fail loudly and differently. The usual pattern is that the agenda assumed everyone had read the pre-read and nobody had, so the first twenty-five minutes become a summary and the actual work gets ten minutes at the end. When you notice this happening in the first five minutes, do not push through. Cut the agenda live: name the one decision that must be made today, drop the rest into an async follow-up, and tell the group you are doing it.

The third failure sits between the two. A team runs the async round properly, clusters the responses, and then holds a live session where the facilitator reads the clusters aloud for forty minutes. That is a document with a meeting attached. If your live agenda contains no moment where two people could reasonably disagree, cancel it and send the summary.

Async workshops: the honest trade

Choosing in ninety seconds

Three habits that make async workshops work

Running the async half without losing the thread

The practical problem with asynchronous workshops has never been the idea, it has been the plumbing. Contributions land in three chat threads, two documents and someone's direct messages, and the facilitator spends longer collating than the workshop would have taken.

Keeping the whole sequence in one place solves most of it. In Session Flo you can leave an activity open between sessions, so the same event holds the async idea collection, the ranking round and the live session that follows, with results visible in one view rather than reconstructed from screenshots.

Whatever tool you use, apply one rule: one link for the whole workshop. If participants need to hold two URLs in their head, your response rate drops and you will spend the live session explaining where things are instead of deciding anything.

What to measure afterwards

Judge the format on three numbers, and record them every time so you build a picture over a quarter rather than reacting to one bad session.

First, contribution breadth: what share of invited participants actually submitted something. Under 70 percent in an async round means your prompt or your deadline failed, not your participants. Second, decision durability: how many of the decisions were still standing four weeks later without being reopened. Third, live-time cost: total person-minutes spent in synchronous session for the workshop.

The interesting comparison is the ratio between the second and third. A team that halves its live-time cost while keeping decision durability flat has genuinely improved. A team that halves live time and sees decisions reopened twice as often has simply moved the argument somewhere less visible - which is the real risk of going async badly, and worth watching for.