A Different Kind of Hard
Imagine you have just been tasked with something that sounds straightforward: migrate all teams in your organization from the old internal deployment system to the new one. The new system is genuinely better. It is faster, it has better rollback, it has guardrails that prevent entire categories of production incidents. You built it yourself, or you know the team that did, and you are confident in it.
Now imagine there are forty-two teams that need to migrate. You control exactly zero of them.
This is the cross-org initiative. It is the category of project that ends careers not because the technology is hard, but because the people problem is much harder than it looks from the outside. Engineers who are brilliant at building systems often walk into this type of project with entirely the wrong mental model. They assume that if the new thing is better, and they explain clearly why it is better, people will move. They are usually wrong.
Here is the core problem. When you are working within your own team, you can make decisions. You can say "we are switching to the new thing on Tuesday" and it happens. You have authority, shared goals, and direct accountability. The same sentence spoken across an org boundary means almost nothing. The other team's manager has different goals. The engineers on that team have a different roadmap. Their on-call rotation is already stretched. They will agree with you in the meeting and then not prioritize the work for six months because something else is always more urgent.
This is not dysfunction. This is how large organizations work. Understanding it clearly is the first step toward doing anything useful about it.
A platform team spends eight months building a new internal framework. It is a clear improvement over the legacy system in every measurable way: three times faster, better developer experience, half the operational overhead. They announce it at an all-hands. Eleven teams say they are excited. The platform team declares success and moves on.
Two years later, the new framework has twelve adopters. The old system still runs on thirty-one teams. Nobody is actively migrating anymore. The platform team has to maintain both. The expected benefits never materialized because you need near-full adoption for the network effects to kick in. The initiative is effectively dead, though nobody has said so officially.
This is the most common outcome. Not rejection. Gradual abandonment through inertia.
The difference between a cross-org initiative that succeeds and one that dies quietly is almost never the quality of the technology. It is the quality of the execution strategy for the human system. That is what this chapter is about.
Why Teams Don't Change (The Real Reasons)
Before you can move teams, you have to understand why they are not moving. The surface answer — "they don't have bandwidth" — is almost always true but almost never the real reason. Bandwidth is a symptom. Under it are four structural problems that show up in almost every cross-org initiative.
They have their own priorities, and yours is not on the list
Every team you want to influence has a roadmap. That roadmap was built by their team lead, shaped by their manager, and blessed by their VP. Your initiative is not on it. Even if the team agrees that your initiative is worthwhile, getting it onto their roadmap requires them to bump something else — something their manager is already expecting to get done. That is a real cost that falls entirely on them.
You need to make the business case not just to the engineers who are excited, but to the managers who own the roadmap. And you need to make it in terms they care about. "This will reduce our p99 latency" matters to an engineer. "This will reduce on-call escalations by 40% for your team" matters to a manager. They are not the same argument.
The switching cost is real and falls on them, not you
Migration is not free. It takes engineering time, testing, documentation updates, on-call runbook rewrites, and a period of elevated risk while the new system is running in production for the first time. All of that cost falls on the team doing the migrating. The benefit, often, flows to the organization — or to you, because your platform now has higher adoption numbers.
This is the asymmetry that kills adoption. You are asking people to do work, take on risk, and absorb a switching cost so that someone else can claim a win. The teams doing the migrating are not irrational when they deprioritize this work. They are responding to the actual incentive structure they are in.
If you want adoption, you need to either reduce the cost of switching dramatically (more on this in a moment), or make the benefit land directly on the team doing the switching, or both.
They don't trust the new thing yet
Teams that run production systems are, quite reasonably, conservative about what they run in production. They have been burned before. Something that looked great in a demo broke their service in a way they couldn't debug at 2am. They are not going to move their critical payment processing pipeline onto your shiny new framework until they have seen it run stably in production somewhere else for at least a few months.
This is not stubbornness. It is engineering judgment. You need to earn their trust by giving them proof, not by asking them to take it on faith.
Nobody is measuring the cost of staying on the old thing
The old system has hidden costs that nobody is tracking. The extra toil of maintaining it. The latency that nobody complains about because it has always been there. The classes of bugs it enables that the new system prevents. The fact that the old system will be three major versions behind its own dependencies in eighteen months.
These costs are real, but they are invisible because nobody is measuring them. And what isn't measured doesn't drive decisions. Part of your job as the initiative owner is to make the cost of inaction visible. Not in a manipulative way — genuinely visible, with real data.
Stop thinking about your initiative as "getting teams to adopt the new thing." Start thinking about it as "reducing the cost of moving, increasing the benefit of moving, and making the cost of staying visible." Those are three separate levers, and they are much more tractable than "convince people to change."
The Coalition Model: Don't Lead with a Mandate
The biggest mistake people make when starting a cross-org initiative is thinking about it as a rollout. They announce the new thing, set a deadline, and wait for teams to comply. This approach generates compliance theater — teams that say they are migrating, update a ticket, and then don't actually move until the deadline is a week away and someone is personally chasing them.
A better approach is to build a coalition first, announce second.
A coalition is a small group of teams that genuinely want to adopt your new thing. Not teams that were assigned to it. Not teams whose manager said yes in an email. Teams where the engineer who will do the actual migration thinks it is a good idea, has some time to do it, and is willing to give you honest feedback when things go wrong.
Before you announce your initiative to the organization, you want five or six of these teams. Not forty. Five or six.
Finding the true believers
The true believers are out there. They are the engineers who asked "when will this be ready?" when they saw your first demo. They are the teams who filed bugs on the old system last year. They are the people who wrote blog posts or internal documents arguing that the organization needs to move faster on this kind of change.
Find them. Go to them individually. Not with a proposal — with a question. "I'm building this new platform, and I'm looking for a team to be an early adopter and help me make it production-ready. I'll be on-call with you through the migration. I'll fix bugs same-day. I'll do whatever it takes to make your migration successful. Are you interested?"
You are offering something different from a standard adoption ask: a partnership. They get high-touch support, direct access to you, and the chance to shape the platform before it is set in stone. That is a genuinely good deal for the right team.
Engineering the first visible win
Your first coalition team's migration needs to go well. Not just "not catastrophically" — genuinely well. Their engineers should feel like the migration was easier than they expected. Their on-call load should visibly decrease (or their deploy time should visibly drop, or whatever the key benefit is). They should be willing to say publicly, in an internal forum or team meeting, that it went well.
This is not luck. You need to engineer this outcome. Be available. Fix problems immediately. Do some of the migration work yourself if needed. Write their runbooks for them. Make yourself so useful during their migration that they would recommend you to other teams. The first success story is worth more than any amount of internal marketing.
You have built a new service mesh that dramatically simplifies service-to-service authentication. Before the big announcement, you spend six weeks with two early-adopter teams. You sit with their engineers. You do pairing sessions. When they hit a bug at 11pm, you are the one who stays up to fix it. When they have a concern about how the new system handles certificate rotation, you add that feature before they need it.
After six weeks, both teams are fully migrated. Their lead engineers write internal posts about the experience. The posts say things like: "the migration took less than two weeks of actual work, the platform team was incredibly responsive, and we have already seen a 30% reduction in auth-related incidents." Those two posts do more for your initiative than any all-hands announcement you could give.
Make It Easy to Say Yes
The single highest-leverage thing you can do to accelerate adoption is reduce the cost of migrating. Not by asking teams to "be more flexible" or "just try it." By doing the actual engineering work to make migration easier.
Every step a team has to take to migrate is a potential point of friction where they give up or postpone. Map out exactly what those steps are. Then eliminate as many of them as you can.
This might mean:
- Writing migration scripts that do 80% of the mechanical work automatically. If the team has to manually update two hundred config files, most teams will not do it. If your script does it in five minutes and they just have to review a diff, most teams will.
- Building compatibility shims that let teams adopt incrementally rather than all-at-once. The team that has to migrate their entire system in one shot faces enormous risk. The team that can migrate one service at a time, validate it, and move on faces a much smaller risk at each step.
- Creating a "migration office hours" slot on your calendar every week. Teams know they can show up with whatever is blocking them and get a real answer in real time. This reduces the "I sent a question to the platform team and heard nothing for a week" problem that stops migrations cold.
- Writing the runbooks for them. Teams need runbooks to confidently operate the new thing. If they have to write the runbooks themselves from scratch, it is a significant time cost. If you provide solid starting templates that need only minor customization, that cost drops to an hour.
- Providing a "canary environment" where teams can try the migration in staging before they have to do it in production. Fear of the unknown is a huge driver of delay. Give teams a safe place to experiment.
The philosophy here is: your job is not to ask teams to do migration work. Your job is to do so much of the migration work for them that saying no becomes harder than saying yes.
Sit down and write out every single step a team needs to take to migrate. Include everything: reading documentation, attending a training session, updating code, updating configs, testing, getting change approvals, updating runbooks, updating monitoring dashboards. Then estimate the time each step takes.
This number — the total hours of work required to migrate — is your adoption cost. Every hour you reduce that number increases adoption. Every hour you add (with a new requirement, a new prerequisite, a new process step) decreases it. Treat this number as a key metric for your platform team.
The Inevitability Narrative
Human beings are deeply influenced by what other people are doing. When you are deciding whether to adopt something, one of the most powerful inputs is the answer to: "What are other teams like me doing?" If the answer is "nobody yet," you will wait. If the answer is "everybody is doing it, and those who haven't are starting to feel left behind," you will move.
This is not a manipulation trick. It is a real and useful signal. If many smart, experienced teams have already adopted something, that is evidence that the adoption cost is manageable and the system is stable. That is legitimately useful information for your decision.
Your job as the initiative owner is to make this information visible. Not to fake it — to surface the real momentum as it builds. This means:
- Publishing a migration dashboard that shows which teams have adopted, which are in progress, and what percentage of the organization is on the new system. Make this visible to everyone.
- Sending regular "adoption updates" that celebrate team migrations. Not in a patronizing way — genuinely acknowledging the work they did and the results they are seeing.
- Creating a public "hall of fame" of teams that migrated early and the specific wins they got from it.
- Letting your early adopters speak at internal tech talks. Peer-to-peer credibility is worth ten times as much as platform-team credibility.
The goal is that somewhere around 30-40% adoption, teams who have not yet migrated should feel a mild social pressure. Not a mandate. A sense that the organization has moved on and they are operating legacy infrastructure. That feeling is a powerful motivator.
You don't need to convince every team that the new thing is better. You need to convince enough teams that the transition is underway and the outcome is not in doubt. After that, most teams will move on their own timeline.
The Mandate / Earn Spectrum
Every cross-org initiative lives somewhere on a spectrum between "fully earned adoption" and "pure mandate." Neither extreme works well on its own.
| Approach | What It Gets You | What It Costs You |
|---|---|---|
| Pure Mandate | Fast motion. Teams start moving immediately when the deadline is real and executive backing is clear. | Surface compliance. Teams migrate technically but don't invest in really learning the system. Quality is low. Resentment is high. The platform team is blamed for every problem. |
| Fully Earned | Genuine commitment. Teams that adopt voluntarily invest in making it work. They give you good feedback. They become advocates. | Slow motion. Without any pressure, 20-30% of teams never move. The tail is very long. You end up maintaining two systems indefinitely. |
| Earned First, Mandate for the Tail | The best of both: genuine early adoption creates momentum and proof points, then a mandate closes out the stragglers before they become permanent. | Requires patience and discipline. You have to resist the temptation to mandate early when progress feels slow. |
The sequencing matters enormously. A mandate issued before you have proof points will fail. Teams will comply on paper and rot in practice. A mandate issued after 70% voluntary adoption, with clear success stories and a mature platform, is almost a non-event. Most teams are already moving. The mandate is just saying "yes, we actually mean it."
How to use executive support correctly
You almost certainly need executive support for a cross-org initiative to succeed. But how you use that support is crucial.
Used wrong: going to your VP and asking them to email all the team managers saying "everyone needs to migrate by Q3." This generates calendar events and status updates and very little actual migration.
Used right: asking your VP to remove a specific organizational blocker. "Three teams want to migrate but their Q3 roadmaps are already locked. Can you help them get this work into their roadmap without having to drop something they've already committed to?" That is a targeted ask that removes a real obstacle.
Executive support is most useful for unblocking things, not for driving things. The driving should come from the quality of your platform and the coalition you have built. The executive is the person you call when a team is genuinely stuck and needs organizational cover to prioritize this work.
Issuing a mandate before you have solved the adoption cost problem. If it takes three months of engineering work to migrate, a mandate doesn't help — it just means teams now have a deadline they are going to miss. The mandate creates urgency without creating capacity. What you get is stress, excuses, and half-migrations that leave the team running both systems simultaneously with none of the benefits.
Fix the adoption cost first. Then issue the mandate.
Running the Initiative at Scale
Once you have your coalition and you have proven the model works, you need to scale it. You cannot personally shepherd every team through every migration. You need systems and structures that do some of the work for you.
Communication that actually scales
One-on-ones are invaluable for the early coalition. They do not scale to forty teams. You need a communication strategy that keeps all teams informed, surfaced when teams are stuck, and celebrates progress — without requiring you to personally ping every team every week.
A set of things that work:
- A bi-weekly adoption newsletter. Two paragraphs. Teams that migrated this week. One concrete win from a team that is already on the new system. One known issue you are working on. A link to the migration guide. That is it. Two paragraphs, bi-weekly, builds more trust than a long quarterly update.
- An internal Slack channel for the initiative where teams can ask questions and see other teams' questions and answers. This creates a community of practice around the migration. Teams realize they are not alone in struggling with specific problems. Solutions propagate automatically.
- Weekly office hours. One hour per week. Any team can show up with any question. No agenda. No slides. Just real-time problem-solving. Teams that know they can get stuck questions answered in 48 hours or less migrate much faster than teams that feel like they are on their own.
- A dashboard that is always up to date. Teams should be able to check at any time how adoption is going. This makes the momentum visible and the laggards visible — to everyone, including the laggards themselves.
Building a champion network
You cannot be everywhere. But you can invest in a network of champions — engineers from early-adopter teams who are enthusiastic about the new system and are willing to help other teams.
Champions are not a formal role. They are the engineers who post "hey, we just finished our migration, happy to answer questions" in the Slack channel. They are the ones who volunteer to pair with another team for an afternoon. They are the people who are already doing the community-building work because they believe in it.
Your job is to identify them, recognize them publicly, give them early access to new features, and occasionally route questions their way when you are overloaded. They do not report to you. They are not on your team. But they become force multipliers for the initiative.
A champion network also solves a trust problem. When a skeptical team engineer asks "does this thing actually work in production?", you are not the right person to answer that question — you built it, so of course you think it works. But another engineer who runs it in their production system and can answer specific technical questions? That is credible in a way you are not.
Measuring adoption honestly
You need metrics, but be careful which ones you pick. The most common metric — "number of teams that have started the migration" — is almost useless. Starting is easy. Completing is hard. Maintaining it well after completion is even harder.
Better metrics:
- Fully migrated teams (defined precisely: old system fully turned off for that team, not just new system added alongside the old one)
- Time-to-migrate for the last three teams that completed. If this number is going down over time, you are successfully reducing adoption cost. If it is going up, you have a problem.
- Post-migration incident rate compared to the team's pre-migration incident rate. This is the outcome metric. If teams that migrate don't see improvements, you need to understand why.
- Champion-to-team ratio. How many teams have at least one engineer who considers themselves a champion? This predicts future migration velocity better than current adoption numbers do.
"Teams that have adopted the new system" is a vanity metric if it counts teams that technically use the new system but still primarily rely on the old one. Always define "adopted" as: old system fully turned off, team fully self-sufficient on the new system, no ongoing support from the platform team needed for normal operations. Anything less is not adoption — it is trial.
The Laggard Problem
In almost every cross-org initiative, there is a cluster of teams that refuse to move. Not because they are obstinate. Usually because they have a legitimate reason. And that reason has been simmering for months before you find out about it.
There are three categories of laggard, and they require completely different responses.
The genuinely stuck team. They want to migrate, they have tried, but there is a specific technical or organizational blocker they cannot get around. Maybe the new system doesn't support a feature they genuinely need. Maybe they have a dependency that isn't compatible yet. Maybe their team lead left and nobody picked up the migration work.
These teams need attention, not pressure. Go to them. Ask what is blocking them. Fix the blockers. The "genuine blocker" team is often the best source of information about gaps in your platform — they have found the edge cases that your early adopters never hit.
The waiting-for-someone-else team. They are waiting for their dependent team to migrate first. Or they are waiting for you to fix a known issue before they commit. Or they are waiting for a quiet period in their own roadmap.
These teams need a nudge and a clear path. Set a specific target date together. Offer to be more hands-on during their migration. Make the path concrete rather than abstract.
The ideological holdout. This team, or more commonly one very influential engineer on this team, has a principled objection to the migration. They think the new system is architecturally wrong. They think the migration is premature. They think the old way is actually better for their use case.
This is the hardest case. Pressure alone rarely works — it just drives the objection underground and creates a resentful team that runs the new system badly. You need to take the objection seriously. Schedule a real technical conversation. Understand the specific concern. If the concern is valid, address it in the platform. If the concern is not valid, walk through the reasoning together until you either change your mind or change theirs.
It is tempting, when one influential engineer is blocking a team's migration, to go around them — to their manager, or to someone more senior. Sometimes this is necessary. But it should be the last resort, not the first response, and you should be transparent about it. Going around someone without first genuinely engaging with their objection creates an enemy. You will encounter this person on the next initiative too. Handle the disagreement directly first.
Sunsetting the Old Way
This is where most cross-org initiatives quietly die. The new system has high adoption. The old system still runs. The platform team is now maintaining both. The org has the costs of two systems without getting the full benefits of either. Six months later, people start to wonder if the new system was worth it. The answer should be yes, but it doesn't feel that way because the old system is still there, still consuming resources, still the mental model people reach for under pressure.
Sunsetting the old system is not a technical problem. It is a political and organizational problem. And it needs to be planned from the very beginning of the initiative, not added as an afterthought once adoption is high.
The sunset plan needs to be part of the original proposal
When you are pitching the cross-org initiative, include the sunset. "We will migrate all teams to the new system by Q3. The old system will be shut down by Q4." This does several things. It signals to teams that this is a real commitment, not an optional platform. It creates a forcing function for the tail-end laggards. And it prevents the "let's keep both forever for safety" compromise that slowly bleeds the organization dry.
Getting agreement on the sunset upfront is hard. Executives are risk-averse. Teams that haven't migrated yet will push back. You will hear "can't we keep the old system running just in case?" The answer is: you can, but if you do, you have not finished the initiative. You have just added a second system. Half of the value disappears.
How to actually shut it down
The physical act of turning off the old system needs to be as careful as launching a new one. There are usually hidden dependencies you did not know about. There is tooling built on top of the old system that nobody documented. There are scripts in engineers' home directories that pipe into the old API. There are monitoring dashboards that pull from the old system's metrics endpoint.
Announce the sunset date six months early
This gives teams real time to plan. It also surfaces the hidden dependencies — teams will reach out to ask "will X still work after the shutdown?" and you will learn about integrations you didn't know existed. Better to find them now than on shutdown day.
Put a visible deprecation banner in the old system's UI and APIs
Every engineer who touches the old system should see, on every interaction, that it is going away and when. Not a pop-up they can dismiss once. A persistent notice. This creates urgency at the engineering level, not just the management level.
Start throttling the old system three months before shutdown
Add a rate limit on the old API. Make the old system slightly less reliable — longer response times, occasional errors that don't break anything but do require handling. This creates real urgency without creating a crisis. Teams that were "planning to migrate soon" will suddenly find the time.
Do a dark period before final shutdown
One week before shutdown, take the old system down for a four-hour window during low-traffic hours. Observe what breaks. Fix the things that weren't supposed to break. This is your production fire drill. It is much better to find hidden dependencies during a planned dark period than during the actual shutdown.
Shut down completely, then archive, then delete
Shutdown and deletion are not the same step. Shut the system down, leave it shut down for sixty days while observing for any issues, then delete the infrastructure. Keep the code in an archive branch forever — someone will need to look at it eventually for historical reasons. But the running system needs to die completely for the initiative to be truly done.
What Success Actually Looks Like
A cross-org initiative is truly successful when three things are true simultaneously, and this is rarer than it sounds:
The new system is running in production everywhere it needs to be. Not "mostly." Not "except for a few teams." Everywhere. The definition of "everywhere" should be negotiated upfront and written down. But whatever it is, it needs to be met completely.
The old system is fully shut down. No dark corners. No "we kept one service on it just in case." No shadow usage through an undocumented API. The old system is gone. The infrastructure is decommissioned. The on-call rotation for it has been dissolved.
The organization does not need the initiative team anymore to operate the new system. This is the hardest part. For the first six months after migration, teams lean heavily on the platform team for operational questions. That is fine. But if a year after migration, teams are still depending on the platform team to help them handle production incidents with the new system, the initiative has not truly succeeded — you have just moved the dependency from the old system to the platform team.
True success means the new system is just part of how the organization works. Teams operate it independently. New engineers onboard to it without knowing there was ever an old system. The initiative team has moved on to the next problem. That is the outcome you are working toward from day one.
The Cross-Org Initiative Checklist — Before You Start
Have you diagnosed why teams haven't already moved?
Not the surface reason. The structural reason. Is it priority? Cost? Trust? Incentives? Your strategy depends on which one it is.
Do you have your first five coalition partners identified?
Not agreed. Identified. You know who the true believers are. You know which of them have time and can serve as early adopters.
Have you measured and actively reduced the adoption cost?
Have you mapped every step of the migration? Have you automated as many steps as possible? Can you state the total engineering hours required?
Is the sunset plan included in your proposal?
Not as a vague future intention. As a concrete date, with explicit agreement from the stakeholders who need to sign off on decommissioning the old system.
Do you have an executive sponsor who understands what you will need from them?
Not just a name. A person who has explicitly agreed to help unblock roadmap prioritization issues and attend a brief check-in with you monthly.
Have you defined "done" in writing?
Exactly what does 100% migration mean? Which teams are in scope? Which are out of scope? What percentage of traffic through the new system counts as "migrated"? This needs to be unambiguous before you start.