There are lots of different ways to organize people into teams. At Security Compass we would group people up into small cross-functional scrum teams, focused on a particular area of the product. They would build up knowledge and context about how those features work and what their code base looked like over time. They could work more-or-less autonomously. As an organization grows this is important.
People may want to change their teams when they feel like they are stagnating or stuck. Often my first instinct was to try and delay a move for as long as possible. It’s disruptive to move someone from one team to another. It takes time for teams to gel. It takes time to rebuild that lost knowledge and context. Doing nothing was easier than doing something, so this became an easy problem to punt.
But people leaving your organization will usually be far more disruptive, and that is how this story ends. All your worries come to pass anyway, and you’ve lost a good developer in the process. You’d likely have been better off eating the costs of a move. Nevermind it’s not all a net-negative: knowledge flows between teams; new relationships are formed; bonds between teams grow. As time passed we tried to build the migration of people between teams into our process, usually moving people between our bigger releases. We weren’t constantly shaking up teams—as noted that’s disruptive—but we weren’t putting things off indefinitely.
Of course moving someone isn’t a panacea for stagnation. You might realize that a person’s needs won’t be met simply by changing their team or role, that their next move should be elsewhere. Moving someone only to watch them quit weeks or months later is foolish. You should always be ready to support someone from your team moving on from your organization. I’ve also made the mistake of trying to keep people longer than I should have. You can do better.