What to consider when you plan to change people in IT projects?
At Trinidad Wiseman (TWN), our goal is long-term partnerships, which in practice means working in the same business field for years and offering solutions to the client. From the perspective of software developers, such long projects can occasionally lead to fatigue in terms of the project field or technology.
In such situations, the rotation of developers comes to the rescue. By rotation, we mean the process of moving one team member from one project to another. At TWN, we believe that developer rotation has many positive aspects, but at the same time, you have to be careful with it.
Let's start with the positives:
1. Rotation reduces employee turnover.
Developers start looking for new challenges when their current work has exhausted itself and no longer offers a challenge. It is not too exciting to do things day after day that you already know very well. Another important reason is often technology. Developers want to experiment and learn new technologies, which is often not possible in a long-term project.
In addition to the technical side, the basic knowledge of the business field and the resulting excitement should not be underestimated. Having implemented digital transformations in the financial sector for a long time, creating solutions in, for example, in agriculture or medicine is a great challenge and change.
2. Rotation provides an opportunity to learn.
Doing the same project for a long time starts to seem like the only way to do things. TWN has role-based experience exchange workshops and various internal trainings, but hands-on experience is still the best way to get a feel for how another project is delivered.
3. Rotation improves code quality.
Being on the project for a long time, you get used to some nuances so much that you don't notice them anymore. Every time a new member joins the project, he/she has questions about why something is done the way it is. It often helps to improve quality through small changes.
4. Rotation reduces the ego.
When working on one project for a long time, a situation arises where the developers "own" the code. "Owning" the code leads to problems that prevent effective collaboration and seeing the bigger picture, ultimately leading to a poorer result.
There are two sides to everything. The same goes for rotation. It is worth paying attention to the following points:
1. The basis of a successful software project is a team that works well together.
It takes a long time for team members to get to know and respect each other. Everyone has their strengths, weaknesses and quirks. It can take almost a year to begin to understand what kind of tasks someone likes, what type of humour their peers have, and who evaluates workloads.
That is why it is worth being very careful when changing this micro-community. A new team member will inevitably have to replace the so-called "old" team member, and consequently, you can hear opinions from the team that it would have been easier to give this job to the developer who was just rotated out.
In addition, bringing in a new team member means a decent learning curve in the initial phase of the collaboration. Success here is guaranteed by a well-developed mentoring system, which we discussed in TWN in more detail in our previous blog article.
2. What about finding a new project for the whole team?
This is definitely the best way to implement rotation. Here, of course, there are some prerequisites - the previous project made by the team must be completed, or it must at least be at such a level that it can be passed on.
It is not wise to go overboard with rotation; rotation is certainly not a tool to solve problems. Instead, it should be seen as an opportunity to improve things.
