Architect Role Scope

A seven-person team waits three days for approval to use a managed queue, while eleven other teams wait in the same line. The company has three kinds of architect and no rule about which decision belongs to whom. Architect role scope is that rule: a role is defined by how many teams its decisions bind and how hard they are to reverse, not by seniority or title.

Why it matters

When scope is undefined, two failures appear. Either everything escalates to the most senior architect, who becomes a queue, or architects stay out of everything and wide decisions get made by accident, one team at a time. Defined scope gives teams speed on local choices and gives the organisation a named owner for the choices that bind everyone.

Implementation patterns

• Three bands. Team-level: one team's internal design, reversible within weeks. Solution or domain level: choices spanning a few teams, such as a shared event format. Enterprise level: choices binding most teams or taking months to reverse, such as identity, account structure and data residency.
• Two tests for the band: how many teams does it bind, and how long would reversal take? Above about three teams or about three months, move it up.
• Guardrails over gates: the enterprise role publishes a small set of constraints (approved regions, security baseline, cost tags) and teams decide freely inside them.
• Short consultation: a one-to-two-day review by the platform team for operational fit, advisory rather than blocking.
• Escalation triggers written down: a second team consuming a local component, regulated data entering scope, spend above an agreed amount.
• Coverage ratio: one architect per five to eight teams is a workable planning range; far fewer people means gates become queues.

Industry example

The pattern is general rather than tied to a single published case, so treat this as an archetype: a retailer of about 400 engineers with an enterprise architect, four domain architects and team leads. Teams pick their own databases and queues from a short approved list and may propose additions via a two-day review. The domain architect owns the event schemas shared between checkout and fulfilment. The enterprise architect owns the identity provider and the cloud account layout. Queue choices stop escalating, and shared decisions have a named owner.

Failure scenarios

• The architect as bottleneck: eleven teams, three days each, and teams begin routing around the process with unreviewed choices.
• Ivory tower: designs written without delivery responsibility are late and slightly wrong, because nobody reconciles them with code.
• Scope creep upward: a local queue becomes shared infrastructure for ten teams without anyone re-deciding.
• Vacuum: no owner for the event format, so three teams ship three shapes of the same customer.
• Title inflation: seniority used in place of scope, so a senior engineer overrules a team on something they will not operate.

Trade-offs

When not to use it

In a company of 25 engineers there is often one architect or none, and three formal bands are theatre. A single tech lead who decides fast and writes a paragraph is enough. Formal scope pays when there are more than about eight teams and decisions begin to collide.

Interview question

Q: Three teams escalate the same disagreement to you in a month. How do you decide whether it is yours?

What a strong answer covers: apply the two tests (teams bound, reversal time); if it is team-level, send it back with a boundary and a revisit date; if it spans teams, own it and write the decision; look at why the same question escalated three times, which usually means a missing guardrail you should publish.

Quick check

Quiz: Which two properties decide whether a technology choice leaves the team? How many teams it binds and how costly it is to undo.

Flashcard: Why is central approval of every technology choice a failure mode? — It turns one architect into a queue and teams route around it.