How Engineering Leaders Use the Architect Elevator
For Engineering managers and VPs of Engineering · Based on Hohpe Architect Elevator Methodology
// TL;DR
Engineering managers and VPs don't need to be the architect—but they need to create the conditions for architecture to work. The Hohpe Architect Elevator Methodology gives you a shared language with your architects: you'll understand why they use Common Framing instead of mandating patterns, why they evaluate designs as 'suitable' rather than 'good,' and how to protect their political capital so they can spend it where it matters. Use this methodology to coach architects on your team, recognize the oracle anti-pattern before it calcifies, and construct Architect Elevator pitches that connect technical strategy to business outcomes for your own leadership chain.
Why do architecture initiatives stall in engineering organizations?
Architecture stalls when the organization treats the architect as either an oracle or a rubber stamp. In the oracle anti-pattern, every decision flows through one person, creating a bottleneck that slows teams and prevents capability-building. In the rubber stamp anti-pattern, the architect reviews designs after they're built and has no real influence. The Hohpe methodology provides a third path: the architect as amplifier—someone who makes every team smarter without becoming a dependency.
As an engineering leader, your job is to create the organizational conditions for this amplifier model to work. That means protecting the architect's time, giving them access to the penthouse (executive conversations), and resisting the urge to use them as a decision-making shortcut.
How do you coach architects using the Hohpe methodology?
Watch for three signals that an architect is falling into anti-patterns:
Oracle behavior: Teams line up with questions and leave with pronouncements. The architect is making decisions instead of helping teams make better decisions. Coach them to use the Phantom Sketch Artist technique—draw what they understood and let the team correct them—rather than arriving with the answer.
Buzzword architecture: The architect tells teams everything must be "cloud native" or "event-driven" without situational reasoning. As Hohpe says, a Post-it on the wall can do that. Coach them to articulate trade-offs against actual business constraints, not abstract pattern rankings.
Political capital overspend: The architect challenges every project and becomes the person nobody wants in the room. Coach them on selectivity: pick one high-stakes issue, build the case with trade-offs, and let smaller issues go. The jester's power comes from credibility and selectivity, not volume.
How do you use Common Framing to unstick cross-team debates?
When two teams are deadlocked—typically in a 40-message Slack thread—apply Hohpe's Step 2 yourself. Convene a session, identify the underlying dimensions being conflated, and build a shared map (a 2×2 matrix, a decision table, or a named set of options). This Common Framing is not up for debate; it's the coordinate system on which discussion happens.
For example, if teams argue about whether to share a database or use separate stores, map data consistency requirements against team autonomy requirements. The debate shifts from "my camp vs. your camp" to "which quadrant matches our actual constraints." You don't need to be the technical expert—you need to be the person who insists on a shared map before anyone picks a position.
How do you connect technical architecture to business strategy for your leadership chain?
This is the Architect Elevator pitch (Step 7). When presenting a technology strategy to your VP or CIO, you need both a catchy, named visual AND the ability to defend every element technically when probed. Executives won't challenge your Kubernetes choice—they'll ask: "What alternatives did you consider? What does success look like? Could we defer this?"
Name your model to make it sticky ("The Platform Maturity Ladder," "The Migration Quadrant"). Ensure the technical foundation and the story live in your head—don't split the narrative to a slide designer and keep the logic in a separate document. The ping-pong between left-brain rigor and right-brain storytelling must happen in one person, and for this audience, that person is you.
What's your next step?
In your next 1:1 with an architect on your team, ask them to describe a recent decision they facilitated. Listen for whether they articulated trade-offs or delivered verdicts. If they delivered verdicts, introduce the Hohpe principle of 'suitable, not good or bad' and discuss how to shift their approach for the next review.
// FREQUENTLY ASKED QUESTIONS
How do I know if my architect is falling into the oracle anti-pattern?
Watch for dependency signals: teams cannot make design decisions without the architect in the room, the architect's calendar is fully booked with review meetings, and team leads describe the architect as 'the person who approves our designs.' In the amplifier model, teams should be able to make most decisions independently, seeking the architect as a sounding board for high-stakes trade-offs rather than as an approval gate.
Should engineering managers learn architecture methodology even if they have architects on staff?
Yes. Understanding the Hohpe methodology gives you a shared language with your architects and helps you protect the conditions they need to succeed. You'll recognize when they're being pushed into oracle mode, when they need political cover to call out a Wily Coyote situation, and when they need access to the penthouse to align technical strategy with business outcomes. You don't need to do the architecture—you need to enable it.
How do I protect my architect's political capital?
Don't use your architect as a weapon to kill projects you disagree with—that burns their jester credibility. Don't put them in a position where they must approve every design (oracle trap). Give them cover when they call out a genuine Wily Coyote situation by backing their analysis publicly. Let them choose which battle to fight; selectivity is what makes their interventions credible and impactful.