An RFC process is a way for engineering teams to propose a change in writing, gather feedback from the right people, and reach a decision everyone can see. RFC stands for "request for comments." Run async, it lets people weigh in on their own schedule, and the point of the whole exercise is the decision it produces, which should land in a record you can query later rather than a document that goes stale the moment it is approved.
Most teams adopt RFCs because they are tired of important changes happening in a hallway conversation or a meeting half the team missed. The RFC fixes the visibility problem, but it introduces a quieter one: the approved RFC becomes a tomb. The decision is buried on page four, the doc never gets updated, and six months later someone reopens the exact debate the RFC was supposed to settle. The process is only as good as how findable its outcome is.
What is an RFC process?
An RFC process is a written workflow where an author drafts a proposal, reviewers comment on it, and the group converges on a decision before the work begins. The document is the request for comments. It usually states the problem, the proposed approach, the alternatives considered, and the tradeoffs, so reviewers can argue with the reasoning instead of reacting to a finished change.
The goal is not the document. The goal is a decision that people understood and agreed to, made visible enough that nobody can later claim they were blindsided. A good RFC process front-loads the disagreement, so the argument happens on the page before the code exists, when changing course is cheap.
How do you run an RFC process async?
You run it in stages, with each stage having a clear owner and a clear deadline, so the lack of a meeting never means the lack of progress.
Start with a draft. The author writes the proposal in full, including the alternatives they rejected and why, because the rejected options are usually where the real debate lives. A thin RFC that only describes the favored approach forces reviewers to reverse-engineer what else was on the table.
Then open comments for a fixed window. Give reviewers a real deadline, a few days at least, so people in other time zones can read and respond without a scramble. Async review beats a meeting here because written comments are specific, threaded, and permanent. Naming a clear decision owner up front keeps the thread from drifting, the same discipline behind durable async handoffs.
Resolve and decide. The author addresses each comment, the decision owner makes the call, and the outcome gets recorded as a decision, not just as an approval checkbox. This last step is the one teams skip, and that is why RFCs rot.
Why do approved RFCs become stale docs?
An approved RFC freezes at the moment of approval, but the decision it carries has a long life. The doc says what the team intended to do in March. It does not say what the team actually shipped, what changed during implementation, or whether the call still holds after the constraint that forced it disappeared. So the document drifts out of sync with reality, and people stop trusting it.
There is also the findability problem. An RFC's decision is wrapped inside a long proposal full of context that mattered during review and matters far less afterward. Months later, someone with a simple question, "did we decide to deprecate the v1 endpoint or not," has to read the whole thing to extract one sentence. They ask in chat, get a half-remembered answer, and the RFC might as well not exist.
The fix is to separate the proposal from its outcome. The RFC document is the deliberation, which is fine to leave frozen, because it is a snapshot of a debate that already happened. The decision is the durable part, and it needs to live somewhere queryable on its own, with a named owner and a clear status.
How should an RFC's decision become a queryable record?
The decision an RFC produces should be captured the way you would capture any decision record: the choice, who made it, and the reasoning at the time, declared by the person accountable for it.
This is where StandIn fits. StandIn auto-indexes your work, so the RFC and the discussion around it are discoverable and pointable. That handles search. But indexing alone does not make a decision trustworthy, because an indexed draft is just text that may or may not reflect a real, final call. Declaring is the separate human step: the decision owner vouches for the outcome as theirs, saying "yes, we are going with this approach, you can quote me." A declared decision can answer a plain question with a named source, while an unread doc can only sit there.
The payoff shows up when someone asks the record "what did we decide about the auth rewrite." They get the decision, the owner, the reasoning, and a link to the RFC it came from, sourced to a person who stood behind it. Ask about something nobody decided, and the record says "no record," which tells you the question is genuinely open rather than handing you a confident guess pulled from a draft. You can see the full path from indexing to declaring to querying in how StandIn works.
Approved RFC doc vs. a queryable decision record
| What you need | Approved RFC doc | Queryable decision record |
|---|---|---|
| Find the actual decision | Read the whole proposal | Ask a plain question |
| Know who is accountable | Often an approval checkbox | A named owner on the answer |
| See if it still holds | Frozen at approval | A current, declared status |
| When nothing was decided | A draft that looks final | A clear "no record" |
| Source of the answer | A long document | The owner's declared words |
The right column does not replace the RFC. It rescues the one thing inside it people actually need later.
Does running RFCs async slow teams down?
It feels slower and usually is not. A synchronous decision happens fast in the room and then unravels slowly afterward, in re-litigation and in the person who missed the meeting quietly building the opposite thing. An async RFC spends a few extra days up front and saves weeks of that drift, because the reasoning is written down and the decision is findable.
The speed comes from not having to rediscover the decision. When the outcome lives in a queryable record, a new engineer reads the call and the reasoning in seconds instead of booking time on three calendars to ask why the system looks the way it does. The RFC pays for itself the first time someone gets their answer from the record instead of from a meeting that never gets scheduled.
Frequently Asked Questions
What does RFC stand for?
RFC stands for "request for comments." It is a written proposal an engineer circulates so the team can comment before a change is built, and converge on a decision in the open.
How is an async RFC different from a meeting?
An async RFC gathers written, threaded, permanent comments on a fixed deadline, so people across time zones can weigh in carefully. A meeting produces fast verbal agreement that is hard to find or trust later.
Why shouldn't the approved RFC be the final record?
An approved RFC freezes at approval and buries its decision inside a long proposal. The decision needs to live in a queryable record with a named owner and a current status, so people can find it without rereading the doc.
Does StandIn write RFC decisions for me?
No. It indexes your RFCs so they are discoverable, but it only treats an outcome as an answer when the owner declares it. It never invents a decision, and it says "no record" when none was declared.
Who should own an RFC decision?
One named person, the decision owner, who makes the final call and stands behind it in the record. Committee approval without a single owner is exactly what leaves a decision unaccountable later.
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.