Interview prompt. You are the only architect supporting eleven stream-aligned teams. Every design document waits on your review, median wait is nine days, and teams have started shipping without it. The CTO offers to hire two more architects. Tell me what you do.

What the interviewer is testing

Whether you read a wait of 9 days as a capacity problem or as a defect in the operating model. Hiring two architects triples the throughput of a process that should be handling a fifth of the volume, and accepting the offer as framed accepts that every design needs an architect's opinion.

The second thing tested is whether teams shipping without review reads to you as information rather than misbehaviour. They decided the review is not worth nine days, and on most of those documents they are right.

The clarifying questions that change the answer

• What fraction of reviews changed the design? Under a quarter and the queue is a formality; stop requiring it. Over half and the teams lack context, which is an enablement problem rather than a throughput one.
• Which of those changes were irreversible if missed? A wrong cache eviction policy is a week to undo; a wrong choice of where customer records are written can be a year and a regulator.
• Is there a default a team can take without asking? If every design starts from a blank page, every design needs a review. Usually the root cause.
• Who is accountable when an unreviewed design fails? If it is the architect, the review is a liability transfer and no process change will shorten it.

A strong answer's arc

Decline the two hires for review capacity and ask for one platform engineer instead. Then replace the single queue with three paths:

1. Reversible decisions: the team decides and records. A short decision record in the repository, no review, no wait. Roughly three quarters of the queue.
2. A published significance trigger: review is mandatory and small. A named list — a new datastore, a new external dependency, anything touching money or personal data, anything crossing a residency boundary. With eleven teams that is about eleven mandatory reviews a quarter instead of forty.
3. Golden paths for the common case. If the default way to build a service, emit telemetry and store data is scaffolded, most designs have nothing to review. This is the platform hire's job, and the only move that reduces demand rather than redistributing it.

Then convert repeated findings into fitness functions. A finding you have made three times is a build rule, not a conversation.

What a strong answer adds

The organisational layer. In the language of Skelton and Pais's Team Topologies (2019) the architect is run as a gatekeeper, and a gatekeeper's limit is low — on the order of two or three teams before the queue forms. As an enabling function with time-boxed engagements, one person plausibly supports six to eight. Give that as an estimate and say how you would test it: measure median wait and the fraction of reviews that change a design monthly, and treat a wait above 3 days as a signal to invest in defaults.

Add the honest cost: some teams will choose differently and a few will be wrong in ways that cost a sprint. That is lower than nine days on every design plus the credibility loss of a process people bypass.

Common weak answers

• "Hire the two architects." The queue returns at a higher cost as the estate grows, and three people now disagree with each other in front of teams.
• "Set up an architecture review board." It converts the wait into a fortnightly meeting plus a queue for agenda slots.
• "Write more documentation." Documents do not reduce review demand; a scaffolded default does.

When this is the wrong answer

Where a single wrong decision is catastrophic and irreversible — a clearing system, an implanted medical device, a nuclear control room — the gatekeeper model is correct and the queue is the point. There the right answer is more reviewers, and review quality rather than wait time is what to optimise.