Async decisions get re-litigated when the team doesn't believe they're real. "Are we still going with X?" "Did we ever actually decide?" "Let's revisit." The fix is not more discussion — it's structural clarity about what makes a decision binding. Four properties separate decisions that stick from decisions that unravel.
What makes an async decision binding
Four properties:
- Named authority — the specific person or group who decided.
- Scope — what the decision covers and what it doesn't.
- Reversibility — what would change the decision, and who would reverse it.
- Durable record — somewhere stable, queryable, visible.
Miss any one and the decision will be questioned within weeks.
Name the authority explicitly
"The team decided" is not authority. "Maria decided after a 48-hour RFC window with 4 engineers commenting" is authority. Naming who decided locks in accountability and prevents the "who actually called this" confusion that triggers re-litigation.
If you can't name the decider, the decision wasn't made — it was discussed.
Define the scope precisely
Scope is what stops the decision from being interpreted out of bounds. "We will use Postgres for the billing service" — clear. "We're going database-first" — too broad; will be misapplied to unrelated systems.
Tight scope makes the decision durable. Loose scope makes it endlessly negotiable.
Make reversibility a field, not a debate
Every binding decision answers: what would reverse this? "Reverse if latency exceeds 200ms at p95." "Reverse if we move off AWS." "Reverse with sign-off from EM + tech lead."
This single field eliminates 80% of re-litigation. Without it, anyone can propose reversal at any time. With it, reversal has a bar — and the bar either gets met or doesn't.
Put the record in a durable, queryable place
Slack threads don't bind. They scroll, archive, and become invisible. The record needs a stable URL, structured fields, and team-wide accessibility.
The act of putting a decision somewhere durable is itself part of what makes it binding — the team treats records-that-exist differently than discussions-that-happened.
Set a clear decision window for async votes
For decisions that need team input, use a structured window: "This decision will be made by Maria on Thursday at 14:00 UTC. Async comments welcome before then. Silence is implicit approval."
Without the window, comments trickle in for weeks and the decision stays in suspended animation.
Async Decisions That Stick
StandIn binds async decisions to declared state — with named authority, scope, and reversibility — so they don't unravel in DMs.
See the Workflow →Distinguish input from veto
Async decisions invite input from the team. They don't grant veto. The decider listens, weighs, decides. Engineers who confuse input with veto will hold decisions hostage with "I didn't agree." Make the distinction explicit.
The mechanism: input is welcome up to the deadline; after the deadline, the decision is binding. Reversal requires meeting the reversibility threshold, not just expressing disagreement.
Re-binding for new context
Sometimes new information genuinely warrants reconsideration. The right path: someone proposes reversal, citing the reversibility criteria. If the criteria are met, the original decider (or current owner) issues a new decision and supersedes the old one. The record now shows both, in sequence.
This is healthy. What's not healthy is reversal-by-attrition — slowly drifting away from the decision without anyone calling it.
Common failure modes
Failure: leaving authority implicit. Decisions without a named decider are decisions waiting to unravel.
Failure: requiring consensus instead of authority. Consensus async takes forever and produces weakest-link outcomes. Authority is faster and more durable.
Failure: revisiting decisions in every retro. Retros should improve process, not re-decide. If a decision keeps coming up, fix the reversibility criteria, don't keep re-deciding.
What to do tomorrow
Take the most recent async decision your team made. Write it in the four-field format: decision, authority, scope, reversibility. Place it somewhere durable. Send the link to the team channel. Notice how the next "are we still going with X?" gets handled differently.
Frequently asked questions
What if engineers keep proposing to revisit a binding decision?
Either the reversibility criteria are too loose, or the decision itself was wrong. Tighten the criteria or examine the decision honestly. Persistent re-litigation is a symptom worth diagnosing.
Should we vote on async decisions?
Voting is rarely the right mechanism for engineering decisions — it produces middle-ground compromises that often don't work. Use named authority with structured input instead.
How long should the async comment window be?
48 hours covers most timezones. 72 if engineers in distant zones are heavily affected. Longer than 72 invites delay; shorter excludes voices.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.