June 6, 2026 · 7 min
The Reintegration Trap
Patrick McClory
You build the thing in isolation because the main org can't support the velocity you need. It works. Everyone celebrates. Then you bring it back in and the thing that made it work gets absorbed and neutralized by the very environment it was supposed to change.
The Reintegration Trap
The experiment worked.
That’s usually how the story starts when organizations tell it. We stood up a separate team, gave them autonomy, let them move fast, and they proved it was possible. High velocity. Modern tooling. Real delivery cadence. The kind of engineering culture that attracts good people and keeps them.
Then they brought it back in.
This is the reintegration trap. You build the thing in isolation because the main organization can’t support the velocity you need. The isolation is what makes it work: the freedom from the interfaces that slow everything down, the autonomy to make decisions without running them through six committees, the culture that formed because the team was small and focused and didn’t have to defend every choice.
It works. Everyone celebrates. Leadership decides to mainstream it. And the thing that made it work gets absorbed and neutralized by the very environment it was supposed to change.
The Financial Services Version
A financial services organization I worked with did everything right up to the last step.
They needed to rebuild a business unit’s technology capabilities to compete. They understood, correctly, that trying to do this inside the existing org would fail. Too many interfaces. Too much politics. Too many stakeholders with competing interests and the authority to slow things down. So they did something harder and braver: they built it out as a pseudo-startup, off-campus, in offices with less polish and more character. Renegade vibes,. The team that went there knew they were doing something different.
They built the capabilities the business needed. They proved it worked. They earned every lesson the hard way: about velocity, about platform discipline, about what it takes to build and operate software at the speed the business required.
Then they took it back to the corporate offices.
And it died on the vine.
Not completely. The organization capitalized on about 10% of the hard-earned lessons. Some things changed. Some practices got adopted. From a certain perspective it had value. But from the perspective of everyone who had lived through the off-campus work, it was a disaster. They could see exactly which 10% got kept and which 90% got lost. They knew it wasn’t the most important 10%. It was the most comfortable 10%, the pieces that didn’t require anyone else to change, the lessons that could be absorbed without disrupting the interfaces that were already there.
The capability the business needed to be competitive was in the 90%.
Why Reintegration Fails
The reintegration trap isn’t a failure of ambition or execution. It’s a structural problem that most organizations don’t see coming because they’re focused on the wrong thing.
The thing they built off-campus worked because of its context, not despite it. The autonomy was a feature. The separation from the main org’s interfaces, the approval processes, the architecture reviews, the stakeholders who needed to be consulted before anything changed, was what allowed the velocity. The renegade culture wasn’t incidental. It was the mechanism.
When you bring the team back in, you remove the context and keep the team. But the team’s capability was partly a function of that context. A high-velocity team inside a low-velocity organization doesn’t stay high-velocity for long. They hit the interfaces. The interfaces don’t change for them. They slow down. The engineers who have options look at the slowdown and make a decision.
The other teams don’t make this easier. The organizations that run these experiments often create resentment alongside innovation. The adjacent teams that watched the off-campus group “get to do the cool stuff” weren’t wrong to notice the difference in conditions. When reintegration happens and the returning team starts advocating for the practices they developed, they’re often heard as “we’re better than you” rather than “here’s what we learned.” The interfaces they’re asking to change belong to people who were never given the same opportunity.
So the returning team fights battles on two fronts: against the organizational inertia that slows everything down, and against the resentment of teams who feel like the experiment implied they were the problem. Neither front is easy. Most teams lose at least one of them.
What Gets Kept and What Gets Lost
The 10% that survives reintegration is almost never the most important 10%. It’s the most comfortable 10%.
Comfortable lessons are the ones that don’t require anyone outside the team to change. A new deployment pipeline. A code review process. A testing standard. These are things the team can adopt internally without needing other people to change how they interface with them.
The uncomfortable lessons are the ones that require the organization to change. Decision-making speed. Approval processes. The number of stakeholders who have to sign off before something ships. The architecture review process that adds six weeks to every significant change. The infrastructure team that’s a shared service and operates on a ticket queue with a two-week SLA.
Those are the things that made the off-campus experiment work differently. Those are also the things the organization has the least appetite to change, because changing them requires people who weren’t part of the experiment to give something up.
The result is an organization that adopted the visible artifacts of the high-velocity approach while leaving the structural conditions that made it possible intact. The team has better tooling. The delivery process is still slow. The engineers who built the tooling know the difference.
The Moment the Best Engineers Decide
There’s a specific moment when the best engineers on a reintegrating team make their decision.
It’s not when the reintegration is announced. It’s not even when the first interface friction appears. It’s the moment when they realize the organization is going to absorb the comfortable lessons and stop there, when they can see clearly that the 90% they care about is not going to change, and that the energy required to keep fighting for it exceeds what they’re willing to spend.
Some of them leave immediately. Some of them stay longer, trying to move things from the inside, getting incrementally more frustrated. A few of them find a way to build something real within the constraints and decide that’s enough.
The ones who leave aren’t wrong. They did something hard, proved it worked, and watched it get diluted by an organization that wanted the results without the change required to produce them. That’s a reasonable thing to be done with.
The organizational cost isn’t just the turnover. It’s the knowledge that leaves with them. The 90% that didn’t make it back into the organization is now walking out the door in the heads of the people who built it.
What Good Reintegration Looks Like
The organizations that navigate this successfully treat reintegration as a change management problem, not a team relocation problem.
The question isn’t “how do we move the team back in.” It’s “what has to change in the main organization before this team can operate inside it at anything approaching their off-campus velocity.” That’s a different question and it leads to different planning.
It usually means doing the organizational work before the reintegration, not after. Identifying the specific interfaces that will create friction. Having explicit conversations with the teams that control those interfaces about what needs to change and why. Building the conditions for the reintegration to succeed rather than dropping the high-velocity team into an unchanged environment and hoping culture is contagious.
It also means being honest about what can’t change fast enough. Some organizations aren’t ready for full reintegration. The right answer in those cases might be a slower transition, or a more limited reintegration, or making explicit that some capabilities will remain semi-separate because the main org can’t yet support what they need to operate.
That conversation is harder than announcing a successful reintegration. It’s the one that has a chance of keeping the 90%.
The Lesson That Keeps Not Getting Learned
The financial services story I described isn’t unusual. It plays out regularly in organizations that have the ambition to run the experiment but not the appetite to follow through on what the experiment reveals.
The experiment reveals that the main organization’s interfaces are the bottleneck. The response to that revelation is usually to absorb the experiment’s outputs and leave the interfaces intact. Which means the next team that needs to move fast will also need to be run as an off-campus experiment, because nothing changed about the conditions that required the experiment in the first place.
The organizations that actually learn from this are the ones that treat the experiment as a diagnostic. What did the off-campus conditions make possible that the main org can’t? Those are the things that need to change. Not as a favor to the high-velocity team but because they’re the things standing between the organization and the capability it needs to be competitive.
The renegade team off campus wasn’t the solution. It was the proof that the solution is possible. The solution is the main organization building the conditions that make the velocity sustainable.
That’s the work most organizations stop short of. That’s where the best engineers go when they leave.