Free Engineering RFC Template

An engineering RFC (request for comments) is the document you write when you want to make a non-trivial technical change and you need the team to weigh in before you build it. It is the artifact that converts a private opinion into a decision the team can own. Most teams already know they should be writing more RFCs; the reason they don't is that the templates they have are too heavy, and the writer gives up partway through.

This template is deliberately lean. The sections are the ones that survived years of iteration on real engineering teams. Anything not in the template was something teams kept writing but the readers kept skipping. The result is a format that a senior engineer can fill in inside a focused half day, and that a reviewer can read in fifteen minutes.

When to use it

• Architectural changes that span more than one service or team.
• New dependencies or platforms that future engineers will inherit.
• Changes to interfaces other teams depend on.
• Process changes (deploy pipeline, branching, on-call) that affect the whole team.
• Any change where you want a written commit-or-reject before you write code.

The template structure

This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.

RFC: [short imperative title]
Author:      [name]
Reviewers:   [named individuals — not "the team"]
Status:      [draft / open for comment / accepted / rejected / superseded]
Deadline:    [date for comments to close]

SUMMARY
  One paragraph. Someone reading only this section should know what
  you propose and why. Treat it as the abstract.

PROBLEM
  What is the situation today? What is wrong with it? Make the
  problem real. Numbers, examples, screenshots. If the reader does
  not believe the problem is real, they will not engage with the
  proposal.

PROPOSAL
  What you want to do. Concrete enough that another engineer could
  start work from this document. Diagrams welcome. APIs, schemas,
  and interfaces sketched, not finished.

ALTERNATIVES CONSIDERED
  At least two. The "do nothing" option is one of them and must be
  taken seriously. For each alternative:
    - What it is
    - Why we are not going with it

IMPLEMENTATION PLAN
  Rough sketch in stages. Not a Gantt chart.
    Stage 1: [...]   ~[time]
    Stage 2: [...]   ~[time]
    Stage 3: [...]   ~[time]

RISKS & MITIGATIONS
  - Risk: [...]   Mitigation: [...]
  - Risk: [...]   Mitigation: [...]

EXPECTED COSTS
  Engineering time:    [rough]
  Operational cost:    [rough]
  Migration cost:      [rough]
  Ongoing maintenance: [rough]

OPEN QUESTIONS
  - Question for reviewers, not the author.
  - Question for reviewers, not the author.

DECISION (filled in when status moves to accepted/rejected)
  Decider:  [name]
  Date:     [date]
  Outcome:  [summary]
  Dissent:  [name: summary, or "none recorded"]

How to use it well

• Name reviewers, not roles. "The platform team" is not a reviewer. Two named people are. Three is the upper bound; beyond that the document becomes diffuse and no one feels accountable for reviewing.
• Set a comment deadline. Five business days is the default that works. Without a deadline, RFCs stay open indefinitely and decisions never get made. The deadline is the forcing function.
• The problem section is the most important. If reviewers do not buy the problem, they will not engage with the proposal. Spend half your effort here, not on the implementation plan.
• Take "do nothing" seriously. Most RFCs that get rejected get rejected because the do-nothing case was undersold. Engage with it honestly.
• Fill in the decision section when you close the RFC. An RFC without a recorded decision is half a document. Make this a hard rule — closing an RFC without filling in the decision section is incomplete work.

What to skip

Skip the urge to use the RFC for ideation. RFCs are for proposals; they are written when you have an answer and want the team to test it. For pre-proposal exploration, use a tech-spike document or a thinking-out-loud Slack thread. Conflating the two produces RFCs that nobody knows how to engage with — they read like notes, not proposals.

Skip including an exhaustive API spec in the RFC. The point of the RFC is direction, not implementation detail. Save the full schema for the implementation. If reviewers cannot agree on the shape of the API at the RFC stage, that is a sign you need a sub-RFC, not more detail in this one.

Frequently asked questions

Is this template free?

Yes. Copy the structure above into a Notion page or a Markdown file in your repo's /rfcs folder.

Can I edit it?

Yes. Common edits: dropping the Expected Costs section for small RFCs, adding a Security section for security-relevant changes, adding a Privacy section if your work touches user data.

Do I need to give my email?

Not for the template. The downloadable Notion version is gated, but the structure is the same.