The Real Cost of Skipping Architecture Reviews
I've watched the same failure mode play out at four different companies now. A senior engineer proposes a design in a Slack thread. A couple of people emoji-react. The team starts building. And then six months later, someone discovers the data model can't support a feature the sales team already sold, and the team is staring down a partial rewrite that nobody budgeted for.
The last time I saw this happen, the rewrite took eleven weeks. The architecture review that would have caught it would have taken two hours.
Eleven weeks
I want to stay on that number for a second, because it's easy to read "eleven weeks" and move on. But think about what eleven weeks actually means for a small engineering team. That's an entire quarter of capacity. That's a roadmap item that doesn't ship. That's a founder sitting across from investors trying to explain why the feature they demoed in October still isn't in production in January. And the root cause, every single time I've traced it back, is the same: someone made a structural decision without writing it down, and nobody pushed back, because pushing back felt slower than just building.
The reasons architecture reviews get skipped are always reasonable in isolation. The team is under pressure to ship. The senior engineer has done this before and "knows what they're doing." Nobody wants to be the person who slows things down by adding a meeting to the calendar. The review process, if one even exists, is vague enough that it feels more like ceremony than substance. And each of those reasons is defensible on its own. But together, they create a culture where the most consequential technical decisions happen in the least visible way. In Slack threads. In standup sidebars. In someone's head on a Friday afternoon.
I've been the person who skipped the review, I'll be honest about that. Early in my career I'd sketch something on a whiteboard, get a few nods, and start writing code. And it worked fine for a while. And then it didn't. And the cost was always, without exception, worse than I'd assumed it would be.
What actually works
The architecture reviews I've seen work well, both the ones I've run for consulting clients and the ones I participated in at larger organizations, are not meetings. They're documents. Short ones. A page, maybe two.
The document answers four questions: What are we solving, and why now? How does the proposed approach work at a high level? What alternatives did we consider and why did we reject them? What could go wrong, and how would we know?
That's it. The author writes it up, shares it async, people comment over a couple of days, the author responds, and if anything is still unresolved there's a 30-minute sync to close it out. Total calendar cost across a week: maybe two hours, spread out, mostly asynchronous.
The first time I ran this process with a team I was consulting for, a backend engineer flagged a problem in the trade-offs section that would have caused a data integrity issue in production. The fix took twenty minutes to address in the design phase. Twenty minutes. It would have taken weeks to unwind if it had shipped. And the most common reaction from teams after their first real review is, without fail, some version of "why weren't we already doing this?"
The line between necessary and overhead
Now, not everything needs a review. Bug fixes don't. Small features that follow established patterns don't. If you gate every PR on a design document, the process will die within a month because engineers will, correctly, recognize it as overhead that doesn't match the risk.
The line I draw: if the decision would be expensive to reverse, it gets a review. "Expensive" meaning significant engineering time to undo, or user-facing behavior that's hard to roll back once it's in production. Database schema changes, new service boundaries, authentication flows, third-party integrations. Those cross the line. Adding a new button to an existing screen does not.
The most common failure mode I see is teams treating this as all-or-nothing. They either review everything, which burns the process out within weeks, or they review nothing, which is how you end up with an eleven-week rewrite. The answer is a clear, shared understanding of which decisions are reversible and which aren't. Gate the irreversible ones. Trust the team on the rest.
Making it stick
If you're a lead or a manager and reviews aren't happening on your team, that's on the process, not the people. I want to be direct about that. Engineers don't skip reviews because they're lazy or reckless. They skip them because the process is painful, or because they've never seen one actually catch something, or because the last review they sat through felt like a performance evaluation of whoever wrote the doc rather than an evaluation of the design itself. Any one of those experiences is enough to make someone avoid the process entirely.
Fix those things and the adoption problem usually solves itself. Keep the template short. Show the team a concrete example where a review caught something expensive. And be explicit, repeatedly, that the review is about the decision and not the person who made it. Because if a junior engineer watches a senior get defensive in a review, that junior is never going to submit a design document voluntarily. And you'll never know what you lost because of it.
The goal is to make thoughtful design decisions feel like the path of least resistance rather than an obstacle to shipping. When the process is lighter than the cost of getting it wrong, people use it on their own.