Architecture Review Boards (ARBs) — sometimes called Tech Review Committees, Design Review Forums, or “the architects” — are the bodies that govern major technical decisions in larger organizations. Effective ARBs prevent expensive mistakes; ineffective ones become blockers that engineers route around. Senior EMs need to know how to participate and how to run them.
What an ARB does
- Reviews proposals for new services, major refactors, or architectural changes
- Catches cross-cutting concerns early (security, scalability, operations)
- Aligns teams on shared standards
- Records decisions for institutional memory
When ARBs work
- Membership rotates; not the same 3 people forever
- Members include senior ICs and EMs (not just architects-by-title)
- Meetings are short, decision-oriented, and time-boxed
- Asynchronous review for less critical proposals
- Decisions are documented and searchable
When ARBs fail
- Become a bureaucratic gate — every PR needs ARB approval
- Members are not technical enough to engage substantively
- Slow turnaround (3+ weeks for a decision)
- Decisions are vetoed without alternatives proposed
- Teams route around it — “we did not need to bring this to ARB”
The proposal format
A good design proposal for ARB review:
- Problem statement: what is being solved?
- Constraints and requirements
- Proposed solution
- Alternatives considered
- Risks and unknowns
- Cost (engineering, infrastructure, ops)
- Specific asks of the ARB
Length: 5–10 pages typically. Pre-read circulated 48 hours before the meeting.
The meeting
Standard format (60 minutes):
- 5 min: presenter sets context
- 10 min: silent reading if not pre-read
- 30 min: questions and discussion
- 10 min: explicit decision (approve, approve with conditions, reject, defer)
- 5 min: action items and recording
What members should focus on
Effective ARB members ask about:
- What you assumed (often the load-bearing weakness)
- What you considered and rejected (and why)
- How you will know if the design is wrong
- What is the rollback plan
- How does this affect adjacent systems
- Operational concerns: monitoring, on-call, security
Less effective members ask:
- “Why didn’t you use [favorite tech]?”
- Bike-shed-level details unrelated to the architecture
- Show-off questions to demonstrate their own expertise
Decisions and conditions
Outcomes of an ARB review:
- Approved: proceed
- Approved with conditions: proceed but address X, Y, Z
- Send back: revise and re-review
- Rejected: not proceeding in this form
Decisions are recorded with the rationale. Future architects can find why decision X was made.
The “ARB-friendly” architecture culture
Strong companies build a culture where:
- Engineers proactively bring designs for review (it is helpful, not punitive)
- ARB members give constructive feedback and propose alternatives
- Past decisions are searchable and referenced
- “We considered this in 2024 and decided X because Y” is a valid argument
What to skip ARB
- Internal-only changes within a single team’s domain
- Refactors that do not change interfaces or operational characteristics
- Routine bug fixes
- Experimentation in feature-flagged dark launches
ARB is for cross-cutting decisions, not every code change.
Distributed ARBs
For multi-time-zone organizations, async-first ARB:
- Proposal posted
- Members comment async over 5–7 days
- Live meeting only if needed for unresolved disagreement
- Decision recorded in the proposal
Reduces meeting load; works well when culture supports it.
Frequently Asked Questions
Do small startups need ARBs?
Under 30 engineers: usually no — informal Slack discussions suffice. Above 50 engineers: ARB-like processes start to add value.
What if I disagree with an ARB decision?
Bring new evidence and request reconsideration. Do not route around. Public disagreement-and-commit is healthier than silent defection.
How do I become an ARB member as an EM?
Demonstrate strong technical writing and judgment in design reviews. Senior EMs and staff+ engineers are typical members.