What needs to be finished first
The problem to solve is formulated in one to two sentences, with recognizable context and reach across at least two teams or components.
What needs to be ready before start
RFC template in repo (Context, Motivation, Solution, Alternatives, Drawbacks, Unresolved Questions, Migration); repository or wiki for RFCs with numbering; review tool with comments (GitHub PR, GitLab MR, Notion Comments); decision log.
One author (senior engineer, architect, PM or TL); 3-20 reviewers from affected teams; named decision instance (Tech Lead, Architecture Review Board or clearly selected Decider); sponsor for disputed RFCs.
Problem description; known alternatives from pre-discussions; affected teams and components; architecture constraints; desired decision date; status values (Draft, In Review, Accepted, Rejected, Withdrawn).
1-3 weeks from draft to decision
RFC number and file created in repo. Reviewers and Decider named. Review window with clear end date communicated. Template sections filled at least as skeleton.
The one question this method answers
Which change does the team propose, with which rationale, alternatives and tradeoffs, and who decides by when?
Marker: Sektion
| Step | Duration | Action | Hint |
|---|---|---|---|
1Section 1: Context and motivation | 60-90 min | Describe status quo: what exists, what suffers, what happens if nothing changes. Motivation: why now? Who benefits, who carries cost? Reach of change (teams, services, data). | Starting with solution writes PR description, not RFC. Context is at least 30% of length. Reviewers need it to classify tradeoffs. |
2Section 2: Solution | 2-4 h | Proposed solution in detail: architecture sketch, interfaces, data model, migration. Concrete enough that another person could implement it. But not code-level, design-level. | Too vague: reviewers cannot evaluate. Too detailed: discussion gets lost in implementation. Rule of thumb: senior engineer could derive tickets from it. |
3Section 3: Alternatives | 1-2 h | At least 2-3 rejected alternatives with pros/cons. Per alternative, rationale why not chosen. Also includes do nothing as alternative. | Anyone naming no alternatives has not examined open-endedly. Reviewers rightly ask: what was checked? Alternatives are proof of care. |
4Section 4: Drawbacks and unresolved questions | 45-60 min | Honest disadvantages of solution: what becomes harder, what costs more, which risk appears? Open questions explicitly as list, with proposal how to clarify (spike, proof of concept, external input). | Drawbacks section is litmus test. If nothing is there, author is either too enthusiastic or not thorough. Expect at least 3 substantive drawbacks. |
5Section 5: Review round | 1-2 weeks async review | Publish RFC, review window (for example 10 business days). Reviewers comment structurally. Author answers every comment, incorporates or rejects with rationale. Status to In Review. | Ignoring comments or checking them off cosmetically misses method purpose. Substantive critique leads to revision. Smoothing is not consensus. |
6Section 6: Decision | 1-2 h | Named decision instance sets status: Accepted, Rejected, Withdrawn. If Accepted: follow-up ADR or tickets. If Rejected: rationale. If Withdrawn: author withdraws with explanation. | Decision without clear instance bogs down. If no Decider was named, that is often the actual problem. Discussion is not consensus; decision is act. |
7Section 7: Translation into implementation | Hours to days | If Accepted: write ADR with reference to RFC (short decision rationale). Derive tickets or issues with reference to RFC. Communicate migration plan to affected teams. | RFC without implementation is discussion theater. Every accepted RFC needs at least ADR plus issues. Owner for implementation named. |
What comes out at the end
RFC document in repo with number, status, author, date, review comments, responses and final status. Plus follow-up ADR and issues with RFC reference. Decision log in RFC directory lists all RFCs with status.
RFC number sequential. Status transitions logged. Status Accepted leads to ADR. Withdrawn RFCs are not deleted, but archived with status. New RFC for major change request, do not inflate old one.
Compact working template for Request for Comments with context, input, output artifacts, and next step.
Structured proposal document that describes a non-trivial change and intentionally collects feedback.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Our Order and Payment services currently share connection pools (max 20 per service). Batch jobs have accessed the same pool since 2024. Two incidents (2026-05-14, 2026-02-22) showed batch workloads can block online traffic through pool utilization. Family Tree analysis from 2026-05-18 shows pattern "batch job without quota shares online pool" (3 incidents in 15 months).
Repeated incidents cost an estimated 40k EUR per incident. Pattern cannot be solved through point fix.
Separate batch pool per service with own quota (typically 5 connections). Batch workloads must explicitly use batch pool (annotation @BatchPool in code). Code review checklist enforces annotation for workloads over 30 s runtime.
Phase 1: Order and Payment service (by 2026-06-30). Phase 2: remaining services (by 2026-09-30). CODEOWNERS checklist active from 2026-05-28.
Decider: @julia (CTO). Status: Accepted on 2026-05-17.
Recognize symptoms and steer against them
Document starts with solution, reviewers do not understand motivation.
At least 30% of text for context and motivation. Anyone unable to write context has not understood problem.
Only chosen solution is in document, reviewers have no comparison basis.
Mandatory Alternatives section with at least 2-3 options plus rejection rationale. Do nothing is always an alternative.
Proposal shown as pure gain, reviewers distrust.
Mandatory Drawbacks section with at least 3 substantive disadvantages. Anyone finding none is not thorough enough.
Discussion runs 6 weeks, nobody closes RFC, implementation unclear.
Name Decider before start. Review window with hard end date. If Decider absent, substitute or pause RFC.
Reviewer feedback is checked off, substantive critique answered literally but not reflected in document.
Per comment either incorporate, reject in writing with rationale or park. Smoothing misses method purpose.
RFC is Accepted, nobody derived tickets or ADR, solution sleeps.
Accepted RFC obligatorily creates ADR and tickets. Owner named. Quarterly audit of all Accepted RFCs for implementation status.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.