staff-engineering · staff
Architecture Reviews Without Theater
Quick answer
An architecture review is a structured conversation that asks: Does this design meet the quality-attribute scenarios that matter, and what risks remain? Staff engineers facilitate reviews to find problems early, record decisions, and protect teams from unexamined blast radius—not to humiliate authors or collect prestige.
Why this matters
- Late architectural mistakes are expensive.
- Cross-team designs need independent critique.
- Reviews produce ADRs and follow-ups, not only opinions.
- Staff interviews probe facilitation and judgment under conflict.
Learning objectives
- Prepare a review packet (problem, scenarios, design, risks).
- Facilitate time-boxed, inclusive critique.
- Separate blocking issues from suggestions.
- Close with decisions and owners.
- Avoid review anti-patterns.
Explain like I am 5
Before the school play, someone checks that the stage can hold the cast and the exits are clear—not to be mean, but so the show is safe.
Mental model
flowchart TD
Prep[Packet: problem + QAS + design] --> Review[Facilitated session]
Review --> Issues[Blocking vs non-blocking]
Issues --> Decision[Accept / revise / reject]
Decision --> ADR[ADR + follow-ups]
| Role | Responsibility |
|---|---|
| Author | Clear packet; honest risks |
| Facilitator | Time, inclusion, decisions |
| Reviewers | Scenario-based critique |
| Scribe | Decisions and actions |
Core concepts
Packet before people
Send materials ≥24–48h ahead: problem, quality-attribute scenarios, context diagram, key flows, failure modes, open questions. Surprise reviews reward the loudest voice.
Scenario walkthroughs
Pick 3–5 critical scenarios and walk the design through each. This beats free-form “I don’t like Kafka.”
Blocking vs non-blocking
Blocking: safety, data loss, compliance, SLO impossible. Non-blocking: style, preferred libraries, future-nice-to-haves. Record both; only blocking holds ship.
Decisions in the room (or async SLA)
Leave with accept/revise/reject and named owners. “We’ll think about it” is not a decision.
Psychological safety
Critique the design, not the person. Staff facilitators shut down status games and invite quieter experts (security, SRE, data).
Worked example
Reviewing a multi-region payments write path:
- Walk partition and dual-write scenarios.
- Blocking: no reconciliation strategy for partial commits.
- Decision: revise with outbox + reconciliation job; re-review delta in one week.
- ADR drafted from the decision; security follow-up ticket owned.
Trade-offs
| Heavy review board | No reviews |
|---|---|
| Slow innovation | Surprise incidents |
| Strong governance | Local speed |
Staff default: lightweight reviews for high blast radius; skip for well-paved patterns.
Failure modes
| Mode | Mitigation |
|---|---|
| Slide-only theater | Require scenarios + risks |
| Design by committee | Facilitator + decision owner |
| Late drive-by nits | Time-box; parking lot |
| Rubber stamp | Rotate independent reviewers |
| No follow-up | Action list with dates |
Interview mode
Skeleton: “I run architecture reviews as scenario-driven risk discovery—prepared packets, blocking vs non-blocking issues, and explicit decisions that become ADRs.”
Knowledge check
Whether the design meets critical quality-attribute scenarios and what risks remain
Only whether the slides look polished
Who has the highest title in the room
Avoiding any written follow-up
Related
By Shubham Jain