Skip to content

Understanding Internal RFCs in a Company Setting

An internal Request for Comments (RFC) is a structured proposal document used within organisations to facilitate thoughtful decision-making on technical or architectural changes. While inspired by the IETF RFC process, internal RFCs are adapted to suit a company's specific culture, workflows, and pace of iteration.

Purpose

Internal RFCs serve several key functions:

  • Communication: They enable clear articulation of complex ideas or changes, ensuring all relevant stakeholders are aligned on intent and implications.
  • Transparency: By documenting proposed changes in a central, reviewable format, RFCs promote visibility across teams and avoid siloed decision-making.
  • Consensus Building: RFCs allow feedback from multiple perspectives, often leading to better-informed, more robust solutions.
  • Documentation: Once finalised, RFCs become a permanent part of the technical record, useful for onboarding, audits, and future iterations.

Typical Structure

A company RFC generally includes the following elements:

  • Title and Summary: A clear, concise overview of what the RFC proposes.
  • Motivation: The problem statement and rationale behind the proposal.
  • Proposal: Detailed explanation of the suggested solution, including diagrams, data models, and pseudocode if needed.
  • Alternatives Considered: Brief evaluation of other approaches and reasons for rejection.
  • Impact Assessment: Technical, operational, and organisational implications, including migration paths and risks.
  • Reviewers and Approvals: A list of contributors and stakeholders who need to review or sign off.

Process

The RFC process typically follows these stages:

  1. Drafting: An engineer, architect, or team authors a draft based on an identified need.
  2. Circulation: The draft is shared for feedback — often via version-controlled documents or internal platforms like Confluence or Git repositories.
  3. Review and Iteration: Feedback is collected and revisions are made collaboratively.
  4. Approval: Once consensus is reached, the RFC is accepted and scheduled for implementation, or shelved with rationale.
  5. Archival: The finalised RFC is archived for future reference.

Benefits

When embedded effectively into a company's culture, RFCs drive better technical outcomes by encouraging deliberate design, collective ownership, and institutional memory. They are particularly valuable in distributed or fast-scaling environments, where alignment and clarity become more challenging.


Share on Share on Share on