Replacing a review board that slowed everyone down

A logistics software company has a monthly architecture review board of seven senior architects. Every significant design must pass it. The queue is nine weeks long, most designs arrive already built, and teams have learned to call their changes "minor" to avoid it. The board isn't malicious; it is a classic gatekeeping board, failing in the classic ways. This case follows the company as it replaces approval with advice, and what it had to add when the new process missed something.

1. The situation

Freightline builds route planning and fleet software: 300 engineers in 40 teams, about 120 services. Its Architecture Review Board (ARB) meets on the first Tuesday of each month and reviews six designs per meeting, twenty minutes each. Designs must be approved before "significant" work starts.

An internal review of the last year found:

• Median wait from submission to decision: nine weeks.
• In 60% of reviewed designs, the team had already built most of it: the only real verdicts were "approve" or "start again".
• Two thirds of cross-team incidents came from changes that never went to the board, mostly labelled "minor".
• The seven board members spent about a day a week each on review preparation, and were the bottleneck for every other kind of architecture work.

2. What mattered

• Speed: decisions in days, not months.
• Quality where it counts: expensive, cross-team decisions still get many eyes.
• Accountability with authority: the team that lives with a decision makes it.
• Visibility: nobody should be surprised by a change that affects them.

3. The options

4. The decision

ADR-112: Replace the Architecture Review Board with the advice process

Status: Accepted (trial for two quarters, then review)
Decider: CTO; consulted all 40 team leads, ARB members, SRE, security
Context: 9-week median wait; 60% of reviews after the fact; incidents from
  unreviewed "minor" changes; ARB members are a bottleneck.
Decision:
  - Anyone may make an architecture decision, after seeking advice from
    everyone meaningfully affected and from someone with expertise.
  - Three tiers: Team (decide, record if significant), Advice (consult
    affected teams, record the advice in the ADR), Forum (present at the
    weekly open architecture advisory forum; a named decider decides).
  - ADRs list the teams consulted and any dissent.
  - Former ARB members become forum hosts and advisors, not approvers.
  - Twelve architecture principles and a technology radar, written with teams.
  - Key rules (dependency direction, data ownership, approved data stores)
    become fitness functions in CI.
Consequences:
  + Decisions in days; reviews happen before building, when advice is cheap
  - Depends on teams seeking advice honestly; some will skip it
Revisit: after two quarters, against wait time and cross-team incidents

5. How it works

The same proposal, a change to the shared shipment-events schema used by six teams, through the old process and the new one.

6. Which tier is this?

Freightline published a one-screen guide so teams could place their own decisions. Try it:

7. How it played out

After two quarters the median time from proposal to decision was six working days. The forum heard two or three proposals a week, with any engineer welcome; attendance settled at around 30. Fewer changes were labelled "minor", because there was no longer a reason to avoid review.

It wasn't seamless. In month four a team changed the retention settings on the shared Kafka cluster without consulting the teams that consume from it, and two of them lost a day of replayable events. The team hadn't skipped the process on purpose: they didn't know who used the cluster. Freightline added two things: the service catalogue now lists the consumers of every shared resource, and the ADR template asks "who did you consult?" with the catalogue's list pre-filled. A fitness function now flags configuration changes to shared infrastructure that have no linked ADR.

8. Lessons

• Review early and with context, or not at all. A board that sees designs after they're built can only approve or reject (Module 27).
• Seek advice, not permission. The team that carries the pager decides; the obligation is to consult those affected and an expert first.
• Tier by reversibility and reach. Most decisions are small; spend the forum's time on the few that are expensive or cross many teams (Module 06).
• Make "who is affected" findable. The advice process failed only where nobody could see the dependents. A catalogue with owners and consumers is governance infrastructure (C03 Backstage).
• Automate the rules, discuss the trade-offs. Fitness functions enforce what is settled; people discuss what isn't (Module 26).

9. Your turn

1. Measure the wait (10 min). For the last five significant decisions in your organisation, how long from proposal to decision, and was anything already built?
2. Tier three decisions (10 min). Place three recent decisions in Team, Advice or Forum. Who should have been consulted?
3. Draft a review checklist (10 min). Adapt the review checklist template for your forum.

10. Check yourself

11. Sources and further reading