The Architect Trap

When I first took my current job as an enterprise architect at Walmart Global Tech, a mentor of mine gave me a piece of advice. He said, “Don’t become a consultant.” I didn’t really understand what that meant at the time, but the longer I work in this role, the more I see what that means and how easy a trap that is to fall into.

As scope expands it’s easy to drift from ownership into providing opinions and commentary. You turn from a builder into at best a critic and at worst an obstacle.

That’s the architect’s trap.

But it’s not a death sentence. It’s not too late to shake free and start creating momentum and driving outcomes for your teams.

The consultant anti-pattern

The “consultant architect” is probably familiar to you if you’re a software engineer in a company above a certain size. This person is probably showing up pretty late in your SDLC (software development lifecycle) to leave comments on design docs and ask tangential questions about your implementation. You may have come to regard this person not as a resource, but as a stage gate or obstacle that has to be surmounted. This is a dangerous pattern to fall into. From the architect’s perspective, this behavior indicates a distance from execution that weakens judgment and muddles thinking. Architecture becomes just oversight, a checkpoint and bottleneck instead of a force multiplier. That earned technical trust you developed as a day to day coder is replaced by rank and organizational authority. You become a bureaucrat instead of a builder.

The smartest person in the room

As an architect, you’re often the most senior engineer in a particular room. This can lead to the misapprehension that you’re supposed to know everything. In reality, you probably only know somewhat more than you did in your last job, which was not everything. Given your new scope, you’re probably in a lot of rooms where you actually don’t know much at all. Maybe you spent most of your career as a front-end engineer and now you’re asked to weigh in on distributed systems decisions. So what do you do? You’re an architect now so you’re supposed to have an opinion on everything, right? Of course not. When you mentor more junior engineers, you probably tell them it’s okay to say, “I don’t know.” Well, it’s okay for you too. It’s also appropriate to defer to engineers who are more junior than you in many technical matters. As you grow in scope you’ll be indexing more on judgment than anything else. Part of that judgment is assessing who holds the best knowledge and getting them in the room with you. Needing to be the smartest can also lead to another anti-pattern: “disapproval bombing.” This is when an architect vetoes an approach without helping to provide a clear path to solving the business problem the team had set out to address. It’s a lot easier to sound smart by pointing out flaws than it is to commit to driving solutions that may come with problems. Once you stop treating seniority as a license to talk more, you can start actually using it as a tool to help teams deliver.

Leading with service and ownership

Your experience and judgment matter, that’s why you’re in this job. Sometimes we really do save the day by saying no. But the point of the role is not approval. It is acceleration. If you’re showing up late in the SDLC and adding your approval as a gate are you really driving outcomes? How does your role align with the team’s mission?

Consider the mental framing of your role. In my opinion, the architect should be in service of the dev teams they support. guiding, unblocking, and only occasionally standing in the way of a change when it really matters. Good architects are creating clarity. They make goals and paths obvious. The great ones create momentum by removing obstacles and giving a push here and there in just the right places. A great architect sees the path forward clearly and helps others see it too.

Part of this is staying hands on. Given your increased scope, getting bogged down in feature implementation can be very painful for both the architect and the team. You have to be tactical about this. Focus on high leverage contributions that move the needle while not getting in the way of the dev team’s roadmap. Architects are where Jira tickets go to die, after all. It’s a balancing act, but it’s worth it. You do not really understand a system from the review lane alone. Hands-on contribution builds both context and credibility. Reference implementations matter. So as I’ve said before, it’s important that you don’t let go. But staying close to the work is only part of the job. The other part is making sure your intervention scales beyond the team right in front of you.

Optimizing for Compounding Effects

Whether you’re raising pull requests, reviewing design docs, participating in a root cause analysis, it’s important to continually ask yourself one question. Am I optimizing for compounding effects? The architect should be solving not just problems but classes of problems. If you have to step in and correct a problem on a team, how are you ensuring a golden path for other teams not to encounter that same problem? At some level, every architect is a platform engineer. Part of this is building up the engineers around you. What you say matters. So it’s important to balance your criticisms with encouragement. Endorsement takes more accountability than criticism.

The job is not to hover above the work and issue opinions from a safe distance. The job is to help teams move, with better judgment, better defaults, and fewer avoidable mistakes. That means staying close enough to execution to remain useful, humble enough to say “I don’t know,” and accountable enough to own the outcome, not just the recommendation. The longer I do this, the more I think my mentor was right. “Don’t become a consultant” was really a warning not to mistake authority for impact. Architects earn their keep the same way good engineers always have: by creating clarity, building trust, and making the system around them work better after they leave it.