RFCs: Building Clarity and Collaboration in Engineering

RFCs: Building Clarity and Collaboration in Engineering

How a simple document format helps teams think clearly, communicate asynchronously, and make better technical and process decisions.

Most bad engineering decisions don’t come from bad intent — they come from missing context.
Meetings generate opinions. RFCs generate understanding.

What Is an RFC?

A Request for Comments, or RFC, is a lightweight proposal document used to describe an idea, a technical design, or a process change — and to invite structured feedback before any work begins.

It’s a simple idea: instead of debating decisions in a meeting or Slack thread, write them down. Describe what you’re trying to do, why, how, and what could go wrong. Then let others review and respond asynchronously.

RFCs give everyone a chance to think before reacting. They slow the decision-making process just enough to make it better.

Why I Use RFCs

When I introduce RFCs to a team, I frame them as a thinking tool, not a bureaucratic one. They’re designed to surface insight, not to create paperwork.

1. Clarity Before Code

Writing forces clarity. By articulating the problem, motivation, and risks, RFCs reveal gaps early. Some of my favorite RFCs end with the realization that we shouldn’t do the thing at all — a small written failure that prevents a large operational one later.

2. Documentation as a Side Effect

An RFC becomes a record of what was proposed, why it was chosen, and what alternatives were considered. Months later, when someone asks “Why did we build it this way?”, the answer is already written down.

3. Inclusivity of Thought

Not everyone thinks best out loud. RFCs give quieter team members — and those who like to research or reflect — space to contribute meaningfully. It democratizes decision-making and improves the quality of outcomes.

4. Alignment Across Teams

At scale, engineering work touches every corner of an organization. RFCs bridge those gaps by creating a shared artifact that anyone — from engineering to product to compliance — can review, comment on, or use for context.

For product managers, RFCs create early visibility into tradeoffs and scope. For design or QA, they clarify intent. For leadership, they provide traceability without another meeting.

Two Templates: Technical and Process Change

Not all RFCs serve the same purpose. At my organization, we use two templates: one for technical changes and one for process changes. Both follow the same principles — clarity, transparency, and feedback — but focus on different kinds of work.

Technical RFC Template

(For architecture, system design, and implementation changes.)

Sections:

1. Overview
2. Goals and Non-Goals
3. Background & Motivation
4. Short Term Pain Points
5. Long Term Risks
6. Design
7. Timeline
8. Dependencies
9. Alternatives Considered / Prior Art
10. Operations and New Processes
11. Security / Privacy / Compliance
12. Risks
13. Results Evaluation
14. Revision History

This template helps engineers reason through tradeoffs and dependencies before writing a single line of code.

Process Change RFC Template

(For workflow, communication, or operational improvements.)

Sections:

1. Introduction
2. Problem Statement
3. Proposed Solution
4. Implementation Plan
5. Potential Benefits
6. Process Change Evaluation
7. Conclusion

This lighter version focuses on people and practice — it’s ideal for evolving how we work, not just what we build.

By separating the two, authors stay focused. Technical RFCs emphasize how the system works; process RFCs emphasize how the team works. Both lead to better shared understanding and fewer surprises later.

How RFCs Support Culture

When practiced consistently, RFCs become part of a healthy engineering culture. They reinforce habits that mature teams value: transparency, ownership, and calm collaboration.

They also create psychological safety. People know decisions aren’t made in hallways or private chats — they’re made in the open, with clear rationale and visibility. That openness builds trust and continuity across projects and teams.

Over time, RFCs even speed up delivery. Writing things down early reduces thrash later: fewer surprises, fewer reversals, fewer “we didn’t think of that” moments.

Getting Started: How to Adopt RFCs

Introducing RFCs doesn’t require a massive process change. Start small and let the value show itself.

1. Pick a Pilot Area.
Choose one upcoming decision — a technical improvement or a recurring process pain point. Write a short RFC for it.

2. Keep It Lightweight.
Use the sections that matter, skip the rest. A one-page RFC is better than a 10-page document no one reads.

3. Create a Shared Space.
Store RFCs where everyone can see them — a Teams channel, a Confluence page, an shared Google Doc . Visibility drives engagement.

4. Encourage Feedback, Not Perfection.
Remind contributors that the goal is clarity, not flawless prose. The value is in the thinking.

Within a few cycles, teams usually start asking, “Do we have an RFC for this?” That’s when you know the culture is shifting.

The Rhythm of Reflection

RFCs turn scattered conversations into durable knowledge. They make engineering organizations calmer, more cohesive, and more predictable.
The real payoff isn’t just better designs; it’s shared understanding — a culture that values thinking before doing.

If your team is struggling with unclear decisions or too many meetings, start small. Take your next big idea, write it down, and invite comments. You might be surprised how much clarity a few pages can bring.

• ← Previous
  Introduction to Kanban: A Visual Workflow Management Method