The Architecture That Nobody Adopted

“You designed the perfect modular architecture. You published the RFC. Three teams read it. Zero teams adopted it. What went wrong?”

The Situation

You're a Staff Android engineer who spent a quarter designing a new modular architecture for the Android codebase — a feature-module structure with clear dependency rules, a shared design system layer, and a navigation contract. You published a thorough RFC with a migration guide and sample code. Six weeks later: 3 teams have read it, posted positive comments, and continued building on the old architecture. No migration has started.

Context

All three teams agreed the new architecture was technically superior
The migration guide estimates 3–4 weeks per team for the initial module extraction
All three teams are currently in the middle of their own Q3 roadmaps with no slack time
Two teams have expressed that they'd adopt it 'next quarter' for the past two quarters
Engineering leadership has not formally mandated the new architecture — it's opt-in

The Question

“Tell me about a time a technical initiative you drove didn't get the adoption you expected. What did you learn about driving organizational change?”

Response Options

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

I asked engineering leadership to mandate the new architecture and set a deadline for all teams to migrate, since voluntary adoption wasn't working.

I analyzed why adoption hadn't happened: the migration cost (3–4 weeks per team) was real, not theoretical, and teams had no slack. I built a migration toolkit that automated 60% of the module extraction, offered to embed with each team for 2-day migration sprints, and piloted with the most willing team to generate a public proof point. Once that team's velocity improved measurably post-migration, the other two teams scheduled their migrations without being asked.

I held a monthly architecture review meeting where teams presented their progress toward adoption, creating social accountability for migration.

I accepted that the architecture would be adopted gradually over time as teams finished their current roadmaps and had natural migration windows.

The Debrief

Why the Best Response Works

Answer B demonstrates the key insight: adoption fails are almost never persuasion failures — they're switching cost failures. The teams agreed the architecture was better. They didn't adopt it because the migration cost (3–4 weeks) had no space in their roadmaps. Reducing the cost to 2 days with a toolkit and an embedded engineer removes the only blocker that mattered. The proof point from the pilot team creates the social evidence that makes the other migrations feel safe.

What to Avoid

The mandate is the most common Staff engineer response to adoption failure, and it almost always backfires. Mandates work when switching cost is low and compliance is verifiable — they fail when switching cost is high and compliance is easy to fake. Mandating a 3–4 week migration without creating capacity for it produces half-migrations and resentment. The RFC already made the case for 'why' — the missing piece was 'how, cheaply.'

What the Interviewer Is Probing

The interviewer is evaluating whether you understand that technical influence is change management, not just documentation. An RFC is a proposal. Adoption is the outcome. The gap between them is switching cost, organizational momentum, and proof. Staff engineers who close that gap by making adoption easy are more effective than those who close it by making non-adoption painful.

SOAR Structure

**Situation:** New modular architecture RFC published; 3 teams agreed it was better; zero migrations started after 6 weeks. **Obstacle:** 3–4 week switching cost per team; no roadmap slack; 2 quarters of 'next quarter' precedent. **Action:** Root-cause analysis confirmed capacity (not conviction) was the blocker; built migration toolkit automating 60% of module extraction; embedded with Team A for a 2-day pilot sprint; published before/after velocity metrics. **Result:** Team A adopted in 2 days; Teams B and C scheduled migrations without being asked; all three migrated by end of quarter.

The Learning Arc

"This taught me that the most important sentence in any RFC is not the architecture diagram — it's the migration guide. If the migration guide says '3–4 weeks,' you've written a proposal that most teams will read and file. If the migration guide says '2 days with the toolkit,' you've written a proposal that teams will execute. I now write the migration experience before I write the architecture. The architecture serves the adoption, not the other way around."

IC Level Calibration

senior

Identify the switching cost as the blocker, offer to pair with each team during migration, and build a simple migration script for the most mechanical parts.

staff · Primary Target

Build the full migration toolkit, pilot with the most willing team, instrument the velocity improvement, and publish the before/after metrics as the social proof that pulls the other teams in. Make adoption the default path by reducing the cost below the threshold of resistance.

principal

Same as staff, plus: work with engineering leadership to build the new architecture into the team onboarding process and the new service template. Make the new architecture the default starting point for any new module or service — so adoption is the path of least resistance from day one.

Company Calibration

Google

Technical leadership: make adoption easier, not just correct