Regular Team Rotation
On large software projects, communication is key. There are so many ways we can try to facilitate regular communication between engineering teams, but I believe one of the best is regular rotation of engineers between the teams. Working on a new team fosters knowledge sharing, shared ownership and responsibility, better technical decisions, and builds communication and technical skills for each of the engineers.
I define knowledge sharing between software teams as understanding what other teams do: their goals, process, products, and code. Understanding each of these things enables effective communication and planning on your own team. When someone new is rotated onto the team, they have the opportunity to see these processes first-hand, perform them, and improve them with an outside perspective. Performing something yourself is a great way to actually understand it. When that new person rotates off the team, their understanding will also become out of date, but now that can be resolved with a conversation with someone now on that team. Now they know who to talk to, and their shared base of understanding enables them to have that conversation more effectively than starting from scratch.
A shared base of understanding also contributes to shared ownership and responsibility for the entire project. When things go wrong, we don’t always get the opportunity to learn what went wrong, how it was resolved, and how to prevent it in the future. Missing these leave us with a lack of confidence in our ability to troubleshoot and resolve future issues, and result in a culture of avoiding issues that we don’t understand. This culture spreads very quickly. Regular rotation between teams provides a lot more opportunity to observe these issues and learn from them. It builds a network of people to talk to, and that shared base of understanding that you can use to figure out an issue even without immediately recognizing it.
Regular rotation between teams builds a network of people to talk to organically. Knowing who to talk to about a given topic is invaluable, but difficult to build from scratch. We have the opportunity to find this network every day that we work closely with several people. Increasing that number by rotating between teams helps that network grow so you can be more confident in finding the answer to your problem. Working with new people regularly helps you learn to communicate with different people who have difference communication styles. Likewise, working with new codebases helps you learn different patterns and how to fit your own style into a new team.
These are all the reasons I think regular team rotation is very important. It’s difficult to implement for several reasons, like reluctance from individuals, aligning individuals with managers, and balancing staffing needs with department goals. So I don’t like making hard rules about rotation, but instead keeping it as a goal and metric to be tracked and discussed with each individual and team regularly.
I’ve tried hard to keep pair programming out of this discussion so far, but bear with me now. I truly believe team rotation is essential to a healthy team, while pair programming is a little more optional. But pairing will multiply these results and make them much more visible and permanent. Pairing often involves rotation within a team that achieves these same results, so rotation between teams is a natural extension.