Coordinating a Migration Across Distributed Teams
Final Prep · Cross-functional Partnerships — how to drive a massive architectural migration to 100% across globally distributed teams with competing priorities, without direct authority over any of them.
This question tests the program and org-coordination lens of a migration, not the technical cutover mechanics. The hard part of a platform-wide migration is rarely the code; it is getting fifty teams in five timezones — each with its own roadmap, its own manager, and no reporting line to you — to actually do the work and finish it. The interviewer wants the coordination machinery: a dependency map that lets you sequence the work, a tracker/scorecard that makes per-team status visible, a single DRI per workstream, an async-first communication cadence across timezones, a way to align teams without authority, landing-zone tooling that makes migrating cheap, clear unblocking and escalation paths, and the discipline to drive to 100% and deprecate the old system. Answer in CARL shape. The technical mechanics — phasing, backward compatibility, reversibility — live in Leading a Cross-functional Migration, and the async operating model lives in Managing Globally Distributed Teams.
What this question is really testing
Whether you can run a program where you own the outcome but not the people. Anyone can announce a migration; the senior signal is treating adoption as a system you engineer. That means making status legible so no team can quietly stall, reducing the per-team cost of migrating until the new path is easier than the old, and creating incentive alignment — a shared goal, an exec sponsor, and eventually making the old path costlier — instead of relying on nagging. It also means understanding that a migration is only done when the old system is deprecated and deleted; the last 10% and the long tail of stragglers are where most migrations die, and a leader who plans for that tail from day one is the one who actually finishes.
How to answer- Map and sequence the dependency graph. Before asking anyone to move, know who depends on whom — which teams are blocking others, which can go in parallel, and the critical path. Sequence the rollout so upstream foundations land before the teams that build on them.
- Make status legible with a tracker/scorecard. A single source of truth showing per-team status — not started, in progress, migrated, verified — with a percentage to 100%. Visibility is leverage: teams behave differently when their status is on a shared scoreboard.
- Assign one DRI per workstream. Every workstream and every migrating team has a single named owner accountable for its slice. Diffuse ownership is why migrations stall; a clear DRI is who you talk to when a number stops moving.
- Run an async-first cadence across timezones. Written decisions of record, a regular written status update, and office-hours rather than mandatory meetings, so a team in any timezone can self-serve answers and no decision is trapped in one region’s working hours.
- Align without authority, and make the old path costlier. Anchor everyone on a shared goal and an exec sponsor who has publicly backed the target date. Then shift incentives: land the new path as the default, and progressively make the old path more expensive — deprecation warnings, freezes on the old system, finally removing it.
- Reduce per-team effort with a landing zone. Self-serve tooling, migration scripts, codemods, templates, and a golden-path guide so each team’s work is hours, not weeks. The cheaper you make migrating, the less you have to push.
- Build unblocking and escalation paths, then drive to 100%. A clear route for teams to raise blockers and a defined escalation ladder to the sponsor when a team won’t move. Track the long tail explicitly, and don’t declare victory until the old system is deprecated and deleted.
- You treat adoption as an engineered system — dependencies, tracking, tooling — not as an announcement.
- You know how to move teams you don’t manage: shared goal, sponsor, incentives, and making the old path costlier.
- You make status legible and hold a named DRI per workstream accountable.
- You default to async and written across timezones so the program isn’t bottlenecked on any one region.
- You plan for the long tail and define done as the old system deprecated, not the new one available.
A worked example (CARL)
Context. Ads Events Infra needed to move every event-producing service off a legacy ingestion client onto a new schema-validated pipeline — roughly 40 producer teams spread across three regions with an eight-to-twelve-hour spread. The old client was a reliability liability: it silently dropped malformed events and was the root cause of a string of data-quality SEVs. The new pipeline fixed that, but it wasn’t anyone’s priority except mine and my director’s. Every producer team had its own half-year roadmap, none reported to me, and the first informal ask had produced a handful of early adopters and then total silence. I owned the outcome — deprecate the legacy client — with zero authority over the people who had to do the work.
Actions. I ran it as a program, not a request. First, I built the dependency map: I instrumented the legacy client to emit per-service call volume so I actually knew who the 40 teams were, ranked by traffic, and I identified the shared libraries several teams depended on — those had to migrate first or everyone downstream would be blocked. That gave me a sequence: foundational libraries, then the high-volume producers, then the long tail. Second, I stood up a scorecard — a single dashboard with one row per team showing status (not started / in progress / migrated / verified) and a live percentage of traffic still on the old client. I made it visible to all the teams and to the exec sponsor, because a public number is leverage a private ask never has. Third, I assigned a DRI per workstream and got each migrating team to name a single point of contact, so I always knew exactly who owned a stalled row. Fourth, I fixed the coordination model for the timezone spread: a weekly written status post as the decision of record, a short async FAQ that grew every time someone hit a snag, and rotating office-hours in two timezone-friendly slots instead of one meeting that was midnight for a third of the teams. Fifth — the highest-leverage move — I invested in a landing zone: a codemod that did most of the client swap automatically, a golden-path doc, and a test harness that let a team prove their events validated before cutover. That turned a multi-week task into a day or two for most teams. Sixth, I aligned incentives with my sponsor: they set a company-visible target date, we made the new client the default in the service scaffolding so all new services were born migrated, and we announced a dated freeze — after date X, the old client would start emitting loud deprecation warnings, and after date Y it would be removed. That progressively made the old path costlier than the new one. Finally, I worked the long tail by hand: a clear escalation path where a genuinely blocked team got engineering help from my side (I had two engineers embed to unblock the hardest producers), and for the teams that were simply deprioritizing it, a short, factual escalation to their manager through the sponsor.
Results. We took traffic on the legacy client from 100% to under 2% in about two quarters, and to zero — old client deleted — a month after that. The codemod alone accounted for roughly 30 of the 40 teams migrating with no direct help from my team, which is the only reason a group my size could drive 40 teams at all. Data-quality SEVs attributable to malformed events dropped to zero after the cutover, which was the number the sponsor actually cared about. And because the old system was genuinely deprecated rather than left running “just in case,” we retired the legacy service and recovered its footprint instead of paying to keep two pipelines alive.
Learnings. The move that mattered most wasn’t the scorecard or the escalations — it was the codemod. Every hour I spent making migration cheaper bought more adoption than any hour spent pushing teams to spend their own. My rule now: before you ask N teams to do work, spend your own team’s effort collapsing that work to near-zero, then use tracking and sponsorship only for the residual that tooling can’t solve. And define done as the old system deleted — a migration that stops at 98% has bought none of the benefit and all of the dual-maintenance cost.
Common follow-ups
A high-priority team keeps deprioritizing the migration. What do you do?
How to answer- Diagnose first. Is it genuinely blocked, or just outranked by their roadmap? The fix is completely different, so find out before you escalate.
- Lower their cost. If it’s effort, offer the landing-zone tooling or embed someone to do the bulk of it — often cheaper than a fight.
- Escalate with data, not emotion. Take the scorecard row and the business risk to the sponsor and their manager; let a dated, factual ask do the work.
- Change the incentive. A dated freeze or deprecation warning on the old path turns “later” into “now” without you having to nag.
How do you track progress across so many teams without drowning in status meetings?
How to answer- One scorecard as the source of truth. Per-team status and a live percentage that anyone can read without a meeting.
- Instrument the real signal. Track actual traffic or usage on the old system, not self-reported status — teams over-report progress.
- Async status by default. A weekly written update and office-hours replace standing meetings; sync time is for blockers only.
- Escalate by exception. Only rows that stall get your attention — the dashboard tells you which ones without a check-in.
How is this different from the technical migration itself?
How to answer- Two different problems. The technical side is phasing, backward compatibility, and reversibility — see Leading a Cross-functional Migration. This is the org side: getting teams to act.
- Coordination is the bottleneck at scale. With dozens of teams, the code is often trivial per team; adoption and sequencing are what determine whether it finishes.
- The tooling bridges them. A good landing zone is a technical artifact that solves a coordination problem — it removes the reason teams stall.
- Done is defined on the org side. The migration ends when the last team is off and the old system is deleted, not when the new one ships.
How do you keep the program moving across timezones with no direct authority?
How to answer- Written decisions of record. Every decision lands in a doc or post so no region is excluded for being asleep — see Managing Globally Distributed Teams.
- Shared goal and a visible sponsor. Authority you lack is borrowed from an exec who has publicly backed the date.
- Self-serve over synchronous. Golden-path docs, an FAQ, and office-hours let any team unblock themselves in their own working hours.
- Make the default do the work. New services born on the new path, and a costlier old path, move teams without you chasing them.
- Migration dashboards / ODS — pull the traffic-on-old-system curve from 100% to zero and the per-team adoption over time.
- GSD — pull the workstream tracker, the per-team DRIs, and the dependency sequencing that structured the rollout.
- Workplace posts — pull the weekly written status updates, the deprecation announcements, and the sponsor’s public backing of the date.
- SEV records — pull the data-quality SEVs before the migration and their disappearance after, to quantify the reliability win.
- The internal wiki & 1:1 notes — pull the golden-path guide and landing-zone docs, and the escalation conversations with stalled teams’ managers.