CASE STUDY — Part IX: Leading a Migration Without Authority (Cross-Team)

SCENARIO

You need to migrate from legacy auth to a new auth service.

6 teams
no direct authority
everyone is busy

Leadership is the ability to create motion anyway.

Why migrations fail: Cross-team migrations often stall because: (1) no single owner—everyone assumes someone else will do it; (2) teams have different priorities—your migration is their distraction; (3) unclear payoff—"why should I spend 2 weeks on this?"; (4) high perceived risk—"what if we break production?"; (5) friction—no docs, no SDK, no examples. Statistics from industry: migrations without a dedicated driver and clear incentives take 2–3x longer or never complete. The key is to reduce friction, demonstrate value, and create visible progress so teams want to migrate.

ALIGN ON WHY (THE LEVER)

Create a one-page narrative that makes the case emotionally and technically clear.

Template:

Risk of staying: What happens if we don't migrate? Security vulnerabilities, scaling limits, compliance gaps, tech debt cost. Example: "Legacy auth has no MFA support. Our SOC 2 audit flags this. We have 6 months to fix or lose enterprise customers."
Benefits of moving: What do teams gain? Simpler code, better performance, new features. Example: "New auth supports SSO out of the box. No custom integration per customer."
Timeline pressure: Why now? Audit deadline, deprecation date, incident post-mortem. Example: "Legacy service is deprecated Q3. We must be off by then."

"Risk of staying" examples:

"Legacy system has no rate limiting. One misbehaving client can take down auth for everyone."
"We can't add new identity providers without forking the legacy codebase."
"On-call for legacy auth is 3x the pages of the new service."

Make it tangible. Abstract "tech debt" doesn't move people. "You'll get paged less" does.

PROVIDE THE PATH OF LEAST RESISTANCE

Migration toolkit—what to build:

Artifact	Purpose	Detail
Migration guide	Step-by-step instructions.	"1. Add new SDK. 2. Replace 3 lines. 3. Test. 4. Deploy. 5. Remove old client." Include screenshots, code snippets, troubleshooting.
SDK / client	Drop-in replacement.	Same interface as legacy, new backend. Teams change import and config—minimal code churn.
Example PR	Show, don't tell.	A real PR from a pilot team. "Here's what our migration looked like. 47 lines changed."
Office hours	Live support.	30 min weekly. "Bring your migration questions." Reduces back-and-forth in Slack.
Runbook for rollback	Reduce fear.	"If something breaks, revert this config. We'll fix and retry."

Senior rule:

Influence is removing friction, not demanding compliance.

BREAK INTO MIGRATION WAVES

Wave planning template:

Wave	Teams	Criteria	Duration
Pilot	1 team (volunteer or low-risk)	Small service, good test coverage	2–3 weeks
Wave 1	2 teams	Similar stack to pilot	3–4 weeks
Wave 2	Remaining teams	Learn from Wave 1 pitfalls	4–6 weeks

Pilot criteria: Choose a team with: (1) willingness to be first; (2) service that's not mission-critical at 3am; (3) ability to move fast. Document every pitfall they hit. Update the guide. The pilot's job is to de-risk the path for others.

Rollback strategy per wave: Before each wave, define: "If error rate spikes > X% or latency > Y ms, we pause the wave and roll back the migrated services." Have a rollback runbook. One team rolls back without blocking others.

Document pitfalls: After each wave, publish "Lessons learned." "Team A hit issue with token refresh—here's the fix." Reduces repeat mistakes.

DEFINE SUCCESS + TRACK IT

Dashboard design:

% traffic on new auth: By service, by team. "Team A: 100%. Team B: 45%. Team C: 0%."
Error rates: Compare legacy vs new. Alert if new > legacy.
Top blockers: Tagged by team. "Team C blocked on: SDK doesn't support our async pattern." Visible so you can unblock.

Communication cadence:

Weekly: Migration status email. "Wave 1 complete. Wave 2 at 60%. Blockers: [list]."
Bi-weekly: Sync with team leads. "What do you need to unblock?"
Monthly: Metrics review. "We're at 70% traffic. On track for Q3."

Visibility creates accountability. When teams see others progressing, they feel pressure to move. When they see blockers, they know help is available.

EXERCISE

Write your migration RFC. Include:

Phases: Pilot, Wave 1, Wave 2. Timeline. Who's in each.
Risk: What could go wrong? How do you mitigate? (e.g., "Pilot finds SDK bug → we fix before Wave 1.")
Rollback: Per-wave rollback criteria. Who decides? How long to roll back?
What you need from each team: "2 engineer-days for migration. 1 hour for office hours if blocked." Be explicit.
Stakeholder management: How do you get buy-in from team leads who don't report to you? What's the escalation path if a team refuses or delays? Draft the message you'd send to a reluctant team lead: acknowledge their priorities, state the shared goal, offer the path of least resistance, and ask for a specific commitment (e.g., "Can you assign one engineer for the sprint of 3/15?").

Sample message to reluctant team lead:

Hi [Name], I know your team is focused on [their priority]. The auth migration is a shared dependency—we all need to be off legacy by Q3. I've put together a migration guide and SDK that should make this a 1–2 day effort. Would you be open to a 15-minute sync to see if we can slot this into your next sprint? I can also join your standup to answer questions. The alternative is we hit the deprecation deadline and have to scramble—I'd rather avoid that.

Escalation path: If a team repeatedly delays: (1) Document the blocker. (2) Share with your manager and theirs. (3) Propose a concrete ask: "We need [X] by [date] to stay on track." (4) If still blocked, escalate to program lead or engineering leadership. Frame as "shared risk," not "they're not cooperating."

🏁 END — PART IX CASE STUDY