Most cross-org initiatives die because the author writes a design doc, files tickets in other teams' backlogs, and complains to leadership when nobody prioritizes them.
If you have ever worked in a large engineering organization, you have seen this happen before: someone spots a real, systemic problem. They spend months writing a sound proposal for a solution, get sign-off from a few senior engineers, and open tracking tickets in every team's queue with a two-month deadline.
Three months later, 4 teams have closed the ticket, 6 have acknowledged they will work on it "someday," 57 have ignored it completely, and the author is in a director's office asking for "air cover" to force teams to do the work.
This is ticket-driven leadership, and it fails miserably because it ignores basic organizational economics. Filing a ticket in another team's backlog is an unfunded tax on their roadmap. That team already has its own priorities, deliverables, and fires. When you ask them to spend 3 days on your migration guide, you are asking them to delay their goals to achieve yours.
Even if you convince a VP to mandate the work, you are spending your precious political capital just to get malicious compliance in return: teams do the bare minimum to close the ticket, resent you, and stop caring as soon as leadership looks away.
For large-scale changes to succeed, you have to flip the economics of adoption. In this post, I'll share some lessons I learned over the years, and two rules I adopt to successfully onboard 60+ teams voluntarily onto new initiatives: absorbing the activation energy myself, and focusing on the output instead of the internal workflows of the teams.
Rule #1: Absorb the activation energy yourself
In chemistry, activation energy is the minimum energy required to start a reaction. Even if a reaction is favorable and releases energy once it gets going, nothing happens until you cross that initial barrier.
This is the same for organizational change: the change could be a net win for everyone, saving money or working time, but teams won't adopt it if the upfront cost to migrate is on them.
So, how do you avoid that?
Instead of filing a ticket asking a team to adopt your way, do the initial onboarding or the code patch yourself. Instead of giving homework (which will always result in an answer along the lines of "Thanks so much, let me put this at the end of the backlog"), you bring a solution where their only cost is a code review. You change the conversation from "Can you prioritize this, pretty please?" to "You just need to click LGTM and you will reap the fruits."
When I suggest this, the usual pushback I get is:
"I am a senior engineer, not a code monkey for other teams. Doing their onboarding doesn't scale."
It is a fair observation, but it misses two crucial points.
First, you do not need to write patches for all the teams—you only need to manually onboard the first 10 to 15. You find the ones suffering the most from the problem you are solving, do the legwork for them, and let them feel the difference. Once enough teams have seen the results of your good work, social pressure takes over. In a recent rollout I did, after onboarding about 20 teams, the remaining 65+ teams started onboarding themselves without me even reaching out. Nobody wants to be the last team being paged in the middle of the night for a problem that has already been solved.
Second, we accept the cost of onboarding the first 15 teams ourselves because the alternative is spending the next 6 months arguing in status meetings with zero adoption. Plus, I am a big fan of dogfooding: getting your hands dirty across a dozen messy codebases is the fastest way to check if your solution is actually sound. If you, the author of the solution, find it painful to migrate one of these teams, imagine how painful it would have been for them (and how quickly they would have abandoned the initiative!). Smoothing the experience ourselves on the first teams is what makes it possible for all the other teams to self-serve later.
Rule #2: Standardize the output, never the internal workflow
Rule #1 works extremely well when we are talking about code, adopting a library, or eliminating a bad pattern. But what if you want to drive operational changes?
Let's say you get the mandate to standardize how teams handle incoming escalations, bugs, and feature requests, and how they communicate back with leadership and stakeholders. You can't just send teams a pull request to fix how they run their standup.
So, what do you do?
The first step is always learning why something failed if it was tried before (and unless you work on the absolute frontier, it has been tried before).
A year before I took on this problem, a top-down effort was put in place to standardize "how we work." It failed miserably. Why? Because it tried to dictate how teams should work inside their own turf: how to structure their backlog, how to run sprints, and even which colors to use for labels in the bug tracker.
That never works. Teams fight standards (rightly so) when you try to dictate their internal habits. If a team is already delivering high-quality work, they will completely reject an arbitrary change to their daily routine just to fit a template. Meanwhile, a team with structural delivery issues will blindly implement your process rules without fixing their underlying problems.
Instead of acting like the process police, we should only standardize the outputs. The what is what brings business value, not the how (up to a certain point, clearly: you shouldn't set piles of cash on fire just to stay warm).
When I was tasked with restarting this initiative and bringing it to completion, I focused purely on the external boundaries of the team instead of writing playbooks on how they should work internally. Each team kept 100% autonomy over how they operated, as long as they provided five exact outputs to the rest of the organization:
Who: Clear ownership mapping. Who owns what, who the leads are, and who gets paged when things break.
What: An explicit service catalog defining what the team supports, and what they don't support.
Intake: A single, structured entry point for requests and escalations, killing the habit of routing work through random Slack DMs.
Visibility: A publicly queryable queue state, so anyone filing a request can see whether their issue is triaged, blocked, or actively being worked on.
Metrics: Standard response and resolution SLOs measured across the team boundary.
The combination of Rule #1 and Rule #2 made adoption effortless. I didn't ask teams to reorganize their backlogs or rewrite their team charters. For the first dozen teams, I drafted their initial service catalog and configured their intake routing based on their past escalations, handed them the link, and asked: "Does this accurately describe what you own?". Seeing these teams having a clear way to interact with the rest of the organization, the rest of the teams just adopted the same standards, because they brought order and less escalations.
Once a team exposes these contracts, how they work internally is entirely their business.
Give teams autonomy inside their walls, make the right path the path of least resistance, and you will never need to beg a VP for a mandate again.
Comments