While taking my career break I have been doing some reading around organization structures and building high performing teams. One of the books that came up in my list was Dynamic Reteaming by Heidi Helfand. I picked this book up because in my career I had seen a several examples of how team structures evolve and change over time and figured it would be great to really dig into some of the patterns that have been identified across many organizations.
The book covers five different patterns for changing teams: One by One, Grow and Split, Isolation, Merging and Switching. It also digs into some specific details of how team assignments can happen ranging from top down assignment to individuals choosing which teams they want to be on and how to build a process that can support teams changing in a truly dynamic fashion.
One By One
This pattern is the most common and basic I have seen in my career, it is when you simply grow teams one new hire at a time. They’re interviewed, hired, onboarded and placed within existing teams. The author covers a lot of real world examples at onboarding efficiently to set new hires up for success.
Some pitfalls that are identified include winding up with an imbalance of juniors to seniors, mentors succumbing to fatigue of having onboard too often, and neglecting to properly vision out a career path at the beginning of the new hire’s tenure.
Grow and Split
I had known this by a few names in the past, including “Team Mitosis.” The consequence of One by One team building is that you eventually fill out a team until it reaches a maximum size that requires splitting into two or more smaller teams. When I was at Carfax I witnessed this on the team I was on that added new hires each week until our morning huddle became a long and dull ceremony as we went around the room and heard from about 20 people on what they were doing that day. Eventually, we split the team up into smaller product focused teams.
The author identifies several criteria that help decide when it is time to split. Meetings start becoming too long, decision making starts becoming fractured and difficult, and the work of the team becomes more and more unrelated. Back to my experience, I remember spacing out a bit because out of the twenty people in the room, only about four were working on something that I was involved with. While the rest were interesting, they were working on features and systems I had no involvement with.
It is important to include the team in the decision to split the team up and spend some time finding each team’s “North Star.” Equally important is to articulate clearly why the team is being split and determine how people will be slotted onto each team.
Isolation
While the “One by One” and “Grow and Split” patterns deal chiefly with company growth, the isolation pattern is introduced as a solution to help combat rigidity that might arise as a company grows and processes become more formalized. You basically create a team of people pulled from existing teams and put it to the side and give the team more freedom to get work done. I have seen this approach several times in my career as well, sometimes called a “Tiger Team” is formed to solve a pressing problem such as the adoption of a new framework, clean up tech debt, launch a completely new product stream, etc.
I have also seen this pattern utilized for “labs” type initiatives when a company wants to invest in a potentially new product line. The author demonstrates this in a real world example where a team was isolated to help pivot a company from failure by building a product that would eventually become GoToMyPC.
The tips provided on this approach is to invite people who are more self-led and self organizing onto the team, let the team choose how it wants to work and give them their own space. Determine if the team will live on past the initial milestone or if they will fold back into their original teams. If they fold back into thre original team there are important questions to answer with regards to maintenance and code ownership.
Merging
Merging happens when two or more teams are combined together. Several scenarios that might call for this situation include the acquisition of a company where the combined team can transfer knowledge faster, combine teams to solve a specific threat or create a larger team to allow for more fluid reteaming. The book again mentions a situation I am familiar with: merging two teams to provide more variety in pairing. I had encountered this before as well when we had two teams of four. It means that one would pair with only three people and over time the members of the team developed the same mindset, skills and approach. By merging another team we were able to introduce more variety as part of our pairing sessions.
In addition to several scenarios of merging teams at the team, tribe and company levels, the chapter on this pattern covers the common pitfalls of the larger team structure and several techniques to navigate them successfully.
Switching
The Switching pattern is introduced to help increase engagement when teams begin to stagnate. Moving team members between teams allows for the opportunity for them to freshen their perspective and change their focus. The important aspect of switching is that it encourages more resilient teams as you can avoid having only one person being knowledgeable of a particular codebase.
A common reason might be to switch someone for personal growth and learning, to rotate pairs or to deliberately switch team members to encourage knowledge sharing. In my personal experience I have also done all of these, both as an individual contributor and as a manager. I had a member of a team who wasn’t performing well and when we discussed it, they confessed they would be happier doing product work. I shopped around teams and was able to get them to switch places with someone on a team who was interested in the infrastructure team. Likewise I have switched people into teams to help share knowledge such as message oriented systems with a new team.
A pitfall is that teams may try to hoard high performers. Once you get “good people” on a team it is hard to let them go to another team. Several ways to solve this problem is to have a community of managers with shared goals as well as individual development plans for engineers to suggest reteaming to meet those specific goals.
Tactics for Mastering Dynamic Reteaming
This section gives a ton of great strategies to plan and enable dynamic reteaming within an organization. I really like this because enabling teams to be self-forming and self-led is highly desirable but takes good planning and structuring to get right. Included are techniques to regularly calibrate and use retrospectives to determine when change is needed.
Closing Thoughts
I really enjoyed this book and it will be indispensable to include in my tactics and strategies when it comes to building and adapting teams. It gives a wealth of real world examples and provides a guide for pitfalls that can be encountered when changing up teams.