Architect Coverage Ratio

One architect supports eleven delivery teams. Every design document waits on their review, median wait is 9 days, and teams have begun shipping without it. The CTO offers to fund two more architects. Accepting triples the throughput of a process that should be handling a fifth of the volume, and commits the organisation to the premise that every design needs an architect's opinion.

The coverage ratio makes that premise examinable. It is teams per architect, and it takes two very different values. As a gatekeeper — every design reviewed before it ships — the limit is low, on the order of 2 or 3 teams before a queue forms. As an enabling function, with defaults published, reversible decisions devolved and engagements time-boxed, one person plausibly serves 6 to 8. Both are estimates; the metric's value is that it forces the question of which model is in use.

Why it matters

A review queue looks like a staffing problem and behaves like a design problem. As utilisation approaches one, wait time grows without bound, so a reviewer at 90% of capacity has a wait that is a multiple of the backlog rather than proportional to it. Adding reviewers raises the service rate and does nothing to the arrival rate, which is set by how many decisions require permission.

Teams routing around review is information rather than misbehaviour. The fraction of reviews that change a design is the diagnostic — under about a quarter and the queue is a formality to abolish; over half and the teams lack context, which is an enablement problem rather than a throughput one.

Implementation patterns

• Measure three numbers monthly: median wait to decision, the fraction of reviews that changed the design, and the count of significant decisions that shipped unreviewed. The third is the one people hide.
• Split by reversibility. Reversible: the team decides and records, no review. One-way doors: mandatory review, from a short named list.
• Publish a significance trigger as that list — a new datastore, a new external dependency, anything touching money or personal data, anything crossing a residency boundary. With eleven teams that is roughly 11 mandatory reviews a quarter rather than 40.
• Invest in golden paths before headcount. A scaffolded default for creating a service, emitting telemetry and storing data removes the decision instead of explaining it, which is the only move that lowers the arrival rate.
• Time-box engagements: six weeks embedded with one team, then out, handing over a written default.

Industry example

Skelton and Pais's Team Topologies (2019) supplies the mechanism. Interaction modes should be explicit and temporary: collaboration is expensive and should be time-boxed, and an enabling team's job is to make itself unnecessary. An architect run as a permanent approval dependency inverts that, so each new team adds a permanent load rather than a temporary one. The same book's platform argument explains why golden paths dominate hiring: reducing the number of decisions that need a decision beats raising throughput in every queue anyone has measured.

Failure scenarios

• Hiring into the queue. Throughput triples, arrivals rise to meet it, and the wait returns within two quarters at three times the cost.
• A review board instead. The 9-day wait becomes a fortnightly meeting plus a queue for agenda slots.
• Silent bypass. Teams stop submitting, the wait metric improves because the queue is shorter, and the organisation reads that as success.
• Liability transfer. The architect is accountable for outcomes they did not deliver, so every review is maximally cautious and the wait is rational rather than fixable.

Trade-offs

The gatekeeper model buys a real chance to stop an irreversible mistake and pays a ratio near 2 or 3 plus teams that do not own their designs. The enabling model buys a ratio near 6 to 8 and faster decisions, and pays in choices you would not have made, a few of which cost a sprint to undo. More architects buys backlog relief and pays in salary plus architects disagreeing in front of teams.

The cost of devolving is lower than 9 days on every design plus the credibility loss of a process people bypass, which is why the enabling model usually wins.

When not to use it

Where one 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 ratio should be low deliberately and review quality rather than wait time is what to optimise. It is also meaningless below about four teams; introduce it when someone proposes the second architect.

Interview question

Q: You cover eleven teams alone, median review wait is 9 days, and teams have begun shipping without review. You are offered two more architects. What do you do with the offer, and what do you measure to show it worked?

What a strong answer covers: decline the headcount for review capacity and ask for one platform engineer instead, because the fix is the arrival rate rather than the service rate. Split decisions by reversibility, publish a short significance trigger so mandatory reviews fall from roughly 40 a quarter to 11, and build golden paths that remove the common decision. Then measure wait, the fraction of reviews that change a design, and unreviewed significant decisions.

Quick check

Quiz: Why does hiring two more architects rarely fix a 9-day review queue? It raises the service rate while the arrival rate — decisions requiring permission — is unchanged, so the queue returns at higher cost.

Flashcard: Rough teams-per-architect limit in each model? About 2 to 3 as a gatekeeper, about 6 to 8 as an enabling function with time-boxed engagements and published defaults.