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 where 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.
Practice the behavioral round:
