6 reasons you should NOT rotate developers onto new projects frequently

I believe that there are a lot of good reasons to rotate the developers at your company onto other projects more frequently than you already are. What I mean by “rotate” is that a team member is effectively moved from one project to another. This is usually in the form of a trade. A developer from one project switches places with the developer of another project. They’re still around to help anyone working on the old project, but it is no longer their primary roll.

Just how frequently am I suggesting that developers should rotate onto new projects? In my opinion, a developer should be on a new project every 6 to 12 months. But this is something your company should experiment with to find an ideal length of time.

I wrote about the benefits in my previous article. I don’t want to act like this is all advantages so in this article I’ll be pointing out the downsides:

Developers may not see the ramifications of their choices

I’ve worked with people who I would say rotate onto new projects too frequently. As a result, they never were able to see the ramifications of their choices. They may have pushed hard for a new pattern of testing that did not work out well in the end. If they stayed on the project the whole time, they would feel the pain of choices and learn from their mistakes. If rotated too frequently, they may never see the problems that were caused.

This is why I suggest a rotation time that is long enough for people to see the ramifications of their choices but short enough so that developers can learn new things and share context before it’s too late.

Frequent rotation can make people stop caring

Even if developers are rotating from team to team, that developer should feel a sense of ownership of the project while they’re working on it (even better, the whole team should feel ownership). If you rotate developers too frequently, they may not feel responsible for the project they’re working on. They may feel like guests in the code base instead of owners.

This problem can be exacerbated if a deadline is given and the developer knows they are rolling off long before that deadline.

I would say this is a good reason to plan a rotating schedule around events instead of instituting a schedule around time.

The rotation may come at a bad time

There’s rarely a perfect time to rotate developers on and off a project. It may be disruptive to the team or the individual. This is why it’s important to share context properly before anyone is rotated on or off a project. Without this upfront effort, the rotation is going to cost a lot more than it needs to.

It takes time to share context

When a developer moves to a new project they now have to become familiar with the code base. This costs time and therefore money. The rest of the team also has to slow down to communicate concepts to the new developer that they are already familiar with. I’ve written about ways to reduce this cost, but it can’t be eliminated.

This is another reason you should avoid rotating too frequently. But, there is a time where the cost of sharing context is worth the risk of a small bus factor number.

Developers may like “owning” a project

A lot of developers consider their project their baby and don’t like the idea of anyone but themselves working on it. When one is in this state of mind, they are not going to appreciate being rotated off their project. Therefore, rotating onto new projects regularly will demoralize these developers.

Rotating onto a low quality project is not fun

If nobody rotated to different projects, each project could stay as its own island of quality. Some would be high quality and some would be low. But if you were working on a high quality project and you rotate onto a low quality project, this can feel like a downgrade. Of course, others may see it as an opportunity to improve the quality of a new code base, but most developers don’t consider that to be a pleasurable experience.

If the rest of the team has a low bar for quality, it can feel like one against all if the new developer tries to improve the code base and nobody else sees a problem with it.

The best way I’ve seen to deal with this problem takes a few steps. First, you must identify a project as low quality and another project as high quality. Then, half of the low quality team should be rotated with high quality developers. This way, it’s not a one against all situation anymore but there should be enough people left on the low quality project to share context. I suggest this because it is really difficult for one person to turn the tide against a whole team.


Although I feel like most companies should rotate their developers onto new teams every 6-12 months, I do acknowledge that this comes at a cost. With these tips, you can avoid the pitfalls of rotating too frequently, at the wrong time, and rotating between projects of different quality.

Join the email list for bonus content.

Leave a Reply

Your email address will not be published. Required fields are marked *