Stable teams

The tech industry has a bizarre addiction to reorganizations. A new CTO comes in? Reorganize. Product not shipping fast enough? Reorganize. Leadership read a new management book? You guessed it — reorganize.

What I've learned about team stability

I spent fifteen years watching high-performing teams get dismantled in the name of "fresh perspectives" or "breaking down silos." I've never once seen it work out well in the short term. Not. Even. Once.

Last year, I advised a mid-sized tech company that had reorganized engineering teams three times (!) in eighteen months. When I arrived, their engineers could barely remember who they reported to, let alone build cohesive products. Their DORA metrics were abysmal — lead time for changes exceeded 30 days, and their deployment frequency had slowed to a crawl.

Remember:

Engineers weren't invested in outcomes because they knew another reshuffle was just months away.

Why stable teams outperform the chaos monkeys

1. Domain knowledge compounds, not resets

When team members stay on a product long enough, they accumulate invaluable institutional knowledge. They understand the codebase's dark corners, learn from past mistakes, and develop an intuition about what solutions will work. Every time you shuffle people, you're throwing that compounding knowledge away.

You can document all you want, but there's no replacement for the engineer who says, "We tried that approach in 2021. Here's exactly why it failed." You can't onboard that kind of historical memory.

2. Trust takes time, not workshops

I'm amazed how many companies will pay thousands for team-building retreats but won't give teams the one thing they actually need: time together. Trust develops when people work through challenges, learn each other's strengths and weaknesses, and develop communication shortcuts.

A team that's been together for 18 months communicates in a shorthand that no amount of documentation or process can replace. They know when Bob says, *"I'm concerned,"*he actually means "This is going to explode in production." They understand Emma needs to think through problems alone before discussing them in group settings. Learning all this takes time.

You can learn more about this in Team Topologies, but the fundamental truth is that humans need time to build trust, and trust is the foundation of high performance.

3. Cognitive load drops, velocity rises

The cost of context switching isn't just about an individual engineer moving between projects. It's exponentially worse when entire teams are constantly getting up to speed on new domains, codebases, and teammates.

High cognitive load kills productivity. When engineers spend mental energy figuring out how a system works or how to collaborate with new team members, they have less bandwidth for solving actual problems. Stable teams become more efficient over time as cognitive load decreases.

4. Accountability sticks when people can't hide

I've seen this pattern repeatedly: Teams get reshuffled, deadlines are missed, and nobody is held accountable because "the teams changed." It's the corporate equivalent of passing the hot potato.

In stable teams, there's nowhere to hide. If something doesn't get delivered, the team owns it. If technical debt accumulates, they're the ones who will feel the pain. This creates natural incentives for quality and thoughtful decision-making.