It’s not uncommon for a successful software project to last many years. After all, successful software is never complete. There’s always a new feature to add or an existing component to freshen up.
But should the original team last just as long?
With longterm projects, it’s common to keep the same engineering team assigned to the project for its entire lifecycle. This happens for two main reasons:
- Keeping a single team in place is the simplest thing to do from a project managerial standpoint. No planning or creative thinking needs to be conducted around effectively swapping a team member.
- It feels like the safest choice for the stakeholders. After all, why rock the boat? We like the current team, and we’ve developed a winning product.
However, in my experience, successful, happy, and innovative teams find opportunities for team rotations.
Benefits of Team Rotations
There are lots of reasons to change up your team:
- New ideas: New team members bring a beginner’s mindset to the problem space and commonly inject positive new ideas and observations.
- Knowledge sharing: Assuming the person rotating off the project isn’t leaving your organization, rotating team members can help you extend the knowledge base of people who can effectively work on this successful product.
- Individual energy and team morale: Variety is the spice of life. The existing feature challenges of the product are exciting and fresh for the new developer. This energy is contagious, and it can provide a boost to the entire team. More on this important point below.
Drawbacks of Team Rotation
Admittedly, there are some valid concerns about rotating teams:
- Requires planning: Pulling off the swap successfully requires a logistical effort.
- Ramp-in cost: When you bring a new developer into the team, it takes time for that developer to become acclimated with the architecture, code structure, and domain.
- Loss of knowledge: When you pull someone with experience away from the team, you can also lose valuable history about the reasons behind certain development choices.
- Disruption of a jelled team: Rotating members can offset the team’s rhythm.
These cons may feel daunting, but if rotations are well planned, the reality of the swap isn’t that painful.
Best Practices for Team Rotations
In my experience, there are a few steps you can follow to help rotations go more smoothly.
- Target people who have been on the project for about 9-18 months. This is long enough for them to gain expertise, provide a ton of value, and eventually get bored and be ready to move on.
- Avoid wholesale team rotations.
- Look for opportunities to overlap the new developer with the old developer (e.g. maintain a little bigger team for a couple of weeks).
- Avoid rotating right before a major deadline.
- Be extremely thoughtful about rotating your lead developer.
- Encourage the team to stay connected with members who have previously rotated out.
- Educate your team to expect rotations. This tends to create positive side effects like better documentation, enhanced peer pressure to produce highly readable code, and less sense of being stuck. After all, we all like a little change every once in awhile.
- Look for opportunities to rotate an old teammate back into the project in the future.
There are many good reasons to rotate team members, but the most important is individual energy. Top developers like new challenges, and they don’t want to feel trapped on the same project forever. That doesn’t mean that they don’t like the product, the technology, or the client–it simply means that they need something new to learn.
When you facilitate a swap, you do lose a little product experience, but you replace it with something that’s more valuable to the product in the long-run–new energy and excitement. What benefits have you seen from rotating your team?