In life, change is inevitable. This is particularly true in the realm of software, for both technology and personnel. People may leave your team for a different team, or for a different company altogether, or new team members may be hired onto the team and need to learn the ropes.
Frequently, team member transitions can be stressful. This is true for both managers and for clients working with a software consultancy like Atomic. The stakeholders or project owners naturally want productive work to continue. They want to keep the team they know and see no upside to changing the existing team. They may fear that the new developers will be less technically skilled, or lacking in communication skills or organization. In any event, every transition period has costs.
Change isn’t all bad, though. I would argue that semi-regular changes to a team can actually strengthen the software product and increase the quality of developers within your organization. When team member changes are a semi-regular occurrence and not a sudden crisis, good things can happen.
Smoother Transitions
For one, with regular additions to the team, existing team members are incentivized to keep documentation current. They are also naturally going to make the ramping-in process as painless as possible. Team members will remember what it was like to ramp into the project themselves, and they will want to pass on the lessons they learned.
Team personnel changes are inevitable anyway, so you might as well get used to them. Intentionally swapping out team members from time to time serves as helpful preparation for those moments when circumstances dictate change.
“Well-Rounded” Code
A team which must absorb new members every five or six months will produce more “well-rounded” code. That is, such a team will produce more approachable, standardized code than a team whose members stay the same for years at a time.
At a former job, I was a member of a large team that inherited a complex code base from a small, tight-knit group of developers. We found the code nearly indecipherable in places; it was impossible to tell what unintended side effects minor changes might have. Moreover, we couldn’t go to anyone for help–the original small team of developers all left the company together to start a new venture. Had the initial team rotated members in and out, I have no doubt the rough edges in the code would have been smoothed out. They would have had no choice but to make their code “friendlier” to newcomers.
You could make the argument that rotating team members encourages “lowest common denominator” choices with regard to tech stack, programming techniques, and software architecture. The concern is that teams will only use the technologies “everybody” knows and never try anything new, even if said new technique would be tremendously beneficial.
But I’m doubtful. I find that “lowest common denominator” syndrome is generally due to interference from above, and not from within teams. Rather, needing to bring new team members up to speed exerts pressure to utilize only the most beneficial among “advanced” programming practices.
Speaking as someone who loves functional programming intensely, when I’m writing a project in an imperative language, I find it helpful to have the pressure of explaining my choices to others. Otherwise, I’m tempted to go hog-wild with whatever cool technique I’m reading about, whether it is appropriate for the project or not.
Inertia
Then there’s the issue of “inertia.” When you’ve been on a project for a while, you stop noticing some of the tradeoffs and tech debt that you’ve built up. You might have sprinkled some TODOs in your code, but the Vegas odds on actually addressing those TODOs gets lower with each passing day.
But when a new member joins the team, she is seeing the code–and the broader context of the project–with “fresh eyes.” Issues or challenges you tabled long ago don’t seem as intractable to someone coming in from the outside. A new developer joined my current project recently, and I was impressed with how quickly he spotted many of the technical debt or wish list items I’d long forgotten. He also has a much better sense of which parts of the project are the hardest for a new person to understand. This provides helpful guidance towards improving those aspects of the system–or at least providing better documentation.
Developer Growth
Finally, I firmly believe that it is in a developer’s best interest to change projects from time to time. I am of the opinion that two years is about the maximum time a developer should stick with the same project.
Developers can and should integrate new libraries or techniques into their ongoing projects, but for my money, there’s nothing like jumping onto a new project–possibly with a different tech stack–to spur growth. Developers or teams that are siloed for long periods of time may become “comfortably numb” and lose the drive to keep learning. In my opinion, rotating developers occasionally will increase the quality of your organization’s pool of developers.
Looking for the Upside
Changes to a project team can cause anxiety, but those same changes can also bring fresh energy and improve the project. The key is being ready to see opportunities when team members join the project, and capitalizing on those opportunities. When have you seen new team members bring clear benefits?