RFCs & ADRs

Scaling technical alignment and documentation culture.

Today's Agenda

What we will cover in this session.

1. The Problem Why unstructured technical decisions slow us down.

2. The Solution Understanding RFCs, ADRs, and the decision funnel.

3. Culture & Growth Leveraging technical writing and empowering team members.

4. Practices Anatomy of documents, workflow fit.

The Problem: Unstructured Decisions

Examining the hidden costs and friction points when teams lack a written decision-making framework.

The Cost of Unstructured Decisions

Without structured documentation, technical growth leads to severe friction.

Endless Re-litigation Teams constantly re-debate the same technical choices as new people join or opinions shift.
The Onboarding Tax New members spend weeks guessing legacy rationale without a clear written trail.
Siloed Knowledge Critical architectural intent leaves permanently when senior engineers depart.

The Solution: RFCs & ADRs

Introducing structured tools to separate early exploration from final architectural commitments.

Two Tools, Two Different Jobs

Separating exploration from final commitment prevents documentation bloat.

RFC (Request for Comments) Used for exploration, debate, alternative comparison, and building early team consensus. Phase: Before work begins
ADR (Architecture Decision Record) Used to lock in permanent historical context, rationales, and accepted trade-offs. Phase: Decision time

The Decision Lifecycle Funnel

Not every explored option requires a permanent architecture record.

1. Many RFCs (Exploration) Teams write multiple RFCs to prototype ideas, evaluate database options, and test alternative approaches.

2. Selective ADRs (Commitment) Only high-impact choices that set a new standard or resist reversal are captured as permanent ADRs.

Culture & Professional Growth

Leveraging written communication to empower remote teams and boost career impact.

Supercharging Remote Engineering Culture

Eliminating synchronous bottlenecks through structured, written communication.

Remote-First Effectiveness Engineers in distributed setups review proposals and weigh in thoughtfully without waiting for live meetings.
Better Transparency Key trade-offs, alternatives, and decisions are open and searchable, reducing silos and building trust.

Scaling Impact Through Technical Writing

Clear architectural writing scales your influence beyond direct conversations and code reviews.

AI-Assisted Drafting Use AI tools to quickly outline structures, critique alternative options, and refine technical rationale.
Intentional Engineering Writing forces deep clarity of thought before building, preventing costly rework and alignment drift.

Voice for Everyone: Inclusive Engineering

Written communication levels the playing field so every thoughtful idea gets considered equally.

Thoughtful Expression Gives engineers time to formulate deep technical arguments without the pressure of live meetings.
Equitable Platforms Provides a safe, accessible space for all team members to share insights and lead initiatives effectively.

Practicing & Leveling Up Your Profile

Build a practice for technical leadership through public and internal documentation.

Deliberate Practice Write short design proposals for minor changes before tackling major system architecture shifts.
Professionalism & Leadership Prep Highlight system design ownership in reviews and build the written advocacy expected in senior/staff loops.

Examples

Walking through concrete blueprints of RFCs, ADRs, and workflow integration.

Example: Anatomy of a Good RFC

A concrete blueprint for proposing technical changes effectively.

Context & Problem Define the technical pain point and business driver clearly.
Alternatives Considered Compare prospective architectural options and trade-offs openly.
Proposed Solution Declare the recommended approach and explain why it wins out over alternatives.
Trade-offs & Risks Acknowledge operational complexity and known limitations before sign-off.

Example: Anatomy of a Good ADR

A clean, concise permanent record of a locked-in choice.

Status & Context Accepted | Identify the operational requirement or system constraint.
The Decision State the chosen architectural standard or technical pattern clearly.
Consequences List positive gains and accepted negative trade-offs or technical debt.

Example: From RFCs to ADR

Case Study: Evaluating database strategies for our user service.

Phase 1: Multi-RFC Exploration We authored three distinct RFCs evaluating DynamoDB (high scale, rigid queries), MongoDB (flexible schema, operational overhead), and PostgreSQL (relational strength, team familiarity).
Phase 2: Debate & Benchmarking Asynchronous reviews across time zones compared read/write latencies and migration effort.
Phase 3: The Single ADR Output We archived the exploratory RFCs and locked in one definitive ADR choosing PostgreSQL on AWS RDS, explicitly documenting why MongoDB and DynamoDB were declined.

Where RFCs Fit in Your Existing Workflow

Connecting technical proposals seamlessly to your current PRD and planning cadence.

From PRD to RFC Once Product defines what problem we are solving and why it matters via the PRD, the engineering team bridges the gap by writing an RFC detailing how we will build it technically.
Zero Duplication RFCs do not replace planning sessions; they serve as the technical deep-dive bridge between high-level roadmaps and sprint execution.