Driving Platform Adoption
Getting busy, siloed teams to adopt your internal platform — by treating it as a product, not a mandate.
This question tests whether you can win voluntary adoption of infrastructure you build. Owning a great platform is worthless if the teams who should use it stay on their old paths. For a horizontal infra leader, adoption is the impact — and you rarely have the authority to force it. The interviewer wants to see you think like a product owner: understand the internal customer, quantify their ROI, remove every gram of migration friction, prove value with lighthouse users, then close the old door. The answer follows the CARL shape — Context, Actions, Results, Learnings — and is judged on whether you drove adoption by pull, not push.
What this question is really testing
Do you treat an internal platform as a product with customers who have a choice — earning adoption through value and low friction — or do you assume “build it and they will come” and then blame the teams when they don’t?
How to answer- Treat the platform as a product. Your users are engineers with choices and deadlines; you have to earn their adoption the way any product earns a customer — with a compelling value proposition, not an org mandate.
- Lead with internal-customer empathy. Sit with the teams you want to migrate, learn their real workflow and pain, and design for it. Adoption stalls when the platform solves the builder’s problem instead of the customer’s.
- Articulate the ROI in their terms. Show the concrete win — hours of on-call saved, cost reduced, a class of bug eliminated, faster launches — so switching is an obvious net gain, not a leap of faith.
- Make migration near-zero-effort. The single biggest lever. Ship codemods, adapters, backfill tooling, and sane defaults so the cost of moving approaches zero. Every hour of migration work you push onto a team is an hour they’ll spend not adopting.
- Land lighthouse users, then deprecate the old path. Get one or two respected teams live and turn their success into social proof; then, once the new path is clearly better and migration is easy, set a dated deprecation of the old path so staying put stops being free. Track coverage as a metric the whole way.
- A product mindset — customers, value proposition, empathy — applied to internal infra.
- Friction treated as the primary enemy of adoption, attacked with tooling.
- ROI stated in the customer’s currency, backed by numbers.
- Lighthouse users and social proof rather than a top-down edict.
- Deprecation used deliberately to close the old path, plus adoption tracked as a metric.
A worked example (CARL)
Context. My team built a new ads events ingestion client that gave exactly-once semantics and cut per-event cost, replacing a legacy logging path that a dozen product teams used. Six months after launch, adoption was stuck around 15%. The platform was technically better, but teams weren’t moving — migration looked like risky, undifferentiated work on someone else’s roadmap.
Actions. I stopped treating low adoption as a motivation problem on the teams and started treating it as a product problem on us. I embedded with two of the stalled teams for a week and watched them actually try to migrate — and found the real blocker: our “migration guide” was a 20-step wiki that assumed deep knowledge of the new schema, and the client needed hand-written config that was easy to get wrong. So I re-cut the roadmap around friction. My team built a codemod that rewrote the old call sites automatically, an adapter that let the new client read the old config so most teams changed nothing, and a shadow mode that let a team run new and old side by side to build confidence before cutting over. Next I rebuilt the ROI case in their language: instead of “exactly-once semantics,” I showed each team the specific duplicate-event bugs and on-call pages the new client would have prevented last quarter, and the dollar cost they’d each save, pulled from Scuba. Then I went for lighthouse users — I picked the most respected and the most skeptical of the twelve teams, did the migration with them so it cost them almost nothing, and had them post their before/after numbers on Workplace. That turned the narrative from “infra wants us to do work” to “the teams we trust already did this and it paid off.” Finally, with migration now a near-zero-effort path and two proof points live, I published a dated deprecation for the legacy client and worked the long tail team by team, offering to send the codemod diffs myself.
Results. Adoption went from about 15% to over 90% of event volume in one quarter, the legacy path was fully deprecated a quarter after that, and the teams that migrated saw duplicate-event on-call pages effectively go to zero. The codemod-plus-adapter approach cut the typical migration from an estimated multi-day project to a single reviewed diff.
Learnings. Technical superiority does not drive adoption — low friction and credible proof do. The highest-leverage work wasn’t on the platform itself; it was on the migration path and the social proof. And deprecation only works after the new path is genuinely easier, or it just breeds resentment.
Common follow-ups
A powerful team refuses to migrate. What do you do?
How to answer- Understand the real objection. Refusal usually hides a genuine gap — a missing feature, a risk, a bad past experience. Find it before you push.
- Close the gap or reduce the cost. If it’s a real need, fix it; if it’s effort, do the migration for them.
- Use ROI and social proof. Show them peers who moved and the numbers they gained — let evidence, not authority, do the work.
- Escalate on cost, not preference. If their staying put imposes a real org cost (dual maintenance, blocked deprecation), escalate that tradeoff cleanly for a decision.
How do you measure adoption — and is a raw count enough?
How to answer- Measure weighted coverage, not logo count. Percentage of traffic, cost, or events on the new path matters more than number of teams.
- Track active, healthy usage. Integrated-but-idle isn’t adoption — watch real, sustained use and error rates.
- Watch the long tail. The last 10% blocks deprecation and often costs the most; track it explicitly to zero.
- Tie to the outcome. Ultimately adoption should move the goal it was meant to — cost, reliability, velocity.
How do you handle the long tail that never migrates?
How to answer- Segment it. Separate “hard” (real technical blockers) from “low-priority” (just not urgent) — they need different treatment.
- Concierge the hard cases. Do the migration for them or build the one missing capability they need.
- Set a hard deprecation date. A firm, communicated cutoff converts “someday” into “this sprint.”
- Escalate the true stragglers. For teams that won’t move despite easy path and clear ROI, make the cost of the old path visible to leadership.
- Adoption dashboards (Scuba / Unidash) — pull the coverage curve: percentage of traffic, cost, or events on the new path over time.
- GSD — pull from the platform-adoption project and the per-team migration tracking to zero.
- Workplace posts / announcements — pull the launch, the lighthouse-user before/after, and the deprecation notice you published.
- Phabricator — pull the codemod, adapter, or migration diffs that made switching near-zero-effort.
- The internal wiki — pull from the migration guide and deprecation timeline you set for the customer teams.