shane.
shane.
Early access

Give your AI your team’s memory.

We’re letting the first teams in now. Leave your work email and we’ll be in touch.

← BlogTeam knowledge

Async decision-making for remote teams that use AI

A simple async decision process for remote teams: one owner, a one-page proposal, a comment deadline and a recorded outcome, plus where AI helps and where it doesn't.

Async decisions for remote teams: a decision thread on the launch date, marked decided, with the team who weighed in.

Async decision-making means a remote team decides in writing, on a deadline, without needing everyone in the same meeting. It works when every decision has one owner, a short written proposal, a fixed comment window and a recorded outcome. AI helps with the drafting and summarizing, but a named person still makes the call.

Remote teams that use AI have a new reason to get this right. If a decision only exists in a call, your AI tools never see it, and they'll keep giving answers based on the old way. This guide covers a simple async process and where AI fits into it.

Why decisions stall on remote teams

Most remote decisions don't fail because people disagree. They fail because nobody knows who decides, when the discussion ends or where the outcome went. Common patterns:

  • The endless thread. Forty replies in Slack, three good ideas, no conclusion.

  • The meeting to schedule the meeting. Five people across three time zones wait a week for a 30-minute slot.

  • The silent decision. Two people agree in a DM. Everyone else finds out when something ships.

  • The reopened decision. A choice gets made, then argued again a month later because nobody can find the reasoning.

Each one wastes time. The last two also leave your AI tools with the wrong picture of how things work.

The four parts of an async decision

1. One owner

Every decision needs one person who makes the final call. GitLab's public handbook calls this a directly responsible individual, or DRI. The owner doesn't need consensus. They need to hear the input, then decide.

2. A written proposal

The owner writes a short proposal. One page is plenty. A written proposal lets people in other time zones respond with the same information as everyone else.

3. A comment window

Set a deadline for input, usually two to five working days depending on the size of the decision. Say what happens if nobody objects: "If there are no blocking concerns by Thursday 5pm UTC, we go ahead."

4. A recorded outcome

When the window closes, the owner writes down what was decided and why, and puts it where people and AI tools look. A decision in a thread is half made. See how to keep a decision log for the format.

A proposal template that fits on one page

Section

What to write

Example

Decision needed

One sentence, phrased as a question

Should we move customer onboarding calls from live to recorded videos?

Owner and deadline

Who decides, and when input closes

Priya, input closes Thursday 5pm UTC

Context

Why this matters now, in a few lines

Onboarding calls take 12 hours a week. Most questions repeat.

Options

Two or three real options, with trade-offs

Keep live calls. Move fully to video. Video plus a weekly live Q&A.

Recommendation

What the owner plans to do, and why

Video plus weekly Q&A: saves most of the time, keeps a human touchpoint.

What I need from you

The specific input wanted

Blocking concerns, and any customer segment this would hurt.

The example is made up. The "what I need from you" line does a lot of work. It tells people whether to approve, object or just read.

How to comment on a proposal

Async decisions go faster when everyone uses the same signals. Agree on three kinds of response:

  • Support. "Agree" or a short note. No need to explain.

  • Concern. "I'd do X differently because Y." The owner considers it but can go ahead.

  • Block. "This will break Z, and here's why." Blocks should be rare and must include a reason.

Ask people to comment on the proposal itself, not in a side channel. If a real debate breaks out, the owner can call a short meeting, but the meeting is for the hard part only. The outcome still goes back into writing.

Where AI fits

AI tools are good at the parts of async work that take time and need no authority. They're bad at the parts that need judgment and accountability.

Good uses

  • Turn a messy thread into a draft proposal. Paste the thread and ask: "Summarize the decision being discussed, the options mentioned and who supports which."

  • List the objections. Before the deadline, ask AI to pull every concern from the comments into a short list, so the owner can respond to each one.

  • Check for conflicts. Give the AI your decision log and the new proposal, and ask whether it contradicts anything already decided.

  • Write the outcome. After the owner decides, AI can draft the log entry and the announcement in a consistent format.

Things AI shouldn't do

  • Make the decision. A summary can't weigh a concern from your biggest customer against a cost saving. The owner does that.

  • Count votes. Async decisions aren't polls. An AI tally of "8 agree, 2 concern" hides the one comment that matters.

  • Replace reading. The owner should read the comments, not only the summary. Summaries drop the quiet, important detail.

Make the outcome reach your AI tools

This is where many teams fall down. The decision gets made in a doc, announced in Slack, and never reaches the places AI tools read. Then a teammate asks ChatGPT or a coding agent a question, and it answers based on the old way. Record each outcome in one place your AI tools can search, and mark replaced decisions as replaced. Knowledge silos in the AI era covers why this gets worse as teams add tools.

A week of async decisions in practice

Here's how a single decision might run for a team spread across London, New York and Singapore:

  1. Monday: Priya pastes a long Slack thread into an AI tool, gets a draft proposal, edits it and posts it with a Thursday deadline.

  2. Tuesday: Teammates in each time zone comment during their own working day. One person raises a concern about enterprise customers.

  3. Wednesday: Priya asks AI to list all concerns, replies to each one, and adjusts the plan to keep live calls for enterprise accounts.

  4. Thursday: No blocks. Priya writes the decision, AI drafts the log entry, and she posts a short announcement with a link.

No meetings, and anyone who joins next quarter can see exactly what was decided and why.

FAQ

Which decisions should stay synchronous?

Urgent decisions, sensitive people issues and decisions with deep disagreement after the first round of comments. Even then, write the outcome down afterwards.

How long should the comment window be?

Long enough for every time zone to get at least one full working day. For most decisions, two to five working days is enough. Reversible decisions can move faster.

What if nobody comments?

Silence by the deadline means the owner goes ahead. Say this in the proposal so nobody is surprised.

Can AI summaries of meetings count as decisions?

Not on their own. A summary records what was said. A decision needs an owner to confirm it. See meeting notes are not memory.

Decide in writing, once

Async decisions work when the process is boring: one owner, one page, one deadline, one recorded outcome. AI makes each step faster, but only if the result ends up where your team and its tools can find it. We're building Shane to keep each decision with its owner, reasoning and status, and hand it to every teammate and AI tool that needs it. If that's a problem your team has, you can join the waitlist at tryshane.ai.