Pre-meeting flow
The RFC lifecycle that comes before the meeting
A technical design review meeting is the synchronous resolution of an asynchronous process that has already done most of the work. The lifecycle below is from the GitLab handbook and matches the patterns documented at Stripe, Shopify, and Squarespace.
- DAY 0
RFC drafted
Author writes the RFC: problem statement, proposed solution, alternatives considered, trade-offs, open questions. Typical length: 2-5 pages. Shared with named reviewers in the document.
- DAYS 1-3
Async review round 1
Reviewers leave comments inline. Author responds to each comment, updates the document where appropriate. Most simple RFCs reach consensus in this round.
- DAY 4
Decision point
Author evaluates whether open questions are substantive enough to need a meeting. Categorise open questions as: resolved (close them), need more async discussion (continue), need synchronous conversation (schedule meeting).
- DAY 5-7
Meeting (if needed) and decision
60-minute review meeting using the agenda below. Author updates RFC post-meeting, circulates final version, decision recorded as an ADR (Architecture Decision Record).
The meeting template
60-minute structure around open questions
Frame the meeting (5 min)
Author states the 2-4 open questions the meeting needs to resolve. Confirm reviewers have read the RFC and the async discussion. If anyone has not, decide whether to proceed or reschedule. The framing matters because technical design discussions expand to cover everything; explicit scoping at the start keeps the meeting on the decisions that genuinely need synchronous resolution.
Question 1 discussion (15 min)
Author re-states the open question and the positions that have emerged in async review. Reviewers explore the question, surface considerations that did not fit in document comments, identify the trade-offs. The tech lead (or designated decision authority) probes the positions and steers toward a decision. Decision captured verbally and noted by the author.
Question 2 discussion (15 min)
Same structure as question 1. The pattern of restate-explore-decide repeated for each question gives the meeting predictable rhythm and prevents one question from consuming all the time.
Question 3 discussion (15 min)
Same structure. If the RFC has fewer open questions, expand the time per question. If more, surface in the framing whether to defer some to a follow-up meeting rather than trying to compress them all into 60 minutes.
Decision capture and ownership (10 min)
Author reads back the decisions made for each open question. Reviewers confirm. Identify the next-step actions: update the RFC, write the ADR, communicate the decision to affected teams, schedule any follow-up RFCs that the decisions trigger. Author commits to circulating the updated RFC within 48 hours so the meeting's conclusions are documented while context is fresh.
Common topics
Five technical-design topic types and the discussion patterns that work
Trade-off between approaches
Compare approaches against specific criteria (latency, consistency, cost, complexity, time-to-implement). Force ranking; avoid the "it depends" answer that postpones decisions.
Cross-team dependency
Identify the specific interface or contract between teams. Decide on ownership and timeline for the dependency. Schedule a separate follow-up with the depending team.
Backwards compatibility
Define the migration path explicitly: what stays, what breaks, what is the rollback strategy. Time-box the deprecation window.
Performance versus correctness
Quantify the performance gain and the correctness risk. Decide whether the trade-off is worth it given the specific use case.
Build vs buy
Compare against specific vendor options, including pricing and integration cost. Decide based on total cost of ownership, not initial cost.
Scope of the change
Define what is in and out of scope explicitly. Surface any work the team might assume is in scope but the author intends to defer.
FAQ
Common questions about technical design reviews
What is an RFC in engineering?
RFC (Request for Comments) is a written design proposal circulated to engineering peers for feedback before implementation. The pattern originated at the IETF in the 1960s and is now common at Squarespace, Stripe, Shopify, GitLab, and most large engineering organisations. RFCs typically include: the problem being solved, the proposed solution, alternatives considered, trade-offs, and open questions. They are reviewed asynchronously first (comments in the document) then synchronously in a meeting only if needed.
When should a technical design need a review meeting?
Only when async review hasn't resolved the open questions. The Stripe engineering blog (Will Larson) explicitly describes this as the test: if the RFC has gone through 1-2 rounds of async comments and there are still substantive disagreements on direction, schedule the meeting. RFCs that reach consensus async should not get a meeting. The meeting is for high-bandwidth dialogue that comments-on-a-doc cannot produce, not for ratifying decisions already made.
Who should attend a technical design review?
The RFC author, 2-4 senior engineers with relevant context, and one tech lead or staff engineer who acts as the decision authority. Keep it small: above 8 attendees the discussion becomes plenary and quieter voices disappear. For RFCs spanning multiple teams, run separate one-team reviews rather than a single all-teams review; cross-team concerns get raised by the team representatives but resolved in their own team contexts.
How long should a technical design review meeting be?
60 minutes for substantive RFCs, 30 minutes for narrow technical decisions. The duration ceiling matters: technical design discussions naturally expand to cover every related topic, and the 60-minute cap forces convergence. If 60 minutes is not enough, the RFC likely needs to be split into multiple smaller decisions. Squarespace's engineering blog documents the discipline of capping these meetings.
What is an ADR and how is it different from an RFC?
ADR (Architecture Decision Record) is a lightweight document recording a single architectural decision with its context and consequences. RFCs propose; ADRs record. Most engineering organisations use both: RFCs for the proposal and discussion phase, ADRs for the final record once decided. ADRs sit in the codebase or wiki as historical record and are typically not reviewed as a meeting topic; the RFC that led to the ADR was the meeting topic.
Who has decision authority on a technical design?
Typically the tech lead or staff engineer for the team owning the system. The RFC author proposes, peers comment, the tech lead decides. Some engineering organisations use consultative decision-making (the tech lead decides after considering input); others use consensus (decision only made when everyone can live with it). The Stripe engineering blog argues for consultative as faster and clearer for most decisions; consensus reserved for genuinely cross-team architectural choices.
Related
Related engineering meeting templates
Design review (UX)
Different audience (designers, PMs) and different criteria. Both formats share async-first principle.
Sprint planning
The ceremony where decisions from technical design reviews get scheduled into sprint work.
Project retrospective
For reviewing major architecture decisions after the system has been in production.
Effective agenda principles
Five elements every agenda needs, including the role of pre-read documents.