Posted by
The architect is often called upon when a project hits a crisis point. Project management analyzes the initial numbers, compares progress to costs, and the alarm bells go off: a significant gap is widening. Inevitably, a showdown ensues between the “top” of the tower, the decision-makers, and the “bottom,” the delivery team.
The simplistic, accusatory question drops: was the project poorly estimated, or is the team not productive enough?
From their ivory tower, a disconnected architect is tempted to shift the blame downward: poor performance, flawed analysis, lack of rigor… But the reality is always more complex. By getting down on the ground, you discover the real reasons: a misunderstood functional requirement, an underestimated learning curve for a new technology, unforeseen dependencies.
Your role isn’t to assign blame, but to understand reality and translate it.
The Ivory Tower Trap: When Strategy Disconnects from Reality
For many architects in transition, the temptation to over-invest in strategy is strong. It’s the new area where they feel less comfortable, and they want to prove their worth. In doing so, they neglect to maintain their technical skills, which erode far faster than they imagine.
This disconnection creates a dual anxiety: the fear of becoming obsolete and the fear of losing credibility. They end up proposing “trendy” solutions without validating them on the ground, which erodes the team’s trust—the very people who have to live with the consequences.
Using the “Elevator” Metaphor: Becoming a Translator Between Strategy and Code
Gregor Hohpe, in his foundational article The Architect Elevator on Martin Fowler’s blog, popularized the idea of the “Architect Elevator.” This metaphor is brilliant because it redefines our role: we are not the guardians of a single floor, but the operators of the elevator that connects the “penthouse” (business strategy) to the “engine room” (the reality of the code).
Our job is to circulate information in both directions. We must go down to translate the strategic vision into clear technical constraints, and we must go up to communicate the challenges and discoveries from the ground to the decision-makers. A plan is an excellent starting hypothesis, but it’s continuous communication that allows it to adapt to the reality on the ground.
Keeping Your Hands on the Code (Without Necessarily Writing Production Code)
Staying relevant doesn’t necessarily mean writing code that goes into production. The developers on the team will always be faster and more focused on that aspect, and that’s as it should be.
Your technical contribution takes another form: developing proofs-of-concept to de-risk a new technology, automating repetitive tasks for the team, actively participating in code reviews, or contributing to the technology watch. These actions allow you to maintain direct contact with the source code, understand the real challenges, and ensure that architectural guidelines are being followed—or evolve them when necessary.
Becoming a “Problem Radar”: Earning Credibility on the Ground
By being present, you shift from a reactive to a proactive mode. You no longer suffer through crises; you anticipate them. Your “radar” becomes more refined. You detect friction, misunderstandings, and technical risks more quickly.
This presence on the ground is the foundation of your legitimacy. The team sees you as an ally who understands their constraints, and decision-makers see you as the one who secures the investment by connecting strategy to its actual execution. Trust is built here, not in a meeting room.
Put It into Practice This Week: Reconnect with the Code
The best way to break the isolation is to go back to the source. I propose a simple challenge: this week, trade one hour of a strategy meeting for one hour of concrete immersion with the team. To put this idea into action, here are a few suggestions:
- Join a code review: Don’t lead it. Listen, ask questions to understand the trade-offs the developers made.
- Offer a pair-programming session: It’s the perfect tool. Offer your help on a blocking point to understand the reality on the ground while bringing your big-picture view.
- Analyze a recent Pull Request: Take the time to understand not just the code, but also the context of the task. Leave a positive comment or a constructive question.
The goal isn’t to judge, but to understand. It’s the first step to getting the elevator to come back down.
Conclusion
The true value of an architecture isn’t measured by the elegance of its diagrams, but by its ability to be implemented effectively by the team and to meet the real challenges of the business.
Don’t just send the plans down; go down with them. Your greatest insights won’t come from the conference room, but from a whiteboard discussion with those who turn your diagrams into code.