How do you scale architectural decision-making across many teams without either a bottlenecked central architecture board or uncoordinated local choices — and where do decision records fit?
answer
- Board = queue; full autonomy = incompatible estate
- Advice process: anyone decides, must seek advice, need not obey
- ADR = artefact; deciders / consulted / informed
- Advisory forum non-blocking — approval rebuilds the gate
- Fitness functions + paved road enforce, documents don't
basics
~20 sLet the teams closest to the work decide, but require them to seek advice from everyone affected and from people with relevant expertise before deciding, and to write the decision down. A central board reviews patterns and standards, not every choice.
solid answer
~60 sThe two failure modes are a central board that becomes a queue (slow, context-poor, resented) and full team autonomy that produces incompatible choices nobody can operate. The middle path most often cited is Andrew Harmel-Law's **architecture advice process**: anyone may make an architecture decision, but *must* first seek advice from (a) everyone meaningfully affected and (b) people with expertise in the area — advice must be sought and considered, not obeyed, and the decider retains the decision. The written ADR is the process artefact: it names the deciders, who was consulted and informed, the drivers, the options and the consequences, and it is reviewed in the open (a pull request) so advice is visible and traceable. Around it sit an **architecture advisory forum** for airing significant records, a **spike-in-scope** rule escalating genuinely cross-cutting decisions to a shared log, and **fitness functions** that turn standards into automated checks. The result: decisions stay local and fast, coupling costs are surfaced early, and the log becomes the organisation's shared memory rather than a compliance ritual.
go deeper
Say that teams should decide close to the work but must consult the people affected, and write the decision down so others can see it.
Name the two failure modes (central bottleneck versus incompatible local choices) and describe the advice process — decide locally, seek advice from the affected and from experts, record it.
Add structure: a non-blocking advisory forum, the split between team-local and shared logs with an escalation rule, deciders/consulted/informed metadata in the record, and RFCs as the conversation feeding the ADR.
Own the whole system: define the significance bar and the layering of principles/standards/team decisions, keep the forum non-blocking, enforce with fitness functions and a paved road rather than review gates, require recorded deviations with return conditions, and watch for the specific decay modes (theatre consultation, unenforced standards, fragmented logs).
## The problem One team with one codebase can decide informally and write it down. At twenty teams, two structures compete: - **Centralised architecture board / review gate.** Every significant decision queues for approval. Consequences: latency (decisions wait weeks), context loss (reviewers do not live in the code), learned helplessness (teams stop thinking architecturally and start satisfying reviewers), and the board becoming a political target. It does produce consistency — at the cost of throughput and ownership. - **Full team autonomy.** Each team decides everything locally. Consequences: fast local decisions, and an estate with five auth schemes, three event formats and no shared operability. The costs are externalised onto operations, security, and whoever integrates later. Neither is acceptable at scale. The design goal is: **decisions made by the people with the most context, informed by the people who bear the consequences, recorded so the organisation learns.** ## The architecture advice process Described by Andrew Harmel-Law ("Scaling the Practice of Architecture, Conversationally", later *Facilitating Software Architecture*), and closely related to the *advice process* from decentralised-management literature (Dennis Bakke; popularised via Frederic Laloux's *Reinventing Organizations*): > **Anyone can make an architectural decision. Before deciding, they must seek advice from (1) everyone who will be meaningfully affected, and (2) everyone with expertise in the matter. Advice must be sought and genuinely considered — it does not have to be followed. The decision, and the advice received, are written down.** What each clause buys you: - **"Anyone can decide"** removes the queue and keeps ownership where the context is. - **"Must seek advice from the affected"** internalises the externality — the team that would have pushed operational cost onto SRE now has to hear from SRE first. - **"…and from experts"** injects specialist knowledge (security, data, compliance) without giving those groups a veto that would recreate the gate. - **"Not obliged to follow"** preserves accountability: a veto moves responsibility to the vetoer; advice leaves it with the decider, which is where the consequences land. - **"Write it down"** is what makes the whole thing auditable and learnable — and this is precisely an ADR. ### The ADR as the process artefact The record carries the governance metadata the process needs: **deciders**, **consulted**, **informed** (MADR's front matter maps directly onto this; it echoes a RACI-style split), the **decision drivers**, the **options considered**, the **outcome and justification**, and the **consequences**. Reviewing it as a pull request makes the advice visible as review comments — a durable trace of who objected and how the objection was answered. Where advice was rejected, saying so *and why* in the record is the point, not an embarrassment. ### The advisory forum A regular, open, non-blocking meeting where in-flight records are aired: the decider presents, affected parties and experts give advice, nobody approves. It serves three purposes — surfacing cross-team coupling early, spreading knowledge (junior engineers watch senior reasoning), and making the culture of decision-making visible. Its non-blocking nature is essential: the moment attendance becomes approval, you have rebuilt the board. ## Scoping: local versus shared decisions Not every decision belongs in a shared log. A workable split: - **Team-local records** — decisions confined to one team's services, kept in that team's repository. The majority. - **Shared/cross-cutting records** — decisions binding multiple teams: interoperability contracts (event schema, API envelope, error taxonomy), identity and authorisation, tenancy, observability conventions, data residency. These live in a shared log with wider consultation. - **Escalation rule** — when a team-local decision turns out to constrain others (discovered in the forum or in review), it is promoted to the shared log. Making promotion routine, rather than a failure, is what keeps teams willing to publish early. Organisations often layer this: principles (rarely change) → shared standards/records (change slowly) → team records (change freely, must not contradict the layers above without an explicit, recorded deviation). ## Related mechanisms - **RFC process** (Squarespace, Uber, Oxide and others): a longer proposal document circulated for comment before a decision. Complementary rather than alternative — the RFC is the *conversation*, the ADR is the *outcome*. Teams that run both usually link them, and keep the ADR short. - **Fitness functions** (Ford, Parsons, Kua): automated, objective checks of an architectural characteristic — dependency rules in an architecture test, contract tests on published schemas, CI budgets on latency or bundle size, security policy checks. These convert standards from documents people must remember into failures the build reports, which is how consistency survives without a gate. - **Paved road / golden path**: make the standard choice the easiest one — templates, libraries, platform defaults. Teams deviating pay the cost of deviation and record it. This achieves more consistency than review ever does. - **Deviation records**: an explicit, recorded exception ("this service will not use the shared auth library, because…") with scope and, ideally, a return condition. Recorded deviations are healthy; unrecorded ones are erosion. ## Failure modes to name in an interview - **The forum becomes an approval gate.** Symptom: teams wait for the meeting before merging. Fix: restate non-blocking, decouple decision from meeting attendance. - **Advice-seeking becomes theatre.** Records list ten "consulted" people who never replied. Fix: require the record to state what advice was received and how it was handled; empty advice sections are the signal. - **Log fragmentation.** Twenty repos, twenty logs, no way to find the cross-cutting ones. Fix: a shared index/published site and a clear rule for what belongs in the shared log. - **Standards without enforcement.** Accepted records nobody implements. Fix: fitness functions and paved-road defaults; a standard nobody can check is advisory, and should be labelled as such. - **Consultation cost outrunning benefit.** If every trivial decision triggers a broad advice round, the process becomes the bottleneck it replaced. Fix: apply the significance bar first; only architecturally significant decisions enter the process. ## What "good" looks like Decisions are made in days, not weeks, by the team doing the work. Affected parties routinely see decisions before they land, not after. The shared log has tens of live records with a visible index, superseding chains, and honest consequences. Standards are mostly enforced by CI rather than by memory. New engineers can read the log and understand why the estate is shaped the way it is — including which deviations were deliberate.
- If advice does not have to be followed, what stops a team from ignoring security or platform experts entirely?Four things. The record makes the advice and its rejection visible, which is socially and organisationally costly to do without a reason. Accountability stays with the decider, who owns the consequences. Cross-cutting constraints that genuinely cannot be delegated — data residency, authentication, published contracts — are lifted out of team scope into shared records or hard platform guardrails. And enforceable standards are wired into CI as automated checks, so ignoring them fails the build rather than merely displeasing someone.
- How do RFCs and ADRs relate when an organisation runs both?An RFC is the conversation: a longer proposal circulated for comment, often exploratory, with a comment period and a broad audience. An ADR is the outcome: a short, permanent record of what was decided, why, what was rejected, and what it costs. Running both works well if the ADR links to the RFC for detail and stays short, and if only decisions — not every discussion — produce a record. Running both badly means duplicating content and losing track of which document is authoritative.
It works like clinical practice rather than a permit office. A surgeon decides and remains accountable, but is expected to consult the anaesthetist and the specialist first, and to record the decision and the consultation in notes others can read. A permit office would review every operation and delay them all; unsupervised surgeons would each invent their own protocol.
saying these in an interview costs you the question
- Assuming the choice is binary between a central architecture board and total team autonomy
- Letting an advisory forum become a de-facto approval gate, recreating the bottleneck it replaced
- Treating an ADR as a request for permission rather than a record of a decision already owned by the decider
- Listing consulted parties who never actually gave advice, so the process looks followed but is not
- Publishing standards with no automated enforcement and expecting consistency from goodwill
- Requiring the full advice process for every decision regardless of significance, making the process the new bottleneck
- Fragmenting records across repositories with no shared index, so cross-cutting decisions are undiscoverable