As my career as a software engineer progresses, I've found myself working on more and more projects that span multiple engineering teams or need input from numerous engineers with different expertise (think infra, ML, full-stack).

Earlier on when this happened, I would schedule a call with everyone, present the idea, get feedback, and iterate from there. I may have documented meeting notes and written down conclusions and decisions, but the feedback medium was mostly verbal and then transcribed (e.g. as meeting notes).

It may come as no surprise, but as the number of projects I was involved in increased, I found that this approach quickly became unsustainable:

  1. My colleagues work in different timezones and mutually overlapping meeting slots are difficult to come by,
  2. I found myself repeating the same context in multiple calls,
  3. Colleagues would often DM me with questions or clarifications on the design

Introducing the RFC ...

I got the chance to work closely with one of our lead engineers for a few months and noticed how they made heavy use of the Request-for-Comment (RFC) document format. A Request-for-Comment (RFC) is a written proposal used to present a concrete solution or direction and gather structured feedback from relevant stakeholders before committing to it.

The goal of an RFC is to align early, surface risks, and converge on a shared plan forward instead of scheduling an alignment call.

Using RFCs drastically reduced the amount of time spent aligning in Slack channels and video calls. Furthermore, the RFC provided a central source-of-truth and context, thus providing a place to clearly describe the problem background and avoid the need to re-establish this in each call when e.g. new stakeholders joined or you wanted to pitch the idea to someone.

In More Detail

Purpose

An RFC exists to achieve one or more of the following outcomes:

  1. Agree on the approach: ensure stakeholders align on how a problem should be solved before implementation begins.
  2. Create awareness of a problem and its implications: make the problem, constraints, and trade-offs explicit to everyone affected.
  3. Surface blind spots and risks early: allow others to highlight concerns, alternatives, or downstream impacts that may not yet be considered.

Expected Outcome

The expected outcome of an RFC is a clear agreement on a plan forward. This may include:

  • Approval of the proposed solution
  • Requested changes or refinements
  • Documented decision to pursue an alternative approach or not to proceed (with rationale)

Once resolved, the RFC becomes a record of context and decision-making, useful for future reference.

Widely Adopted Workflows That Use RFCs

A Minimal RFC Template

Comment Deadline: TBD
Decision Finalized: TBD
Stakeholders: @anastasios, @dora, @johan

Background

Context to frame the problem that is being solved, why it is important i.e. the impact of solving it vs not solving it.

Proposal

Details of the proposal. This is where stakeholders will likely provide most input on and the discussion starts!

Alternatives Considered

  • Alternative 1. Reason not chosen.
  • Alternative 2. Reason not chosen.

Meeting Notes

Log of meetings held with stakeholders as a log of discussions for future reference.

  • @today w @matt, @tshepang, @dora

    • Elaborated on background section together
    • Added more detail on aspect X,Y of proposal

  • @yesterday w @tshepang, @alex

    • First pass at solution proposal
    • Fleshed out Alternative 1 and 2