Async decision making is the practice of reaching and recording a choice without everyone being in the same meeting at the same time. The frameworks that work share one trait: a named person owns the call, input has a deadline, and the result lands somewhere you can ask about it later. A framework that produces a decision nobody can find in three months did not actually make a decision, it just delayed an argument.
Most teams pick a method like RFC or disagree and commit and assume the method is the hard part. It is not. The hard part is what happens after the call is made. If the reasoning lives in a thread that scrolls away, the framework fails quietly, and the same question comes back wearing a different name.
What are the main async decision making frameworks?
A framework is a repeatable way to gather input, assign ownership, and close a decision so people stop relitigating it. Four of them cover most of what distributed teams need, and each fits a different kind of choice.
The DRI model names one Directly Responsible Individual who makes the call after hearing the team. It works best when speed matters and the choice is reversible. The RFC (Request for Comments) writes the proposal down first, opens it for written feedback over a set window, then closes it with a decision. It suits larger, harder-to-reverse choices where the reasoning needs to be visible. Disagree and commit lets the team voice objections, then asks everyone to back the chosen path even if they would have picked differently, which keeps a decision from stalling on consensus that will never arrive. Time-boxed input sets a hard deadline for feedback, after which silence counts as assent and the owner proceeds.
None of these is better than the others in the abstract. They are tools for different jobs, and the trap is using a heavyweight RFC for a choice that needed a DRI and an afternoon.
Which framework fits which decision?
The fit depends on two things: how reversible the choice is, and how much the reasoning needs to be on the record for people who were not in the room.
| Framework | Best for | Who owns it | What gets recorded |
|---|---|---|---|
| DRI | Fast, reversible calls | One named individual | The call and a short why |
| RFC | Big, hard-to-reverse choices | Author plus reviewers | Full proposal and the debate |
| Disagree and commit | Decisions stuck on consensus | The decider, after objections | The call and who dissented |
| Time-boxed input | Choices that drift without a deadline | The owner who set the clock | The decision and the cutoff date |
Read the table as a starting point, not a rulebook. A reversible call with one clear owner does not need a week of comments. A choice that will shape the architecture for two years deserves the written debate an RFC forces, because the reasoning is the part future teammates will need most.
Why do async decisions disappear so often?
Because making the decision and recording it in a way you can retrieve are two different acts, and most processes only do the first. The DRI announces the call in a channel. The RFC closes with a thumbs-up emoji. The disagree-and-commit moment happens on a call nobody captured. The decision was real, but it left no trace anyone can query.
A few weeks later someone new asks why the team chose the queue over a cron job, and the honest answer is that nobody remembers and the thread is gone. So the team reopens the question, which is the exact thing the framework was supposed to prevent. The framework did its job in the moment and then the moment evaporated.
This is the gap that quietly wastes the most time on distributed teams. We wrote more about where it slips during transitions in engineering team handoffs and context loss. The pattern is the same: the choice was made, the reasoning was sound, and none of it survived contact with the calendar.
How does a queryable record make a framework stick?
A decision record is a system that answers who decided something and why, with a named source the person stood behind. The framework decides; the record makes the decision retrievable on demand, long after the deadline passed and the channel scrolled.
Here is how the two fit together. Your team runs whatever framework suits the choice. When the call lands, the owner declares it: a short statement of what was decided and the reasoning, vouched for by the person who made it. Declaring is the human step where someone says "yes, this is my decision, quote me on it." From then on, anyone can ask the record a plain question and get that person's own words back, with their name and the date attached.
The named author is the part that matters most. A decision with no owner is just an opinion that happened to win, and when it goes wrong nobody is accountable for it. A decision with a named source tells you who to follow up with and what they were actually weighing at the time.
There is one more property worth naming. A good record can tell you when no decision exists. If someone asks about a choice the team never actually made, the answer is "no record," not a confident guess. That refusal is information. It tells you the question is still open and points you to the person who would own it, instead of letting a phantom decision drive real work.
How do I start using these frameworks asynchronously?
Start small and pick one framework per kind of choice, so people are not guessing which process applies. Reversible calls get a DRI. Architectural calls get an RFC. Anything stuck in endless debate gets disagree and commit with a deadline.
Then add the one habit that makes any of them durable: the owner declares the decision when it closes. Not a separate document nobody opens, but a short, named entry the team can query later. If your team already runs async standups, that is a natural place for it, since standups generate decisions constantly and usually throw them away. Our roundup of the best async standup tools for 2026 covers which tools keep the decision and which only summarize the status.
You can see the full path, from making a person's work discoverable to declaring a decision to querying it later, in how StandIn works.
Frequently Asked Questions
What is async decision making?
It is reaching and recording a choice without requiring everyone to be present at the same time. A named owner gathers input on a deadline, makes the call, and records it where people can ask about it later.
Which async framework is best for a remote team?
There is no single best one. Use a DRI for fast reversible calls, an RFC for big hard-to-reverse ones, disagree and commit when consensus stalls, and time-boxed input when decisions drift without a deadline.
Why do async decisions get relitigated?
Usually because the decision was announced but never recorded in a retrievable way. The thread scrolls away, nobody remembers the reasoning, and the team reopens a question it already answered.
Does StandIn make decisions for me?
No. It answers only from records you declared, in your own words, with your name attached. If you never stood behind a decision, it points the asker to you or says there is no record.
What happens when someone asks about a decision we never made?
You get a clear "no record" instead of an invented answer. That tells you the question is still open and shows who would own it.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to retire your daily standup?
Distributed teams use StandIn to start every shift with full context, no standup required. Engineers publish a 60-second brief. The next shift wakes up knowing exactly what to work on.