The Role of the Architect

The checkout team needs sub-100 ms p99 on a hot endpoint. Their tech lead evaluates the options and picks gRPC for internal calls: it is faster than JSON over HTTP, the team is comfortable with protobuf, and the benchmark backs it up. Within a sprint, three other teams are asked to generate protobuf stubs, add a new build dependency, and learn a debugging toolchain they did not choose. The decision was locally correct and globally expensive. That gap — a choice whose consequences cross team boundaries — is the first thing that separates an architect's decision from a senior engineer's.

A practical test you can apply in any design review:

When the answer shifts rightward, ownership shifts with it. Architects own significant technical decisions and their consequences across team boundaries — including the consequences nobody asked for, like the platform team absorbing a new runtime because one squad wanted it.

The mechanism that makes this work in practice is a written decision record. A one-page Architecture Decision Record (ADR) forces the scope question into the open:

# ADR-014: Internal RPC uses gRPC for synchronous service calls

## Context
Checkout p99 budget is 100 ms; serialization costs 12 ms with JSON.
Teams affected: checkout, payments, inventory, notifications.

## Decision
gRPC for synchronous internal calls; Kafka stays for events.

## Consequences
+ p99 serialization drops to ~2 ms
- 4 teams adopt protobuf codegen in CI
- New failure mode: HTTP/2 connection resets behind the mesh
- Rollback path: JSON gateway stays for 2 releases

Note what the record does not say: it does not claim gRPC is the best RPC ever. It claims gRPC is the right choice given a stated budget, names who pays, and names the exit. Interviewers ask this shape constantly — 'tell me about a technical decision you made that affected teams other than your own' — and the strong answer always contains the same three parts: the boundary the decision crossed, the cost you knowingly imposed, and the reversal path you left open. See Quality Attributes and NFRs for how the 100 ms budget itself gets justified; a decision record without a measurable target is just an opinion with a title.

One warning: scope is not seniority. A junior engineer who notices a decision will leak across three services has just done architect work, and the response is to escalate the decision, not to shrink it. The role is defined by the blast radius of the choice, not by the title on the badge.

Architect roles fail in predictable ways. Some architects become glorified reviewers who block pull requests with style opinions. Others disappear into slide decks nobody reads. The antidote is to define the job by its artifacts: if a week produces no written direction, no ambiguity that got resolved, or no team that made a better decision because of you, the week was spent somewhere other than the role.

Output 1: direction. Direction is a short written statement of the technical constraints the next two quarters will operate under — not a vision statement. Compare:

Weak:  'We will embrace cloud-native principles and innovation.'
Good:  'All new services deploy to Kubernetes in eu-west-1 only.
       No new relational schemas without a migration owner.
       Kafka is the default for async; SNS is approved only for
       fan-out under 1k msg/min. Anything else needs an ADR.'

The good version is falsifiable: a team can read it and know whether their plan complies without asking. Direction exists to remove decision requests, so every line should answer a question that previously had to be asked in a meeting. It also expires: revisiting it every quarter, deleting the lines nobody follows, and adding the constraints that recent decisions kept rediscovering keeps the document alive instead of ceremonial.

Output 2: resolved ambiguity. Most architecture work is not choosing between microservices and a monolith; it is answering the 15 smaller questions that stall delivery. 'Can the notification service read the orders database directly?' 'Who owns the retry policy for failed payments?' 'Do we version the events or the schema registry?' Ambiguity is expensive because two teams resolve it independently and then discover they resolved it differently — that is when integration pain begins. The architect's job is to notice the question exists, resolve it fast (often with a two-line ADR), and publish it where the second team will find it before they guess. Measure this: decision latency, the time from 'we are blocked on a question' to 'it is written down', is the single best proxy for architecture effectiveness. Weeks-long queues for trivial decisions are a structural failure, not a busy calendar.

Output 3: coached decisions. The tempting move is to answer every question yourself. That scales to about one team, and it makes you the bottleneck the moment you take a holiday. Coaching means teaching the decision procedure so the team runs it without you:

1. Name the quality attribute at stake (latency, availability, security).
2. List two or three options with the cost each one imposes.
3. State which constraint from the written direction rules options in or out.
4. Write the record and its reversal path.

When a tech lead comes to you with a proposal and leaves with three better-formed questions, the capability transferred. The tell that coaching is working is that ADRs start appearing in repositories you do not own, written by people who never attended your meetings. The tell that it is failing is that you are still the required reviewer on every design doc — that is not influence, it is a queue with a person at the front of it.

A lightweight way to make ambiguity visible is a one-table log kept in the team wiki and reviewed in fifteen minutes a week:

Anything past two working days without movement is treated as a defect, not as busyness. The log also gives you evidence for the next direction revision: nine questions about retries means the retry policy is underspecified at the platform level, not at the payments level.

There is a well-known failure mode: the architect who has not read a diff in two years, whose diagrams no longer match the deploy pipeline, and whose reviews are discounted by engineers as 'not real'. Credibility in this role comes from staying close to implementation while thinking at system scope — and the two halves reinforce rather than compete, provided you choose where to spend the closeness.

A workable allocation for a typical week:

Two rules keep the code contact productive. First, review at the seam, not the style. Commenting on naming and formatting is what linters and senior engineers are for; your review should target the boundary: 'this service now imports the vendor SDK directly in domain code, which contradicts ADR-009', or 'this table has no owner for the migration backfill'. Second, spike before you advocate. Nothing ends an architecture argument faster than a two-hour prototype: when the team claims 'Kafka consumers are simpler than SQS handlers', a 60-line consumer that processes ten messages and shows the failure semantics ends the debate with data. One real number outweighs forty diagrams.

The scope half is a different skill: reasoning about properties that no single repository contains. Timeouts and retries that compound across three hops; a database schema that forces a lock ordering two services must share; a cache that makes two regions disagree for 30 seconds during failover. These are emergent — no line of code is wrong, yet the system misbehaves. Architects earn the title by consistently noticing these before production does, which is why you keep a mental inventory of the system's non-obvious couplings and update it whenever a design doc proposes to add one.

Postmortems are the cheapest way to build that inventory. After reading one, ask two questions that engineers usually skip: what did the system do that no single service was wrong about (the compounding), and which decision record would have prevented the coupling that caused it. Over a quarter, those answers accumulate into the list of couplings you bring to every design review — and they give your review comments the weight of evidence. 'We saw this failure shape in the March payments outage' ends debates that 'I have a feeling about this' never will.

A caution on the credibility trap: closeness to code can tempt you to make decisions that belong to the implementing team — naming a class, choosing a library version, prescribing an error-handling idiom. Each such decision you take is a decision the team stops practicing, and coaching capacity shrinks accordingly. The boundary is: you decide anything whose failure crosses a team; the team decides everything contained inside their module. Hold that line and the role stays both technical and scalable. Next, learn to make those cross-boundary decisions concrete by turning vague requirements into Quality Attributes and NFRs.