The Architecture Review That Went Dark

“You proposed a major platform change. 2 months later, it's stalled. Two tech leads ghosted. One EM pushed back publicly. You have no authority.”

The Situation

You're a Principal Android engineer who proposed a significant platform-level change: migrating 6 teams from a legacy event bus to a coroutine-based state management system. The change is technically correct — the event bus is causing race conditions that have now surfaced in 3 production incidents. Two months into the review process, two tech leads stopped responding, one EM pushed back in a design doc comment, and the business team started building around the proposal.

Context

You have no direct authority over any of the 6 affected teams — you're an IC, not a manager
The two silent tech leads were vocal supporters initially; the silence came after their EMs were looped in
The EM who pushed back publicly cited 'migration risk' but didn't engage with the technical details
Business teams routing around the proposal suggests they expect it to fail or be indefinitely delayed
Three production incidents in the past quarter have root causes that trace back to the event bus

The Question

“Tell me about a time you had to drive a large, cross-organizational technical change and encountered significant resistance. What did you do?”

Response Options

One of these is the strongest response. The others reflect common approaches with real trade-offs.

I escalated to my manager and asked them to use their organizational authority to force the review to a conclusion.

I reached out to each silent tech lead individually to understand their actual concerns, separately had a direct one-on-one with the resistant EM to understand the migration risk concern specifically, and proposed splitting the proposal: 3 willing teams migrate now as a pilot, producing data that addresses the resistant EM's concerns before the remaining teams commit.

I revised the proposal to address the migration risk concerns, sent an updated doc to all 6 teams, and set a two-week deadline for final feedback.

I withdrew the proposal, waited for the next production incident to create urgency, and reintroduced it with the incident data as evidence.

The Debrief

Why the Best Response Works

Answer B works because it treats the stall as an information problem, not a resistance problem. The two silent tech leads likely have concerns they didn't feel safe raising publicly — 1:1 conversations surface those. The resistant EM's concern is 'migration risk,' which is legitimate and addressable. The pilot proposal gives everyone a lower-stakes way to say yes.

What to Avoid

Interpreting silence as agreement or opposition. Silent tech leads are usually navigating internal pressure from their own managers. The biggest mistake is sending more documents without first understanding why the existing ones haven't moved people.

What the Interviewer Is Probing

The interviewer is testing whether you understand that Principal-level technical change is fundamentally a social problem with a technical solution, not a technical problem with a social obstacle. Can you navigate organizational resistance without authority? Can you design a path that gives resistant stakeholders a way to win?

SOAR Structure

**Situation:** 6-team coroutine migration proposal stalled after 2 months — 2 silent tech leads, 1 resistant EM, business routing around. **Obstacle:** No authority; organizational anxiety; unspoken concerns blocking progress. **Action:** 1:1 interviews with each silent tech lead (revealed: EM pressure over timeline); direct 1:1 with resistant EM (revealed: specific integration risk, not general opposition); proposed 3-team pilot with metrics designed with the resistant EM. **Result:** Pilot launched with 3 teams; data gathered; remaining 3 teams opted in; migration complete in 6 months; zero race condition incidents in the subsequent quarter.

The Learning Arc

"This taught me that when a technical proposal stalls, the document is almost never the problem. The problem is always a person whose concern hasn't been surfaced yet. I now build a stakeholder interview step into every large technical proposal before I start asking for decisions — not to gather support, but to find out what would need to be true for each person to feel safe saying yes."

IC Level Calibration

senior

Identify who the blockers are, have direct conversations with them, revise the proposal to address specific concerns, and ask for an explicit decision from each stakeholder.

staff

Investigate the root of resistance (often the EM layer, not the tech leads). Separate the willing teams from the resistant ones. Propose a phased or pilot approach that lowers the decision risk for skeptics.

principal · Primary Target

Recognize that silent stakeholders signal organizational anxiety, not technical disagreement. Do 1:1 stakeholder interviews before sending any more documents. Reframe the proposal as a pilot with success metrics. Use the resistant EM as a design partner for the pilot criteria — making them an author of the validation process, not an observer.

Company Calibration

Amazon

LP: Earn Trust + Have Backbone; Disagree and Commit