Working Under a Systems Architect

Read job postings closely and you'll find load-bearing phrases. "Works independently as a high-level technical specialist … while collaborating closely with and taking architectural guidance from the current Systems Architect" is one of them. It says: we are hiring a strong specialist, not a rival architect. Panels probing this are screening for a specific failure mode — the brilliant senior hire who fights the incumbent architect for six months. Your job in the room is to show you can be technically formidable and structurally deferential, and that those aren't in tension.

The vocabulary of alignment

Enterprise architecture has a small working vocabulary. You don't need a TOGAF certification; you need to use these terms naturally:

• Reference architecture — the blessed pattern for a class of problem ("our reference architecture for public-facing web apps"). New designs either follow it or explicitly justify divergence.
• Standards and guardrails — the constraints that keep a portfolio coherent: approved platforms, auth patterns, logging conventions, data-handling rules. Guardrails are what make delegation safe — the architect can let specialists run precisely because the rails exist.
• Architecture Decision Record (ADR) — a short written record of a significant decision: context, options considered, decision, consequences. Proposing ADRs is the single easiest way to show architectural maturity — it says I expect my decisions to be reviewed, and I make that cheap.
• Architecture review — the checkpoint where designs get challenged before they're built. The senior move is bringing work to review early, when changing course is cheap, not after, when review becomes conflict.
• Technical debt register / roadmap alignment — the shared list of what's deliberately imperfect and when it gets fixed; new work should reduce it, or at least not silently add to it.

How to describe the working relationship

A strong answer to "how would you work with our Systems Architect?" has three parts:

Inherit before you propose. "My first weeks are for learning the current enterprise design — the reference architectures, the standards, the integration patterns, and why they are the way they are. Systems in production usually encode lessons; I'd rather inherit those lessons than rediscover them." This lands especially well delivered by someone with obvious building energy — it shows the throttle is deliberate.

Propose in writing, decide together, disagree in private. "For AI initiatives I'd bring short written proposals — an ADR-style document: the use case, options, risks, my recommendation — so the architect reviews a concrete artifact, not a hallway pitch. Where we disagree, I make my case with evidence, once, in the room — and whatever we decide walks out as our decision." Panels hear the maturity in "once."

Own the delegated space fully. Deference isn't passivity. Within agreed guardrails, a specialist runs: builds, ships, monitors, reports. "The architect shouldn't need to review my error handling — they should be able to trust that anything I ship follows our standards, and spend their attention on the decisions that actually need them."

AI specialist + systems architect, specifically

AI work creates a particular seam: the AI specialist knows what models can do; the systems architect knows what the enterprise can absorb. Name the seam and how you'd manage it:

• AI capabilities enter through the enterprise front door — the same auth, logging, data-classification, and deployment standards as everything else. No shadow AI stack.
• The specialist brings options, the pair picks trajectories. "Here are three ways to add document intelligence; here's what each costs, risks, and couples us to" beats "I already built it over the weekend" — even when you could build it over the weekend.
• Translate both directions. Part of the role is making AI legible to the architect and management (capabilities, limits, failure modes, cost curves) and making enterprise constraints legible to AI enthusiasm elsewhere in the building. The person who can write the two-page brief that both audiences trust becomes the hub of every AI conversation.

The trap question

Some panel will ask a version of: "What would you do if you strongly disagreed with an architectural decision?" The scored answer has a shape: make the case with evidence and a written option analysis → escalate honestly if the stakes justify it → then execute the decision wholeheartedly, and instrument it so reality can settle the question later. The disqualifying answers are at the extremes: "I'd just go along" (no spine) and "I'd build a prototype proving them wrong" (no team). Evidence, escalation path, commitment — in that order.