← All posts

Blog

5 min read

Asynchronous decisions for remote teams: how to decide without another meeting

A distributed team makes small decisions all day — which vendor, which date, which name — and most of them don't deserve a call. How to run one as a room instead: who answers, who closes, what everyone sees, and what happens when the decider is asleep.

Remote teams have a bad habit: when a decision needs more than one person, they book a meeting. The meeting takes thirty minutes to schedule, thirty to hold, and produces a decision three people would have reached in five minutes each — if they had been asked separately, at a time that suited them, with the same information in front of them.

Most team decisions are exactly that shape. Which of three vendors. Which week for the offsite. Which of four names for the feature. Whether the Tuesday standup should move. They need input from several people, they don't need those people in the same room, and they mostly don't need a discussion at all — they need answers, added up honestly, with a reason attached.

The shape of an async decision

An asynchronous decision that actually works has five parts, and skipping any one of them is how "let's just do it in Slack" ends up back in a meeting:

  1. A fixed set of options, written down once, the same for everyone.
  2. The same few questions asked of each person — not a free-text thread where everyone answers something different.
  3. Private answers, so the second person to reply isn't reacting to the first.
  4. A deadline and a closer — one person, or one moment, at which the answer becomes final.
  5. A result with reasons, so the people who didn't get their preference can see why.

That is a room. You make one, paste the options, share the link in the channel, and say "answer by Thursday". Everyone answers when they're awake and free. On Thursday, you close it.

Two questions are enough

For most team decisions, a custom room's two questions do the job:

  • How do you feel about this option? One to five, per option. It separates "I'd pick this" from "fine" from "please not this".
  • Is it a no-go for you? One veto per person, with a one-line reason. It removes the option for the whole team, and the results page says who used it and why.

The second one matters more than it looks, and it is scarce on purpose: with one veto each, people spend it on the thing they truly can't accept rather than on everything they'd mildly prefer to avoid. Teams have a lot of quiet "no"s — the engineer who knows the vendor's API is a nightmare, the person who has a hard commitment the week of the proposed offsite. In a thread, those come out late or not at all. In a room they come out first, by design, and the decision is made among the options that were actually viable.

Add a note at the end for anything a question didn't cover. It isn't scored; it's read.

Who closes it, and what if they're asleep

The host — whoever made the room — closes it. Closing freezes the result: the number, the ranking, the reasons, all stored as they were at that moment, so a late answer can't rewrite a decision people have already acted on.

Distributed teams have a specific problem here: the host is in one time zone and Thursday ends in another. So a host can delegate closing to someone else by email — a colleague eight hours ahead accepts the invitation and gains exactly one power: to close this room. They can't change it, can't see anyone's answers, can't manage anything else. When they close it, the result is frozen just as if the host had.

A host can also be told when someone answers, by email or by message, so "has everyone replied yet?" stops being a thing anyone has to ask.

What the team sees

Nobody sees anyone else's answers. The host can see who has answered — so they know who to nudge — but not what. When the room closes, everyone with the link sees the same page: the option the team can live with, the runners-up, anything that was ruled out with the reason, and a bar showing who is delighted and who is compromising.

The reasoning is the part that makes async work. A decision handed down in a meeting is accepted because people were in the room when it was made. A decision handed down in a thread is often not accepted, because it looks like whoever wrote the summary picked what they wanted. A results page that says Four of five are happy with this one and Dan isn't sold on it is neither — it is the team's own answers, added up in the open.

When it isn't enough

Some decisions genuinely need a conversation: the ones where the options aren't known yet, or where the point is to change someone's mind rather than to count it. A room won't help there, and it shouldn't try.

But most of what a team books meetings for isn't that. It's a choice between things that already exist, made by people who already know what they think. Ask them, add it up, and give the thirty minutes back.

And the meeting you do need

When a real meeting is required, finding the time for it is itself a decision the same shape — and a meeting room handles it: everyone paints their availability in their own time zone, and the room offers the times that actually work for the whole team, scoring each person by their worst moment in the slot rather than their average. More on that here.

Try it on a real decision.

A room takes about two minutes to set up and needs no account. Send the link and see what the group actually agrees on.

Read next