Why development team membership should change regularly
Static development teams might be hurting your company. But too much reorganization can cause chaos. Here's how to strike a balance that keeps teams engaged and innovative.
IT organizations must keep software teams engaged with the work that they do. At the same time, companies should improve software development speed and quality. You can achieve both goals.
To attain high levels of employee engagement, a company might balance IT talent with a new structure, or encourage developers to innovate with new technology. Some say that development team membership should change regularly.
When you mix up IT teams, it helps the organization chip away at silos of information, said Jorge Perdomo, co-founder and CTO of goTenna, a mobile mesh network company. And a fresh set of eyes on a project can identify flaws that a stagnant team might miss, he said.
Additionally, when an organization mixes up IT teams, employees can bond with new people formerly from different groups, increasing morale and employee retention. "The more you mix up, the stronger social bonds you create within the enterprise," Perdomo said.
Another reason development team membership should change is that it builds resilience across the organization. "You want people solidly briefed on what is being done where, why and by whom, so that you can find efficiencies and keep internal production alignment," Perdomo said.
Shuffling workers provides important signals about the health of development and testing processes. When an IT organization moves people around, its leaders should ask themselves two questions:
When people cycle in, do they find the same bugs as the last individuals?
When something breaks, does everyone look toward one person for answers, or are there multiple developers who can get things running again?
How often team membership should change
Some people mix up team roles and membership often, while others do not. What works for the development team membership might not apply elsewhere, even within the same company.
Business leaders should change the makeup of their teams about every 12 to 18 months to increase productivity, said Mike Saccotelli, director of software engineering at SPR, an IT consultancy. "It is during this timeframe when people's interest can start to wane, so mixing up teams regularly also keeps employees engaged," Saccotelli said.
This type of shakeup provides employees with growth opportunities and exposes their teams to different perspectives, he said. The organization could swap team members out, or just assign new roles and responsibilities within the same team.
That 12 to 18 months tenure on one team should be the minimum in IT, unless special circumstances exist, said Aviv Ben-Yosef, tech executive consultant and coach at Aviv Ben-Yosef Consulting. However, an enterprise can balance permanent reorganizations with temporary shakeups in between. For example, teams might pair up on occasion, do exchanges in which someone joins a different team for a week, and hold cross-team meetings for learning and development.
If you keep the developer in one project all the time, it kills his willingness to learn and creativity to solve problems.
Konrad RotkiewiczCEO of Ulam Labs
Ben-Yosef worked for the Israel Defense Forces (IDF) cyber units, where he witnessed how even the country's brightest professionals needed time to develop deep insights about their teams. The IDF frequently organized cross-team task forces for short periods of time. These task forces, he said, brought innovation, boosted knowledge sharing and prevented a brain drain into only the most interesting teams. "Most people got to experience interesting projects this way," he said.
A conservative timeframe for development team membership changes can also work, said Konrad Rotkiewicz, CEO of Ulam Labs, a software development company. Ulam Labs changes one member of a three- to five-person team every two to three years. This arrangement helps add fresh energy and ideas to the team. A new member often happily works on features that more senior team members might consider monotonous. This approach also enables developers to challenge themselves in new projects.
"If you keep the developer in one project all the time, it kills his willingness to learn and creativity to solve problems," Rotkiewicz said.
How to keep workers engaged
An IT organization must find ways to balance perspectives and talent across teams when it shuffles employees around. "Directors and other leaders should work to cultivate teams with cross-functional skills and varying levels of experience," Saccotelli said. Balance across IT and dev teams helps to cultivate junior-level talent and gives senior members of the team the opportunity to mentor and manage junior teammates. Developers need opportunities to grow beyond their technical skills because mentorship and team leadership are key skills for career progression.
Make sure that employees can express their desire to move to new projects. "Providing this flexibility has been a key component to retaining our talent at SPR," Saccotelli said.
Managers must properly set expectations. If a move cannot happen immediately, explain the plan for it to happen and a reasonable timeframe. Of course, IT organizations can't accommodate every employee who asks for a new project that focuses on an engaging technology. In those instances, identify and prioritize growth opportunities within an employee's existing projects where they can develop skills like communication, team leadership, mentorship and client management. "While these skills aren't always what people have in mind when they think of 'interesting work,' they are skills that every good technologist will need throughout their career," Saccotelli said.
Product portfolio management
A dynamic approach to creating teams and moving employees around can help balance each team's amount of talent. Product portfolio management (PPM) takes a proactive approach to change development team membership.
Product portfolio management is a high-level view of the company's projects through which leaders can identify problems and opportunities, and allocate resources accordingly. By addressing the products as a portfolio, the company can move employees into roles where their skills and experience will prove most effective.
Many organizations adopt a PPM approach, in which engineers are effectively internal consultants or advisors who switch projects frequently, said Ravi Lachhman, developer advocate at Harness, a continuous delivery platform.
A PPM model allows engineers to go where the organization needs them -- and where they, personally, are interested in contributing.
Organizations must strike a balance of experience and fresh perspectives. Interns are a great example: They bring rose-colored glasses to their projects, Lachhman said. Contrast this enthusiasm with a veteran who has personal experience with many roadblocks to project success.
Development team membership should also change to enable individuals to gain different domain skills, which is invaluable to their careers and keeps them engaged and innovative. "Pigeonholing developers to certain teams doesn't motivate talent to stay put," Lachhman said. "Keeping teams fresh leads to team members who are optimistic and focused on a shared goal."
Consistency despite changing faces
Developers keep a lot of knowledge about a project or technology in their heads. It's inevitable that developers changing teams take that information with them. Some developers will leave the company entirely, or be unreachable for other reasons.
"Sometimes you don't get poached, but someone can get hit by a bus," Perdomo said. "So, don't have all your eggs in one basket."
In these cases, think about ways to mitigate the impact of departures, Perdomo said. In the best scenario, that developer spends two weeks doing a handover via documentation, code commenting and training of replacements. But don't count on it. Ensure that everyone on each team documents all work. "Enforce code commenting, so that if you do lose someone on the team you can try to recover as quickly as possible," he said.
Additionally, it's helpful to have at least two leads for any engineering discipline; they can check on, or provide a backup for, each other.
The counterargument on changing dev team members
Not all experts agree that IT or development team membership should change. Some caution against breaking up teams on an arbitrarily set schedule, and others eschew the practice entirely.
"You do not want to mix up your development teams; this is a bad practice," said Marina Nitze, partner at Layer Aleph, an IT consultancy. Nitze also served as the chief technology officer of the U.S. Department of Veterans Affairs from 2013 to 2017.
Nitze says teams grow together, and they can become more effective over time. If an organization breaks up an "A team" and disperses its members, she said, it could have a disastrous result. "This doesn't make all your teams better, it eliminates the existence of a high-performing team," Nitze said.
Balance out innovation with efficiency, said Antony Edwards, COO of Eggplant, a testing tools provider. While mixing up dev teams will sometimes lead to innovation, it can also result in confusing and inconsistent products.
"It'll probably just end up with people constantly rewriting the thing," he said. "The first thing any developer does in a new team is rewrite everything."
Avoid large-scale reorganizations, Edwards said; it works better to draft people in on a per-project basis. For example, one of Eggplant's dev teams has five people, and it is currently working on a security project. That team recently brought in a sixth person from another group for this project -- not a whole new bunch of fresh faces. "That ensures that we get the right expertise, and we get a bit of challenger thinking, but we don't hurt the core team dynamic," Edwards said.
Mixing developers up can break the delicate balance that might exist between different perspectives. "People who think differently to each other and only just met usually don't like each other and don't work together well," Edwards said. "But people who are different and have embraced that difference are great."
Dig Deeper on Software development team structure and skills
