There’s a persistent belief in engineering organisations that moving people between teams is healthy, it spreads knowledge, prevents silos, and keeps things fresh. I understand the appeal. I’ve also watched it destroy team effectiveness more times than I can count.

The research is clear, and my experience confirms it: stable teams outperform shuffled ones. Not by a little, by a lot. And the reasons are rooted in how humans actually build trust and develop working relationships, not in how org charts look on a slide.

What the Research Shows

Bill Horvath, writing in 97 Things Every Engineering Manager Should Know, summarises the evidence directly: all else being equal, a team with stable membership will perform better over time. Studies show team stability leads to high performance, predictable velocity, and outcome quality.

The mechanism isn’t mysterious. Tuckman’s model of team development, forming, storming, norming, performing, describes a real process that every team goes through. When a team is first assembled, members are feeling each other out (forming). Then they start to clash as they establish working patterns (storming). Eventually they find their groove (norming) and start producing their best work (performing).

Every time you change the team’s membership, you reset this cycle. A new person joins and the team drops back to forming, or at least to storming. The trust that was built has to be rebuilt. The working patterns that were established have to be renegotiated. The implicit knowledge about how each person works, what they’re good at, and how to communicate with them has to be relearned.

This isn’t a one-time cost. It compounds. Horvath cites research showing a strong negative correlation between team tenure diversity, variability in how long members have been on the team, and psychological safety. The more a team changes, the less likely its members are to trust one another.

The Metrics Problem

Here’s something that doesn’t get discussed enough: team performance data only has meaning when team membership doesn’t change. If you’re measuring velocity, cycle time, or defect rates, those metrics are only useful for comparison if the team is the same team. Shuffle people around and your historical data becomes meaningless, you’re comparing different teams that happen to share a name.

This creates a vicious cycle. Organisations that shuffle teams can’t build meaningful performance baselines, so they can’t identify trends, so they can’t make data-driven improvements, so they shuffle teams again hoping the new configuration will be better. It’s organisational thrashing.

Stable teams, by contrast, develop predictable performance patterns. You can forecast delivery with reasonable confidence. You can identify when something’s going wrong because you have a baseline to compare against. Product owners can plan more effectively because they know what the team can deliver.

The Knowledge Argument

The most common justification for shuffling is knowledge sharing, “we need to spread expertise so we don’t have single points of failure.” It’s a legitimate concern, but team shuffling is the worst possible solution.

Better alternatives exist. Pair programming, code reviews across teams, internal tech talks, documentation, and rotation programmes where engineers spend a few weeks embedded with another team before returning to their own, all of these spread knowledge without destroying team stability.

The firefighter team model is another approach I’ve seen work well. Instead of moving people permanently, you create a small, flexible team that can be deployed to help other teams with specific problems. They bring expertise in, help solve the problem, and leave, without disrupting the host team’s long-term composition.

What I’ve Observed

The best-performing teams I’ve led were the ones that stayed together the longest. They developed a shorthand that made communication effortless. They knew each other’s strengths and weaknesses and compensated naturally. They could estimate work accurately because they understood their own capacity. They held each other accountable because they’d built the trust required to have honest conversations.

The worst-performing teams were the ones that were constantly being reorganised. Every quarter brought a new structure, new team members, new priorities. People never got past the storming phase. They never built the deep trust that enables real collaboration. They were always starting over.

I watched one team go through three reorganisations in eighteen months. Each time, management expected the new structure to solve the problems of the old one. Each time, the disruption made things worse. The engineers who could leave, did. The ones who stayed became disengaged. By the end, the team was performing worse than any of its predecessors, not because the people were worse but because they’d never been given the stability to become a team.

When Change Is Necessary

I’m not arguing that teams should never change. People leave, people get promoted, projects end, and organisational needs evolve. Sometimes a team genuinely needs new skills or perspectives. And sometimes a team is dysfunctional in ways that can only be fixed by changing its composition.

The point is that change should be deliberate and infrequent, not routine. When you do change a team, acknowledge the cost. Give the team time to reform. Don’t expect the same performance from a reconstituted team that you got from the stable one. And don’t change teams just because it looks good on a reorganisation slide.

Stability isn’t glamorous. It doesn’t generate exciting announcements or impressive org charts. But it’s the foundation on which effective teams are built, and treating it as expendable is one of the most expensive mistakes an engineering organisation can make.