Should Enterprise Architects Do Code Reviews? Why the Answer Is (Usually) No

Last week, I made a comment that stirred quite a bit of discussion—both online and offline. The statement? Enterprise Architects (EAs) should not be doing code reviews.

The reaction was swift and passionate. Some agreed, some disagreed, and many asked for more context. So here it is: a deeper dive into why EAs should focus on the ‘why,’ ‘what,’ and ‘when,’ and leave the ‘how’ to the domain experts.

What’s the Role of an EA, Really?

Enterprise Architecture isn’t about syntax, linting, or pull requests. It’s about aligning technology strategy with business goals. It’s about ensuring teams are moving in the same direction—on the right road—at the right speed.

When EAs spend time in code reviews, they’re working in the system, not on it. That’s a critical distinction.

Why EAs Shouldn’t Be Doing Code Reviews

1. It’s a Misallocation of Talent
2. It Disempowers SMEs
3. It Undermines Strategic Work

So Why Do EAs Sometimes End Up in Code Reviews?

Let’s be honest—it’s usually not because they want to. There are a few reasons this happens:

• Organizational immaturity: When architecture roles aren’t well understood, EAs are pulled into tactical tasks.
• Cultural legacy: If you rose up through engineering, it’s hard to let go of the code.
• Gaps in governance: Sometimes, EAs step in because no one else is ensuring quality.

The Three Paths to Becoming an EA

Understanding how someone got into the EA role often explains their tendencies. Here are the three most common archetypes I’ve observed:

1. The Technologist

This person came up through engineering. They wrote the best code, designed the best systems, and got promoted through sheer technical brilliance. They likely focus on the “how” and have a deeply ingrained bias toward execution.

• Strengths: Technical depth, credibility with engineers, practical solutions.
• Risks: May struggle to zoom out, might over-index on implementation.

2. The Fixer

This is the get-it-done operator. They may have stumbled into EA by solving so many problems they became the default glue in the organization. Their motto? “If a screw needs tightening, I’ll do it myself.

• Strengths: Adaptability, cross-functional empathy, delivery mindset.
• Risks: May resist delegation, operate more as a super-SME than an architect.

3. The Strategist

This EA came from academia, business analysis, or enterprise strategy. They studied TOGAF or Zachman before ever writing a line of code. They see patterns, frameworks, and long-term trends.

• Strengths: Strategic thinking, model-driven planning, boardroom communication.
• Risks: May lack delivery credibility, risk being perceived as “ivory tower.

The Common Denominator: Being a Value Multiplier

Regardless of your path, the EA’s job is to multiply value. Sometimes that’s by enabling faster delivery, sometimes by guiding long-term investment in the right capabilities.

Doing code reviews might give short-term gains, but it rarely compounds. Your energy is better spent lifting the entire capability maturity of the organization.

If better code quality is today’s lever for business value, fine—get involved temporarily. But use that opportunity to create standards, platforms, and feedback loops that scale beyond your involvement.

Final Thought: Know Your Altitude

Enterprise Architects operate at altitude. Your job is to see the terrain, weather, and destination. Engineers fly the plane.

If you keep dropping into the cockpit to adjust the rudder, you’re not doing your job—and worse, you’re probably disempowering someone who could do it better.

Stay focused on the why, what, and when. Leave the how to the experts. That’s how you create real, lasting impact.