Our architecture review board (ARB) meets every two weeks. Senior engineers present proposals for significant technical decisions. The board asks questions, raises concerns, and occasionally asks for changes. Then the engineers go implement their plans.

When it works well, the ARB catches problems before they become expensive mistakes. It ensures consistency across teams. It spreads knowledge about what’s being built. It’s a valuable forum for technical discussion.

When it works poorly, it’s a bottleneck that delays projects, imposes unwelcome opinions on teams who understand their problems better, and creates bureaucracy for its own sake. Teams start working around it to avoid delays.

After five years of chairing our ARB, I’ve learned what makes the difference between value and obstruction.

Why Architecture Review Exists

The usual justification for ARBs is preventing bad decisions. Without central review, teams might choose technologies that don’t integrate well, duplicate work that’s already been done, or create technical debt that affects the whole organization.

This is real. I’ve seen teams choose completely different monitoring tools for similar problems, making it impossible to have consistent observability. I’ve seen teams build custom solutions for problems that other teams had already solved. I’ve seen technology choices that seemed reasonable in isolation but created integration nightmares.

Centralized architecture review can catch these problems. Having experienced engineers look at proposals before implementation prevents some mistakes.

But prevention isn’t the only goal. Good architecture review also spreads knowledge. When one team presents how they’re solving a problem, other teams learn from that. This creates consistency not through mandates but through shared understanding.

What Review Should Actually Cover

Not everything needs architecture review. The threshold matters. Set it too low and the ARB becomes a bottleneck for routine decisions. Set it too high and teams make significant decisions without coordination.

We settled on reviewing decisions that either affect multiple teams, introduce new technology to the organization, represent significant cost, or have security or compliance implications. Everything else can be decided by individual teams.

In practice, this means reviewing things like:

Choosing a new database technology. This affects backup procedures, monitoring, operational knowledge, and potentially licensing costs. It should be coordinated.

Building a new shared service. If multiple teams will depend on it, architecture review ensures it’s designed to meet those needs.

Major refactoring of shared infrastructure. Changes to CI/CD pipelines, network architecture, or authentication systems affect everyone.

Routine decisions like which web framework to use for a new service, how to structure application code, or which JavaScript library to use for a UI component don’t need review. Teams should have autonomy for these.

The Presentation Burden

One mistake organizations make is requiring elaborate presentations for architecture review. Teams spend days preparing slides, documenting decisions that have already been made, and scheduling meetings that delay their timelines.

This creates incentive to bypass the process. If presenting to the ARB means a week of preparation and a two-week delay waiting for the meeting, teams will find ways to avoid it. They’ll frame decisions as smaller than they are, make them before review, or just not mention them.

We moved to a lighter process. Architecture proposals are documented in two-page written briefs. They describe the problem, proposed solution, alternatives considered, and implications for other teams. The brief is shared asynchronously for review. Most proposals get approved without meetings.

Only when there are significant concerns or unclear tradeoffs do we schedule a discussion. This reduces overhead while maintaining coordination.

Decision Authority vs Advisory Input

The biggest question for any ARB is: does the board have veto authority, or is it advisory?

Veto authority means the board can block proposals. This ensures consistency but creates adversarial dynamics. Teams feel like they’re asking permission rather than seeking input. They optimize for getting approval rather than making good decisions.

Advisory input means teams make final decisions but consider board feedback. This feels more collaborative but can be ignored. If a team is determined to use a specific technology, advisory feedback might not change anything.

We’ve settled on a hybrid. For decisions that are truly team-local, the ARB is advisory. For decisions that create obligations on other teams or significant shared costs, the ARB has veto authority. The difference is whether the decision affects just one team or the broader organization.

This mostly works. Teams appreciate that they have genuine autonomy for their decisions while understanding that shared infrastructure decisions require consensus.

The Expertise Problem

Architecture review only provides value if the reviewers have relevant expertise. An ARB made up of people who don’t understand the problem space or technology options just adds overhead without insight.

Our ARB membership rotates. We have a few permanent members who provide continuity and institutional knowledge. But we also include people with expertise relevant to whatever’s being reviewed. If we’re reviewing a data pipeline proposal, we include data engineers. If it’s about frontend architecture, we include someone with frontend expertise.

This prevents the ARB from becoming a group of senior people issuing opinions about things they don’t understand. It also prevents the ARB from becoming an old guard that blocks innovation in favor of familiar approaches.

The Consistency vs Innovation Tension

ARBs naturally lean toward consistency. If we already use PostgreSQL, proposals to use MySQL get questioned. If we already have monitoring in Datadog, proposals to use Prometheus require justification.

This is reasonable. Consistency has value. Every additional technology in the stack is something else to learn, maintain, monitor, and support. Minimizing variety reduces operational complexity.

But consistency can become conservatism. If the ARB blocks new technologies unless there’s overwhelming justification, the organization gets stuck with legacy decisions. The database choice that made sense five years ago might not be optimal now.

We try to balance this by requiring clear justification for new technologies, but being open to that justification. The question isn’t “why not use what we already have?” It’s “does this new technology provide enough benefit to justify the additional complexity?”

Sometimes the answer is yes. We added Elasticsearch to our stack despite having PostgreSQL for most data storage because full-text search requirements genuinely warranted specialized tooling. Other times the answer is no. A proposal to use MongoDB because it was “more modern” didn’t provide enough benefit over PostgreSQL to justify it.

When Review Catches Real Problems

The ARB has prevented several significant mistakes. A team proposed an API design that would have created coupling between services that should have been independent. Another team planned to store sensitive data in a way that would have created compliance issues. A third team was about to build a system that duplicated functionality that already existed in another part of the organization.

In each case, the review process caught the problem before implementation. The cost of fixing these issues after deployment would have been much higher than addressing them during design.

But the review also sometimes creates false positives. Concerns get raised that turn out not to matter. “This might create a scaling problem” when the team is nowhere near the scale where it would be an issue. “This technology choice is risky” when the risk is actually manageable.

Finding the right balance between being appropriately cautious and being unnecessarily conservative is ongoing calibration.

Making it Not Suck

The key to making architecture review valuable rather than bureaucratic is making it feel like help rather than obstruction.

Keep overhead low. Lightweight documentation and asynchronous review where possible. Meetings only when necessary.

Focus on genuine risks. Don’t question decisions just to demonstrate authority. If there’s no real concern, approve quickly.

Provide useful feedback. Don’t just say “this might be a problem.” Explain why it’s a concern and suggest alternatives.

Respect team autonomy. The ARB should coordinate and advise, not control. Teams should feel like they’re getting valuable input, not being supervised.

Create forum for learning. Use review sessions as opportunities to spread knowledge, not just evaluate proposals.

The Alternative Models

Some organizations don’t have formal ARBs. Architecture decisions happen through peer review, consultation with platform teams, or just individual team autonomy. This works when the organization is small, technical culture is strong, and there’s good informal coordination.

Other organizations have very heavyweight architecture processes with multiple review stages, formal documentation requirements, and governance that slows everything down. This might be necessary in highly regulated industries or very large organizations where coordination complexity is high.

We’re somewhere in the middle. Lightweight but deliberate. The right level of process for our size and needs. As we grow, we’ll probably need to evolve the process again.

Worth It or Not?

Is maintaining an ARB worth the effort? For our organization, yes. The coordination value and mistake prevention outweighs the overhead. But it requires continuous attention to keep it valuable rather than bureaucratic.

The measure of success is whether teams engage with the process voluntarily. If teams bring proposals proactively because they value the input, it’s working. If teams are trying to avoid or bypass review, something’s wrong.

After five years, we’re mostly in the former category. Teams generally appreciate the feedback and see value in coordination. That’s the only reason the ARB continues to exist. The day it becomes pure bureaucracy is the day we should shut it down.