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 don’t want to act like rotating developers is all advantages. But I shall discuss the disadvantages in a future article. Here’s why you should rotate your developers onto different projects:

Rotating developers helps them understand the big picture

Lets go extreme and imagine that one of your developers worked on every single project at your company. They would be intimately aware of how all the pieces fit together. They’d understand why a request to another team is reasonable or unreasonable given their constraints. They would have insight into the best place a feature to be implemented and be able to break down high level requirements into low level stories that are distributed to the rest of the teams. And, the chances that all the pieces would fit together in the end would be improved.

Consider that not all projects are user facing. Some projects are merely APIs for other projects. The people stuck on these API projects have a difficult time seeing how the features they are writing are providing value to the end users. Rotating these developers onto user facing projects will give them empathy for the customers and help them make decisions on their behalf. This decision making advantage will carry oven even if they are rotated back onto an API project. If a developer from a user facing project rotates onto an API project, they can bring a lot insight to the rest of the team for the same reason.

Rotating helps with a shared context

There’s a company maturity level required to even be able to rotate a developer from one project to another. Unless there’s a good support structure (documentation, onboarding, pair programming, etc.), a rotation will not go well. This support structure requires a way to share context. Without this – worst case scenario – it will be as if both developers quit. This would occur if you only had one person teams and after rotation, the two people never communicated with each other. Without being able to share context about where they left off, the ramp up time for being effective on their new projects will be astronomical.

The reality is that any developer is free to quit any time they want. So avoiding rotation does not avoid this concern, it just stops you from dealing with it until it’s too late. Better to deal with this risk head on today than at the worst possible moment tomorrow.

Rotating increases collaboration

With a large enough company it can become possible for projects to depend on each other with limited collaboration. This is a problem and here are a few symptoms of it:

1. Work that is frequently blocked waiting for other teams
2. Components that don’t fit together (e.g., an API nobody uses)
3. Features that nobody uses

Frequent rotation will help alleviate these problems. It will also give developers direct contacts with people in other projects and that can pay off in unexpected ways.

Rotating empowers anyone to fix issues on any project

Once a developer has worked on a project, they will feel comfortable fixing issues on that project. When a company does not rotate developers this is not the case. When a project has production issues the developers of other projects wait for the developers of that project to fix it. This doesn’t have to be the case. With sufficient trust and collaboration, any developer could feel empowered to fix any production issue regardless of the project.

Rotating can reduce employee churn rate

A lot of developers start to look for a new job when they feel their current job has stagnated. It’s no fun to know everything you’re going to do day in and day out for years to come. Another reason developers quit is that they want to work with new people or learn a new technology. Rotating gives a developer all of those opportunities with very little downsides (relative to having an employee quit).

Some projects are less fun than others. If a developer is stuck on a bad project and it feels permanent, they’re likely to look for a new job. But if a new project is 6 months away, the bad project will be temporary and an employee is more likely to stick it out.

Rotating is an opportunity to learn

Having a developer stuck on a project for years is like having a developer live on a little knowledge island. They are learning things that would be valuable to share with others. Others are learning things that should be shared with them. When the organization structures these communication boundaries so developers can’t share experiences, everyone is left to their own devices to learn.

This is inefficient because some islands that others have already learned. Some islands may never learn a lesson that they should.

Rotating gives developers an opportunity to improve code quality

I’m working on a project right now that has had over 4 people rotate on. Each time a new person rolls on, they point out a low hanging fruit for improving the quality and stability of the code base in their first week. Why does this keep happening? Because a pair of fresh eyes can easily see the eyesores that the rest of the team has learned to adapt to over time.

When developers know they will be rotating onto new projects and responsible for sharing context before they leave, they’re going to be encouraged to write maintainable code. It’s far too common for a developer to silo knowledge so that nobody can understand it but them. Frequent rotation reduces this risk by addressing it earlier.

Rotating can reduce ego

Pride can be a good thing when it improves code quality. But ego can get in the way of code quality and cause developers to silo the knowledge of their project. Frequent rotation reduces this problem to a 6 month period because that’s the longest that an individual can “own” their code. I’ve discussed in other articles why code ownership is a bad thing.

I will say that there are more effective ways to deal with this issue (pair programming comes to mind).

---

Hopefully these advantages have convinced you that your company should be rotating developers onto new projects more frequently. Feel free to reach out to me if you have any questions or concerns.

Join the email list for bonus content.

Email address: First Name: Last Name:

Leave this field empty if you're human: