Architecture reviews that change a team's trajectory

Most architecture reviews we see share a problem: they confirm what the executive sponsor already believed. They produce a 60-page document with diagrams lifted from the codebase that nobody on the engineering team reads. After a decade of doing this work, here is the shape of a review that changes a team's trajectory.

What we look at first

Before any diagram, before any code, we look at three things: the production incident history, the on-call rotation, and the deploy frequency. Teams that ship rarely and page often have an architecture problem. Teams that ship often and rarely page have an architecture, even if it is not beautiful. We have seen immaculate Terraform and chaotic on-call rotations, and we have seen the inverse.

The interview is more valuable than the diagram

Architectures live in the heads of the engineers who built them. The diagram is a snapshot; the interview is the system dynamics. We spend the first week talking to engineers at every level. The senior staff tells us about the design. The mid-level tells us about the debt. The junior tells us where they get stuck. All three signals matter.

Common antipatterns we find in week one

The N+1 query that nobody owns. The auth check in the wrong layer. The retry loop that turns a 1% error into a 30% cascade. The missing index on a table that grew 100x. The cache that is invalidated by the write that is supposed to populate it. These are not exotic problems; they are the same problems in every codebase, and they have known fixes.

How we write a review people read

We write the review as a single document with three sections: the five things that are wrong, the five things that are right, and the prioritized roadmap. We cap it at 25 pages. We avoid jargon where possible and define it where not. We use the team's own vocabulary. The point of a review is to be acted on, not to demonstrate expertise.

Build versus buy is rarely the right question

Teams ask us 'should we build or buy X' when the real question is 'do we have the operational capacity to run X in three years.' Buying shifts the cost from engineering to operations. Building shifts it from operations to engineering. The right answer depends on which cost is more painful for your business, not on the feature comparison.

What we will not do

We will not write a review that recommends a rewrite. We will not recommend a technology we are resellers for. We will not produce a document that does not have a clear owner for every action item. Architecture reviews that do not result in changed behavior are a tax on attention.