Building a theory of job rotation in software engineering from an instrumental case study (2016)
Managers sometimes move employees to new projects once in a while, as it’s thought to be beneficial to them and the company. Santos, Da Silva, De Magalhães, and Monteiro conducted a case study at a Brazilian software company that systematically applies job rotation, and describe how this practice actually impacts workers.
Why it matters
If a software development company doesn’t want its engineers to walk away, it has to work hard to keep them happy. This can be partially achieved using job rotation, i.e. letting engineers move to other projects once in a while.
We know from prior studies on human resource management that job rotation works. This study by Santos et al. is (one of) the first that specifically studies the impact of systematic job rotation within a software engineering context.
How the study was conducted
The authors conducted interviews and analysed documents at a large Brazilian software company that frequently rotates its developers between projects.
Interviewees were sampled from two projects: the first systematically applied job rotation, while the second only did so sporadically. Furthermore, interviewees from each project were chosen such that a variety of job rolesDevelopers, testers, managers, technical leads, etc., backgrounds, and perspectives on job rotation were represented.
What discoveries were made
Findings from this study should be useful to anyone who considers re-evaluating their job rotation strategies or moving to a different project themselves, but might not be applicable to every situation.
Engineers usually assume the same role in their new projects, but that doesn’t have to be the case: some engineers change roles if their new project requires it.
A rotation can be triggered at any time, e.g. when an engineer:
- has completed their work on the old project;
- has specific skills required by their new project;
- didn’t perform as expected in their old project;
- requested a transfer to a different project.
Rotations are done primarily to fulfill project needs. Additional motivations are increased flexibility of teams, knowledge sharing, and opportunities for developers’ professional growth.
Job rotation allows engineers to work with new domains and technologies, which increases work variety and allows them to acquire new skills and experiences, both of which are beneficial to the engineer and their employer.
But job rotation also comes with downsides.
If an engineer is moved to a different project before they’ve had the chance to finish their work, they’ll have to spend time on training their replacement(s) in addition to the higher workload from their new project.
That’s not the only downside however: engineers believe that a “premature” rotation affects the feedback that they receive from their managers.
While the authors couldn’t find any corroborating evidence for those beliefs, it is clear that a job rotation will result in an actual short-term loss of productivity:
- The rotated engineer won’t be familiar yet with their new project;
- Whoever is assigned to fill the gap left by the rotated engineer will also have to familiarise themselves with their new project;
- The engineer’s old and new teams need to spend time on training.
The effects show some key relationships that should be taken into account when applying job rotation:
- The amount of knowledge that an engineer can acquire from a rotation, depends on the skills and knowledge they already possessed, and what’s their new project provides. Therefore, larger knowledge gaps result in more knowledge acquisition. This is a lasting gain, i.e. the engineer can benefit from acquired knowledge indefinitely.
- A rotated engineer usually has to learn a lot of new things in a short time and train their replacements. This increases their cognitive workload, which then negatively impacts their performance. Fortunately it’s only a temporary loss that will eventually disappear when they spend more time in their new project.
- If an engineer is rotated before they’ve managed to finish their work, the quality of feedback will take a hit. Since the impact of bad or negative feedback can’t be easily recovered, this is a permanent loss.
The authors conclude their theory with two hypotheses:
- If you want more lasting gains, you’ll have to incur more temporary losses. The severity of these losses is moderated by the individual’s skills and the moment of rotation.
- Increasing the frequency of job rotations increases lasting gains, but also permanent losses. The severity of these permanent losses are moderated by the moment of rotation only.