The Request for Comments format has been around since 1969, when Steve Crocker wrote RFC 1 to document the ARPANET protocol. Over fifty years later, the format remains one of the most effective tools for technical decision-making.
Yet most engineering teams either skip RFCs entirely or implement them so poorly that they become bureaucratic busywork. Neither extreme works.
The case for writing things down
Before diving into process, let's be clear about why RFCs matter:
They force clarity. Writing a proposal forces you to think through the problem more rigorously than a Slack thread or a whiteboard session. If you can't explain your approach in writing, you probably don't understand it well enough.
They create a decision record. Six months from now, when someone asks "why did we build it this way?", you'll have an answer. The alternative is tribal knowledge that walks out the door when people leave.
They distribute context. Not everyone can attend every meeting. A well-written RFC lets the whole team understand what's being proposed and why, on their own schedule.
They surface better ideas. When people have time to read and think before responding, you get higher-quality feedback than you do in a meeting where the loudest voice wins.
Where RFCs go wrong
Most RFC processes fail for predictable reasons:
1. Too much friction
If writing an RFC requires a specific template with 15 sections, approval from three managers, and a two-week review period, people will avoid writing them. The overhead has to be proportional to the decision.
2. Feedback is unstructured
"LGTM" and "some concerns" are not useful feedback. Neither is a 47-comment Google Doc thread where half the comments are about typos. Good RFC processes need structured feedback mechanisms.
3. No clear decision point
An RFC that sits in "review" for three weeks with no resolution is worse than no RFC at all. There needs to be a clear owner, a clear timeline, and a clear decision framework.
4. They're write-only
If nobody reads the RFCs, why write them? This usually happens when RFCs are stored in a wiki graveyard that nobody visits. The format needs to meet people where they work.
A better approach
Here's what we've learned about making RFCs actually work:
Keep it lightweight
A good RFC needs three things:
- Context — What problem are we solving and why now?
- Proposal — What specifically are you proposing?
- Questions — What do you need input on?
That's it. You can add sections for alternatives considered, rollout plans, or success metrics if they're relevant. But don't mandate them.
Ask specific questions
This is the single biggest improvement you can make. Instead of "please review," ask specific questions:
## Open questions
1. Should we use PostgreSQL or DynamoDB for this use case?
Consider: query patterns, operational complexity, cost at scale.
2. Is a two-week migration window realistic given current sprint commitments?
3. Are there privacy implications we haven't considered?Specific questions get specific answers. Generic requests get silence.
Set a deadline
"Please review by Friday" is simple and effective. Without a deadline, reviews expand to fill available time — which is infinite.
Make the decision explicit
After the review period, the RFC author should update the document with:
- The decision that was made
- Key feedback that influenced the decision
- Any follow-up items
This closes the loop and creates that valuable decision record.
Where Inkling fits
We built Inkling because we kept seeing the same pattern: teams that believe in RFCs but struggle with the feedback loop. The document gets written, but the response process is messy.
Inkling lets you embed structured questions directly into your RFC, right next to the relevant context. Reviewers can read the proposal and provide focused feedback in one flow. No switching between tools, no scattered comments.
It's not about replacing your existing process. It's about making the feedback part work better.
We're building Inkling to make technical proposals more collaborative. If your team writes RFCs (or wishes they did), we'd love to talk.