Making Decisions Async Without Them Getting Reopened

Making a decision asynchronously is straightforward. Making one that stays made is the hard part, and it fails in three predictable ways, none of which are about the decision itself.

"We decided it on Tuesday and re-decided on Thursday."

Three ways an async decision fails to close

• Nobody decided. A thread reaches rough consensus and stops. No line says "so we are doing X". Everyone leaves with a slightly different impression, all of them defensible.
• The scope is unstated. "We will use the shared queue" could mean for this feature, for this quarter, or forever. Each reader assumes the scope that suits their work, and the disagreement surfaces later as a surprise.
• It is unfindable. The decision was made clearly, in a thread, in a channel, in April. In August a new joiner cannot find it, so they raise the question in good faith and the team relitigates it.

The third is the most common by a wide margin, and it is worth dwelling on because it is usually misdiagnosed as people being difficult. It is not disagreement. It is retrieval failure, and the same dynamic is the subject of why decisions keep getting revisited.

Closing a decision in four lines

Whoever owns the decision writes this in the thread where it was discussed, and nowhere else initially.

The fourth line is the one that stops relitigation, because it answers the question that drives most of it: am I allowed to argue about this? "Changeable by Priya, or with evidence of X" tells a newcomer both that the question is settled and what would legitimately unsettle it. That is a much better outcome than a decision that feels either permanent or endlessly negotiable depending on who asks.

Silence is not agreement, unless you say so

Async decisions stall waiting for explicit agreement from people in other zones. State the rule instead: a decision proposed with a deadline is decided at that deadline unless someone objects, and objecting requires a reason, not just a preference.

Two things make this work. The deadline must allow a full working day in every affected zone, which for three zones means at least 48 hours. And the proposal must be findable by the people it affects, which means posting it where they read rather than where you write. A proposal posted in a channel that one zone does not follow is not a proposal, it is a formality.

Record-keeping that survives a month

Every team that suffers from reopened decisions eventually builds a decision log, and most of those logs stop being updated within a quarter. The reason is that the log is a second place to write something, after the place where the decision actually happened, and the second write has no immediate benefit to the writer.

What works is making the decision retrievable from where it was made. With StandIn, the decision you wrote down in your brief is what your StandIn answers from: someone asks "what did we decide about the queue" and gets your words with a source under them, whether you are in a meeting, at lunch, or asleep. It never guesses, and if the decision is not in the record it says so and names who to ask, which is itself useful information.

That changes the incentive. Writing the decision clearly pays back the first time someone else would have asked you about it, rather than paying back in a quarterly audit nobody performs. See how StandIn works.

When reopening is correct

Not all reopening is waste, and a team that cannot revisit anything is worse off than one that revisits too much. Three legitimate triggers: the facts changed, the decision is producing a harm nobody predicted, or the person who made it did not have the authority.

Write those triggers down alongside the decision format, because the goal is not fewer reversals, it is fewer accidental ones. A decision reversed deliberately with new information is a working team. The same decision made three times by three people who could not find the first two is a retrieval problem wearing the costume of a disagreement.

Common Questions

How long should we wait for input on an async decision?

Long enough for one full working day in every affected time zone, so 48 hours for a three-zone team. State the deadline in the proposal and state that silence counts as consent, otherwise decisions drift for a week waiting for people who had no objection.

Who should make the decision if the team disagrees?

The named owner for that area, and the name should exist before the disagreement rather than being negotiated during it. Undocumented authority is the most reliable source of reopened decisions, which is why the DRI question belongs in the DRI model in distributed teams.

Where should decisions be recorded?

Where the discussion happened, in a form that can be found later by someone who was not there. A separate log is fine if it is genuinely maintained, and a second place to write is usually the reason it is not.

What about decisions that are hard to reverse?

Those deserve a live conversation and a written proposal in advance. Reserve the expensive process for the expensive decisions, and let reversible ones be made quickly by their owner with the four lines. Treating every decision as irreversible is how teams end up unable to decide anything async.