Engineering teams make many decisions. Some are obvious; many aren't. Without a framework, decisions are made informally — in Slack threads, in conversations, in someone's head — and then forgotten or contested later. Frameworks provide structure: who decides, who's consulted, what's recorded.
This page covers the major frameworks and when each fits.
A document proposing a change. Written by the proposer; commented on by the team; eventually accepted, rejected, or revised.
Structure:
When to use:
The Rust language community popularized this in software. Many companies have adopted similar processes.
Length: 2-10 pages typically. Long RFCs lose readers; very short RFCs miss the point.
A short document recording a single architectural decision.
Structure:
ADRs are 1-2 pages. They live in the code repository (often docs/adr/).
When to use:
ADRs are write-once-rarely-update. If a decision is superseded, write a new ADR explaining the change.
A role model for decisions:
For each meaningful decision, identify who's in each role. Avoids the "who decides" confusion.
Useful for:
Similar to DACI:
Used widely in project management; less common in engineering than DACI.
| Situation | Framework |
|---|---|
| Significant technical change | RFC |
| Architecture decision worth preserving | ADR |
| Cross-team or stakeholder decision | DACI |
| Long-running project with many decisions | All three at different stages |
For day-to-day technical decisions, no framework is needed. Slack thread, code review comment, quick chat.
The right amount of process scales with stakes:
Pick and move on. "Should this method be public or package-private?" Don't write an ADR.
Quick discussion in code review or design doc. No formal record needed if the code is the record.
ADR. Record for future reference.
RFC. Discussion across the affected teams. Time-boxed comment period.
RFC + DACI. Multiple stakeholders; explicit roles.
Skipping levels in either direction is wrong:
The framework is structure; the decision quality comes from elsewhere:
"Adopt Kubernetes" is not an option. "Migrate the order service to Kubernetes by Q3 with these specific milestones" is. Vague decisions don't constrain action.
Most decisions have downsides. Acknowledge them. The decision that "has no downsides" is rare; usually the trade-offs are hidden, not absent.
Distinguish reversible from irreversible decisions:
Bezos's "Type 1 vs Type 2" decisions. Most decisions are Type 2 (reversible); spend less time on them.
Decisions don't take more time because you give them more time. Set a deadline; decide.
The decision is made; communicate; move on. Reopening every decision because someone wasn't there is a recipe for paralysis.