The Problem with “Let’s Sync About It”
In my 15 years working with and studying distributed teams, I’ve watched the same pattern repeat. A decision needs to be made. Someone says “let’s schedule a meeting to discuss.” The meeting gets added to three people’s calendars across four time zones. Someone can’t make it. The meeting gets rescheduled. By the time everyone finally gets on a call, half the time is spent catching people up. The actual decision takes 10 minutes.
Harvard Business Review research shows that the average executive spends 23 hours a week in meetings, up from less than 10 hours in the 1960s. For remote teams, the problem is compounded by time zones—there’s literally no good time for everyone to meet. The default answer to every question becomes “let’s sync,” and before you know it, the team is spending more time scheduling decisions than making them.
The solution isn’t more meetings. It’s a structured approach to asynchronous decision-making that lets teams move fast even when nobody is online at the same time.
Why Async Decisions Make Teams Better
Teams that master async decision-making see benefits that go beyond just fewer meetings. Research on distributed teams consistently shows that well-designed async processes improve decision quality, not just speed.
Better input from everyone. In live meetings, the loudest voice or the most senior person often drives the outcome. Async gives introverts, night owls, and people in less-represented time zones equal opportunity to contribute. The quality of the decision goes up because you’re hearing from more people, not just the ones who think fast on a call.
Decisions get made on time. When you set a deadline and a decision-maker, the decision happens. No waiting for everyone’s schedule to align. No “can we push this to next week?” because someone is out. The deadline creates accountability, and accountability creates momentum.
A record of why. Every async decision produces documentation—the proposal, the feedback, the rationale. This isn’t bureaucracy; it’s institutional memory. Six months from now, when someone asks “why did we choose this approach?” you don’t have to rely on fading recollection. You have the decision log.
McKinsey’s 2024 State of Remote Work report found that companies with structured async decision processes make decisions 25% faster and report higher team satisfaction with the quality of those decisions. The speed comes from removing coordination overhead; the quality comes from better, more thoughtful input.
The Async Decision Framework
Over the past decade, I’ve helped dozens of remote teams build async decision practices. The framework that emerges is always a variation of the same six-step structure. It’s simple enough to start using next week, and robust enough to handle decisions with millions of dollars on the line.
Step 1: Frame the Decision
The single biggest cause of slow decisions is fuzzy framing. “What should we do about our onboarding process?” is not a decision—it’s a topic. “Should we switch from our current onboarding tool to Tool X, with a budget of $5,000 per year, by end of quarter?” is a decision.
A well-framed decision brief includes:
- The decision itself, stated as a specific question with concrete options
- Why it matters — the business impact, the problem being solved
- The desired outcome — what success looks like after the decision is implemented
- The deadline — when the decision needs to be made
- Background context — links to relevant docs, prior discussions, data
The sharper the framing, the less time people spend asking clarifying questions and the more time they spend giving useful feedback.
Step 2: Assign Clear Roles
Not everyone gets equal say in every decision, and pretending otherwise is how you get 30-person threads going nowhere. Every async decision needs three role categories:
Decision-maker (1 person). This is the person who makes the final call. They’re accountable for the outcome. Not a committee. Not a vote. One person. For small decisions, this might be the team lead. For bigger decisions, it might be a department head or the CEO.
Stakeholders (2-5 people). These are people whose input matters because the decision affects their work or they have relevant expertise. The decision-maker is expected to consult them, but isn’t bound by consensus.
Informed (everyone else). These people don’t give input—they just need to know what was decided and why. Copy them on the announcement, don’t drag them into the process.
Clarity about roles is kind. It tells people exactly what’s expected of them, and prevents the anxiety of “am I supposed to have an opinion here?”
Step 3: Propose Concrete Options
Open-ended questions kill momentum. “What do you think about our project management tool?” invites rambling, pet peeves, and tangents. “Here are three options for our project management tool, with pros and cons for each—what stands out to you?” invites focused, useful feedback.
The decision-maker or proposer should outline 2-3 specific options, each with:
- A clear description of the option
- Pros (why it’s good)
- Cons (trade-offs and downsides)
- Costs (time, money, effort)
- Expected impact (how it moves the needle)
Options don’t need to be exhaustive. They just need to be real alternatives that someone could actually choose. One of them can be “keep things as they are”—the status quo is a legitimate option and explicitly including it forces people to justify change.
Step 4: Collect Structured Feedback
Once the proposal is out, set a feedback window—typically 24-48 hours for most decisions, longer for bigger ones. Share it in the right channel (a specific Slack channel, a Notion page, a threaded discussion) with a clear deadline.
Ask for feedback in a structured way:
- Agreement — “I support Option A because…”
- Concerns — “I’m worried about X because…”
- Suggested changes — “What if we modified Option B to include…”
Structured feedback prevents meandering threads. It also makes it easy for the decision-maker to scan and synthesize input instead of reading a 50-message Slack thread.
A few ground rules: no lobbying in DMs. All feedback goes in the shared thread so everyone can see it. People can build on each other’s input, but they can’t form factions behind the scenes. If someone needs more time, they have to say so before the deadline with a reason and a proposed extension.
Step 5: Make the Call
When the feedback window closes, the decision-maker makes the decision. This is the most important step and the one teams often skip by trying to reach consensus.
Consensus sounds nice in theory—everyone agrees, everyone’s on board. In practice, consensus means the decision gets watered down to whatever offends the fewest people, and it takes forever.
The decision-maker’s job is to:
- Read all the feedback
- Weigh the trade-offs
- Make a choice
- Document the rationale
The rationale doesn’t need to be a novel. A few sentences explaining why they chose what they chose, and what factors they weighed most heavily, is enough. The point isn’t to convince everyone—it’s to be transparent about how the decision got made.
People don’t need to agree with every decision. They need to understand why it was made and trust that the process was fair.
Step 6: Communicate and Follow Up
A decision that isn’t communicated might as well not have been made. Announce it clearly to everyone affected: the decision, the rationale, who was consulted, and when it goes into effect. Include a link to the full decision log for anyone who wants the details.
Then follow up. Good decisions are evaluated, not forgotten. Set a check-in date—30 days, 90 days, whatever makes sense for the scope of the decision. At that check-in, ask:
- Is the decision delivering the expected outcome?
- What have we learned since we made it?
- Should we stick with it, adjust it, or revisit it?
This follow-up loop turns decisions from one-time events into ongoing learning. It also gives people who disagreed with the decision a structured way to revisit it with new data, instead of rehashing the same arguments in every meeting.
Decisions That Should Stay Synchronous
Async isn’t the answer to everything. Some decisions genuinely benefit from real-time conversation:
Crisis situations. When something’s on fire and you need to respond in hours, not days, get on a call. Async is too slow for emergencies.
High-stakes strategic decisions. Company direction, major pivots, large budget calls—these often benefit from live discussion where people can challenge assumptions in real time. You can still do pre-reading and async prep, but the final call often happens in a room (virtual or otherwise).
Complex trade-offs with no clear answer. Sometimes you don’t know what you think until you talk it through. If a decision involves tangled interdependencies and no obvious path, a focused live discussion can untangle it faster than days of async back-and-forth.
Performance and sensitive conversations. People deserve real-time conversations about their performance, their role, or difficult feedback. Don’t deliver bad news asynchronously.
For everything else—most operational decisions, tool choices, process changes, roadmap prioritization—async is faster, more inclusive, and produces better documentation.
Getting Started with Your Team
You don’t need to overhaul your entire process to start making decisions asynchronously. Pick one decision this week and try the framework. A small decision—say, choosing a new team lunch tool or deciding on a date for the next offsite—is the perfect test case.
Write a brief. Assign a decision-maker. Propose options. Collect feedback. Make the call. Document it. See how it goes.
Most teams are surprised by how well it works the first time. The decision gets made faster than scheduling a meeting would have taken. More people contribute. And you have a record of why you chose what you chose.
Over time, as the team gets comfortable with async decisions, you can expand to bigger and more consequential calls. The goal isn’t to eliminate meetings entirely—it’s to stop using meetings as the default way to make decisions, and reserve them for the conversations that actually need real-time interaction.
The best remote teams I’ve worked with don’t have fewer decisions—they have better decision processes. Async decision-making is one of the highest-leverage practices you can adopt. It takes a little structure, but the payoff in speed, quality, and inclusivity is enormous.
