Lightweight Architecture Reviews

A technical second opinion in 60–90 minutes. Not a gate, not a sign-off — a working session that leaves a team with a sharper risk picture and still owning the call.

What it is

This is the architecture-review pilot named in the intro: a technical second opinion on a project that needs one — not a gate, not a sign-off, a working session with another set of engineering eyes.

The deliverable is a sharper picture of risk, written down in a way the team can reuse. The point is that the team leaves understanding its own design better than when it walked in — not that you blessed it. You are a second set of experienced eyes for ninety minutes, not an approval authority and not the system’s new architect.

How you run it

Reviews are requested, usually through intake — they’re pulled, not scheduled standing time. Timebox the session to sixty to ninety minutes and hold the line on it; the timebox is what keeps a review from sliding into a full audit.

Bring one more engineer’s eyes than the team has. The value is the second perspective, so don’t run it solo if you can avoid it. Have the team walk you through what they’ve built and what they’re deciding — you’re reacting to their design, not arriving with one.

What you commit to is a short written readout, delivered same-day or next: what you’d watch, what you’d change, what’s fine, and the named risks. Short is the discipline. A readout the team will actually reread is two thirds of a page, not a fifteen-page audit nobody opens.

How you show up

Ask the questions an experienced engineer would ask if they were in the room — about failure modes, scale, the seams between systems, what happens when the vendor changes the contract. Your questions are the product more than your conclusions are.

Name risks plainly. “This works until the batch job grows past a few hundred thousand rows, and then it doesn’t” is worth more than a hedge. The team can only weigh a risk you’ve said out loud.

Respect that the team owns the decision. You can say what you’d watch and what you’d change; you don’t get to say what they must do. Do not redesign their system — the fastest way to wreck a review is to start drawing the architecture you’d have built, because now they own your design instead of understanding theirs.

The readout template

Keep it short and keep it the same shape every time, so a reader who’s seen one readout knows where to look in the next.

Section	What goes here
What we’d watch	The things that aren’t wrong now but will bite at scale, under load, or on the next change.
What we’d change	The specific changes you’d make, in priority order — each one optional, each one the team’s call.
What we’d leave alone	What’s fine as-is, said explicitly, so the team knows what not to spend time on.
Open risks	Named risks with their trigger and consequence — “if X, then Y” — that the team should track regardless of what it changes.

Notice that “what we’d leave alone” is a section, not an omission. Telling a team what’s fine is as useful as telling them what’s broken — it’s how a review reduces work instead of inventing it, and it’s the line that proves you reviewed the whole thing rather than just hunting for problems.

Templates

The hard part of a review isn’t the session — it’s keeping it from quietly becoming a gate. These copy-paste starters carry that work in their wording: they confirm the timebox, deliver the readout, and say in plain language that the call stays with the team. Swap anything in [brackets] for your specifics. The intent is doing the work, so keep it when you edit — not just the structure.

Confirming a review

When a team asks for a review, your reply sets the terms before the room does. Name the scope, hold the timebox, and say the ship decision is theirs — in writing, before they can start treating the session as the thing they’re waiting on.

Subject: Re: architecture review for [project]

Hi [name],

Happy to bring a second set of eyes to [project]. Two things up front so we
both know what this is:

  Scope:    a 60–90 minute working session — you walk us through what you've
            built and what you're deciding, and we react to it. Not a full
            audit of the system.
  Timebox:  we'll hold to the [60/90] minutes and leave you a short written
            readout same-day or next.

To be clear about what this isn't: it's a second opinion, not a sign-off. You
own the design and you own the ship decision — nothing here is a gate, and
you don't need our blessing to deploy.

Send me [the diagram / a doc / whatever you've got] beforehand if it's handy,
and let's grab [proposed time].

[your name]

Notice it says “not a gate” before the team can decide it is one. Premature load bearing starts the moment a review reads like approval — putting the ship decision back with the team in the confirmation email is how you keep a second opinion from hardening into a dependency on you.

Readout email

The send-ready version of the readout. It mirrors the same four sections as the readout table above — what you’d watch, what you’d change, what you’d leave alone, open risks — so a reader who’s seen one knows exactly where to look. Keep it to two thirds of a page; this is the paste-into-email form of the table, not a longer cousin of it.

Subject: Architecture review readout — [project]

Hi [name],

Good session today. Here's the readout — short on purpose, same four sections
every time. All of this is advice; the calls are yours.

What we'd watch
  - [the thing that's fine now but bites at scale / under load / on the next
    change — one line each]

What we'd change
  - [specific change, highest priority first — each one optional, each one
    your call]

What we'd leave alone
  - [what's fine as-is, named explicitly, so you know what NOT to spend time
    on]

Open risks
  - [named risk: if [trigger], then [consequence] — worth tracking regardless
    of what you change]

Nothing here is something you're waiting on us for. Ping me if you want to
talk any of it through.

[your name]

Notice “what we’d leave alone” gets its own line even in the email, and every line is framed as advice. The readout reduces work only if it tells the team what’s fine, and it stays a second opinion only if the prose never reads like a checklist they have to clear.

This is advice, not a sign-off

For the moment a team treats the readout as a gate — “we’re waiting on the architecture review before we deploy.” Say it plainly and hand the decision back, same as you did in the confirmation.

Subject: Re: deploy of [project]

Hi [name],

Quick clarification: you're not waiting on us. The readout was a second
opinion, not an approval — there's no sign-off step here, and we're not
blocking the deploy.

If you've weighed the open risks we flagged and you're comfortable, ship it.
The call is yours; it always was.

[your name]

Notice this exists because the warning sometimes doesn’t land the first time. Premature load bearing is the failure this whole pilot guards against — when a team still treats the review as a gate, the fix is to say “the call is yours” again, out loud, until a thing meant to unblock them stops being a thing they wait on.

What good looks like

The team leaves with a sharper risk picture and still owns the call — you didn’t decide for them.
The readout is short, named, and reusable — the next engineer at that agency can read it and catch up.
You named at least one risk the team hadn’t fully seen, and at least one thing that’s fine.
The session ended on time.
Nobody is waiting on your approval to ship.

Where it goes wrong

Premature load bearing

The review becomes a gate. Teams start treating your readout as a sign-off and won’t ship without your blessing — so a thing meant to unblock them is now a dependency on you. The tell: a team says “we’re waiting for the architecture review before we deploy.” Say plainly, in the room and in the readout, that this is advice and the ship decision is theirs. A second opinion they can overrule is help; one they can’t is a gate.

Capacity substitution

You stop reviewing their design and start producing it — leaving the session with the architecture you’d build, drawn on their whiteboard. Now they own your design without understanding it, which collapses the moment you rotate off. The tell: the readout describes a system the team didn’t propose. React to their work; don’t replace it.

Scope creep into a full audit

The ninety-minute second opinion quietly becomes a multi-week assessment of everything. It feels thorough and it buries the team in findings they can’t action. The tell: the readout grew past a page and the timebox got “just this once” extended. Hold the timebox. If there’s genuinely a full audit’s worth of work, that’s a different, named engagement screened through the four questions — not a review that slid.

What it tells us

One review is one team’s risk picture. The same architecture problem showing up across reviews is something else: it’s a reusable artifact waiting to be written, or a hire waiting to be made. When three agencies hit the same seam between a legacy system and a new vendor, that pattern belongs in a question set or a doc so the fourth team catches it before the review.

So keep the readouts and read across them. They feed the four questions — what unblocks more than one team, what’s a real engineering gap worth staffing — with hard evidence, and a recurring readout finding is one of the strongest hiring signals you’ll get.