When designing and building features, clear communication is key. One of the most critical tools in our engineering toolkit is the Request for Comments (RFC) process. RFCs are living documents that drive alignment across teams, create clarity, and provide a roadmap for implementation. But, not all RFCs are created equal. We use two kinds of templates to ensure efficiency: a detailed version for complex projects, and a streamlined version for smaller features.

Here’s how we approach writing effective RFCs and why tailoring them to the scope of the work matters.

‍

‍

Why Write RFCs?

RFCs are the blueprint for technical work. Whether it’s a significant architectural overhaul or a small feature enhancement, a written plan ensures that everyone involved has the same understanding of the problem, solution, and implementation path. Key benefits include:

1. Better Planning: Writing encourages thoughtful design before coding begins. By structuring discussions around key technical decisions early on, RFCs prevent scope creep, reduce last-minute pivots, and ensure that dependencies are accounted for.
2. Alignment: Development has many stakeholders. RFCs help create and maintain alignment.
3. Documentation: Provides a historical record of decisions, challenges, and solutions. This allows anyone new to the organization or specific part of the system to learn about why things are built the way they are built.
4. Risk Mitigation: Identifies potential risks and raises critical questions before implementation begins. This “What if?” activity helps with making sure that we build feasible solutions.‍
5. Scalability: Creates a repeatable process that scales as the organization grows.

‍

The Two RFC Templates: Choosing the Right Tool

1. Tech-Spec RFC: For Big Projects

The Tech-Spec RFC is our go-to template for large, complex initiatives that impact multiple systems, require cross-team collaboration, or involve significant architectural changes. Its comprehensive format ensures all critical aspects are thoroughly examined.

Key Sections:

• Background and Purpose: Explains the why behind the change and its goals.
• Architecture Overview: Includes diagrams to visualize the system’s structure and interactions.
• User/Data Flows: Details how users or data will traverse the system.
• API and Database Changes: Specifies the exact schema and API modifications.
• Testing and Observability: Describes the strategy to ensure quality and monitor the feature post-release.
• Implementation Plan: Breaks the work into milestones and tasks to track progress.

This template is ideal for projects like introducing a new multi-cloud orchestration layer or redesigning critical parts of our platform infrastructure.

Get the template here.

2. Mini RFC: For Smaller Changes

The Mini RFC is designed for lightweight changes or feature updates. It’s short, focused, and perfect for when a smaller scope is involved.

Key Sections:

• Problem Statement: A concise summary of the issue being addressed.
• Proposed Solution: A high-level explanation of the change and its expected impact.
• Implementation Details: A brief outline of the components to be updated and any anticipated challenges.
• Success Metrics: How the success of the change will be measured.
• Questions/Concerns: Space for addressing potential risks or uncertainties.

This template works well for quick, iterative changes like adding a new filter to a UI or tweaking alerting logic.

Get the template here.

‍

When to Use Each Template

• Tech-Spec RFC: Use when a project spans multiple teams, introduces significant complexity, or has long-term implications.
• Mini RFC: Use for minor features, enhancements, or maintenance tasks that are limited in scope.

By choosing the right template for the job, we strike a balance between thoroughness and efficiency.

Get a Notion database template to manage RFCs that you can copy and start using today here.

‍

‍

Best Practices for Writing RFCs

Regardless of the template, these tips can make your RFCs more effective:

1. Be Clear and Concise: Use simple language to explain technical concepts. Avoid jargon where possible.
2. Visualize When Possible: Diagrams can often explain what text cannot.
3. Iterate: An RFC is not set in stone; update it as new information arises or plans evolve.‍
4. Encourage Feedback: Share the RFC early and invite input from all relevant stakeholders.

‍

Why Tailoring RFCs Matters

Using the right level of detail ensures your team spends time where it adds the most value. Overly detailed RFCs for small tasks can waste time, while under-documented large projects can lead to confusion, missed requirements, or costly rework. By aligning the complexity of the RFC to the scope of the work, we ensure we’re delivering efficiently without compromising quality.

‍

Start Writing Smarter RFCs

RFCs are more than a formality—they’re the backbone of effective engineering processes. Whether you’re tackling a massive system overhaul or adding a small feature, tailoring your RFC ensures clarity, alignment, and success.