RFC means Request for Comments: a written proposal that a team circulates so people can react to it before a decision is made. In a team-process sense, an RFC is the document where someone lays out a change they want, explains the reasoning, and invites others to push back, ask questions, or agree. The point is to get the thinking on paper, gather input, and reach a decision that everyone can see and trace later.
The phrase started in the early internet standards world, where RFCs were numbered documents that defined how the network would work. Engineering teams borrowed the idea and made it lighter. Today an RFC is usually an internal doc, not a public standard, but the spirit is the same: write the proposal down, let people comment, then decide.
What does RFC stand for and where did it come from?
RFC stands for Request for Comments. The term comes from the documents that defined internet protocols starting in 1969, where each proposal got a number and stayed open for feedback from anyone working on the network. The name was deliberately humble. Calling something a "request for comments" rather than a "specification" signaled that it was open for discussion, not handed down.
Teams kept that humility when they adopted the format. An RFC is a proposal, not a verdict. It says "here is what I think we should do, and here is why, now tell me where I am wrong." That framing matters, because it invites the disagreement that makes the final decision stronger.
How is an RFC used in a team process?
In practice, an RFC follows a simple arc. One person writes up a proposed change: a new service, a database migration, a policy, an API shape. They explain the problem, the options they considered, the option they recommend, and the tradeoffs. Then they share it with the people affected and ask for comments. Those comments come in as inline notes, threaded replies, or a synchronous review meeting. After the discussion settles, someone records the decision: accepted, rejected, or revised.
A good RFC usually covers a few standard parts.
| Section | What it answers |
|---|---|
| Context | What problem are we solving, and why now? |
| Proposal | What exactly do we want to do? |
| Alternatives | What else did we consider, and why not those? |
| Tradeoffs | What do we give up, and what risks remain? |
| Decision | What did we choose, who approved it, and when? |
The first four sections are the input. The last one is the output, and it is the part teams most often forget to capture cleanly. A thread full of comments is not a decision. The decision is the single line that says what was chosen and who stood behind it.
We wrote a fuller walkthrough of running this end to end in our guide to the RFC process for engineering teams, if you want the operational version.
Why does an RFC beat deciding in a meeting or a chat thread?
A meeting decides in real time, which means only the people in the room hear the reasoning, and the reasoning evaporates when the call ends. A chat thread captures the back-and-forth but buries the conclusion under a hundred messages, so six months later nobody can tell what was actually decided or whether it stuck.
An RFC fixes both problems by separating the discussion from the record. The comments live in the document while it is open. The decision gets written down as a clear statement when the document closes. Anyone who joins later can read the proposal, see the objections, and find the resolution in one place, without having to reconstruct it from memory or scrollback.
That is the real value of the format. It is not the writing for its own sake. It is that a written proposal produces a written decision, and a written decision is something a person can stand behind by name.
How should the decision from an RFC be queryable later?
Here is the part most teams miss. Writing the RFC is the easy half. The hard half is making sure that, a year later, someone can ask a plain question like "why did we pick Postgres over DynamoDB for billing?" and get the actual answer, sourced to the RFC and the person who approved it.
A decision is queryable when you can ask a normal question and get a specific, sourced answer back, instead of being handed a folder of documents to read. Most RFC archives fail this test. The doc exists, but it is one of four hundred docs, and nobody remembers its title, so the knowledge is technically saved and practically lost.
This is where StandIn fits. StandIn gives each person a Representative, your StandIn, that can answer questions as them, but only from records they explicitly stood behind. When you close an RFC, the author declares the decision: they vouch for the outcome as their own. After that, anyone can ask the question in plain language and get the decision back, with the named person and the RFC attached as the source.
The restraint is the important part. Your StandIn never invents a position you did not take. If you never declared a decision on a question, it does not guess one for you. It points to where the discussion happened, routes the question to someone closer to it, or says it does not have a declared answer. A refusal there is information, not a failure, because "no one has stood behind a decision on this" is a true and useful thing to learn before you act. You can see how the indexing-and-declaring flow works in how StandIn works.
What makes a good RFC versus a bad one?
A good RFC is specific about the decision it is asking for. It states the problem in a sentence, names the options, recommends one, and is honest about the tradeoffs. It closes with a clear resolution and a named owner. A bad RFC rambles, buries the actual ask, never reaches a decision, or reaches one that nobody records.
The single biggest improvement most teams can make is the closing line. Before you call an RFC done, write one sentence: what was decided, who decided it, and the date. That sentence is what turns a discussion into a record you can answer from later. Our piece on why teams lose decisions in chat covers the failure mode this prevents.
Frequently Asked Questions
What does RFC mean in simple terms?
RFC means Request for Comments. It is a written proposal a team shares so people can react before a decision is made, and it ends with the decision recorded in one place.
Is an RFC the same as a decision record?
Not quite. An RFC is the proposal and the discussion. The decision record is the outcome: who decided, when, and why. A good RFC produces a decision record as its final section.
Who writes the RFC?
Usually the person proposing the change. They lay out the problem, the options, and their recommendation, then invite the affected people to comment before anyone decides.
How is an RFC decision made queryable?
By recording the decision as a clear statement that a named person stood behind, then making it answerable in plain language. With StandIn, the author declares the outcome and anyone can ask for it later and get it sourced.
Does StandIn write the RFC for me?
No. StandIn answers only from records a person declared. It can return a decision you stood behind, but it never generates a position you did not take, and it refuses or points when no one has declared an answer.
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.