Heidi Helfand on Dynamic Reteaming (Scaling Tech Podcast Ep18)

Apr 18, 2023 | Developers, Team Management

Change is constant, and our teams are no exception. So while we might strive for creating stable and consistent teams, the reality is it’s not possible to maintain those teams very long. Instead of being reactive to team changes, how can we more proactively harness change in teams for good? That’s the topic of our conversation today with Heidi Helfand, author of the book Dynamic Reteaming.

Heidi coaches software development teams using practical, people-focused techniques, with the goal of building resilient organizations as they double and triple in size. Her 20+ year career in tech helped launch Procore Technologies and AppFolio to IPO and Expertcity to acquisition by Citrix. She was on the original development team that built GoToMeeting and GoToWebinar. Heidi is based in Southern California.

Your team is changing, so join us for this episode to learn from Heidi the best ways to handle that change!

Listen on Spotify
Listen on Apple Podcasts

Watch the video:
Show notes with links to jump ahead are below

Show Notes from Episode 18 – Heidi Helfand on Dynamic Reteaming
Timestamp links will open that part of the show in YouTube in a new window

  • 00:00 In the opening quote, Heidi talks about how traditionalists in the area of teams will often say change is the problem. Heidi sees it as an advantage, and team change can help improve the quality of life for all the team members.
  • 01:08 Arin and David start by talking about how we live in a world of constant change, and our teams are no exception. Stable and consistent teams are not possible, and so harnessing that change for good is our topic today. David notes how we have lacked a framework for a long time for managing team change, and so this conversation will provide that framework to our listeners. Arin notes this conversation challenged him on his assumptions about when or if you should ever split up high performing teams.
  • 04:03 Arin introduces Heidi Helfand as author of the book Dynamic Reteaming. Heidi coaches software development teams using practical, people-focused techniques, with the goal of building resilient organizations as they double and triple in size. Her 20+ year career in tech helped launch Procore Technologies and AppFolio to IPO and Expertcity to acquisition by Citrix. She was on the original development team that built GoToMeeting and GoToWebinar. Heidi is based in Southern California.
  • 04:35 We start by talking more about Heidi’s background, and how it led her to see the art and wisdom of changing teams. Heidi has most recently worked as a VP of engineering, and worked with tech teams throughout her career, and she realized how teams change constantly, but that this type of change is challenging territory and she wanted to dig into this material more while writing her book. Most books say you have to keep a team consistent for as long as possible, and she felt that really negated the experience of her career in dynamic and growing software teams.
  • 07:10 Heidi expands on why changeable teams are still teams. Heidi talks about reviewing litearture on Tuckman’s model on Storming, Forming, Norming, and Performing. Adjourning was later added to that list of team phases by his coauthor. In separate research about group therapy, the authors struggled to complete studies because people were constantly leaving and being added to teams. But that’s reality! Heidi found it interesting how traditionalists in the area of teams will often say change is the problem. Heidi sees it as an advantage, and team change can help improve the quality of life for all the team members. Adding people to a team to create redundancy can make life better for everyone on the team. It also allows team members to work on a wider variety of things. If someone doesn’t want to switch, or doesn’t want others to join them, that is more of a challenge however.
  • 11:19 David talks about how whenever we work with a new client, and add outside contractors to their team, we are triggering a reteaming event. That change requires thoughtful processes because a team has to think about how to integrate new team members, how to onboard them, how to get others to work on the code, how to work better remotely, etc. Heidi talks about how it would have been counterproductive in a growing org to pretend that teams must be static. She tells a story about when 20 people joined her organization as interns in the same day. The onboarding of that large group was a big deal and required a different process than when people just joined a team one at a time. It would be nice and convenient if teams could stay together for so long, but that’s just not the real world.
  • 15:15 Heidi says that her talks about started re-org’s, but that was not her goal. Change for the sake of change is not good, but teams grow and contract, and something that requires further reorganization in the company. Because we still have to keep knowledge in house and deliver software! David mentions how the VP of Engineering has the power to address these decisions up front, and cannot be afraid to do that top-down. In some cases though, David has seen problems where a client is not willing to take on that change though. Leaders who execute these changes must have the power and accountability to the lead the change. Heidi notes that a VP of Engineering or a Director of Engineering may be the leaders involved, and they are the ones who need to do the risk management to make sure that knowledge stays in house. How do you help people feel like they are part of the group, regardless if they are contractors or employees? That has to be considered too. The focus must be on both culture and software delivery.
  • 19:55 David asks about how remote work has changed the concepts behind Dynamic Reteaming. Heidi notes that timezones can be challenging for sure. Heidi likes to map out organizations in a spreadsheet and organized by the timezones they work in, to see how much overlap there is. If you cannot get around only having 2 hours of overlap in a team, then the team needs to be structured differently. You can change your teams to be based on similar timezones, but it depends on the organization. Team composition is one of the levers you have. Using video is very helpful and does allow for a lot of video, but meeting strategically at the team level is worth the investment. You don’t need to get 500 people together, just the closest units of people. Shared experiences from team events become a form of currency in the organization. David and Arin laughed about a time they did an Escape Room activity in Sao Paulo Brazil with a group of developers who spoke 3 languages, but managed to finish with only 3 seconds left even though we already had been enjoying some caipirinhas (a Braziling mixed drink).
  • 25:15 Arin asked Heidi about some of the patterns described in her book, and he asks about two specific scenarios. He asks her to imagine an internal engineering staff of 40, and they bring in 20 outside engineers all at once – is that a good idea? What pattern should you look at, and how would you approach it? Heidi talks about the “Grow and Split” pattern in the book, where you add people to a team until it starts to feel unwiedly and inefficient, and then you split the team into a couple smaller groups to make them more efficient again. You also have to consider dependencies when splitting teams, to make sure you don’t create dependencies on each other and that the right roles are included in each team. Heidi also mentions the Isolation pattern, because if the new people are going to work on a new product, then you might want to keep them in a separate team isolated from the legacy development team. But that can create some cultural divide in the company, so that has to be considered if that’s a good or bad thing. It might be good if the legacy team is having a hard time splitting from older practices. Heidi also points out the importance of cadences and the dangers of cadence mismatch – a two week sprint might be too long for teams doing rapidly prototyping. But in general, Heidi would question if adding 20 people to a 40 person team at once is too much. It can create a big wave in the system and so must be planned carefully. A change that large should involve a lot of input from the existing team.
  • 34:00 Arin asks for the sake of discussion, let’s assume that the situation is a startup who has received a large amount of funding and will need to grow by 50% over the next year. In that case, would you rather add them all at once, or slowly over time? How do control the creative destruction that can bring? Heidi notes you don’t want to shock the system too much. This is an area where remote can actually help since you don’t see all the change at once, you don’t see all the new people in the office, and so it can actually be helpful. The most important thing is to have a coherent strategy within the leadership team, and that they talk about it and invite ideas from the team. Creating a unified front as leaders can really help the organization get behind the reasons for this change, and everyone buying into how you make the change. This will help you to include more perspectives from management if they see that the executives are clearly communicating why the change is necessary, even if everyone agrees there will be challenges. Teams should use agile retrospectives to help them cope with the changes and learn from them. Arin asks Heidi to confirm that Reteaming requires both top-down and grassroots support, and that iteration is important so you can learn from the addition of new team members. David also notes that he’s never seen a reteaming as large as 20 where it went smoothly, it’s hard to keep everyone engaged.
  • 40:30 David’s last question is after a reteaming event, does Heidi recommend you pay attention to specific metrics of success to see how it went? Heidi says it gets back to the metrics you were already looking at for delivery, but you have to recognize adding new people will create a temporary dip in productivity while the team ramps up. Heidi prefers qualitative feedback about how the team is doing, but recongizing that you should not expect immediate increases in productivity or throughput. Heidi also recommends having regular engagement surveys to get feedback from your team before and after a reorganization. Engagement surveys are different when teams go through a downsizing, because those who stay in the team still experience pain and loss for months after the reorganization. In those situations, it’s important to focus not just on helping those who are leaving, but also helping those who remain cope with the change and the loss of those coworkers. David notes how Heidi is stressing that it’s important to understand what reasonable expectations we can have about the effects after a reorganization. We still have to get things done at the same time while people are adapting to the uncertainties and abrupt ending that the reorganization created. Heidi mentions the William Bridges book on Transitions, which talks about these changes that people go through in life in general.
  • 51:04 Arin asks about one of the anti-patterns in the book: Reteaming to spread High Performers. There is a story in the book where a team of high performers was spread around the company to spread them throughout the company. When is that a good idea, and when is it a bad thing? In the specific story in the book, this team of high performers had a great vibe and was jamming very well. The leader thought it would be good to spread that dynamic and knowledge to other teams, but it ended up just settling into three “ok” teams. Heidi says an alternative he could have tried is to have lunch-and-learns to help spread knowledge from the high performers to another team. Or maybe us the Switching Pattern in the book, where just one person switches temporarily between teams, and the guest worker in that high performer team could bring the skills back to their team. Heidi is reluctant to bust up teams that are doing really well.
  • 54:28 Arin brings up a quote from the book about “you can’t make guacamole from an unripe avocado – sometimes teams are just not ready for change.” Heidi notes it is hard to force things if a team doesn’t want to change. It comes down to storytelling and influence with that team, and giving them some stake in the team. You can bring in an external speaker to inspire some of them. Heidi would get teams that she was coaching to present to other teams, to help them see the value of the change. Again you need some top-down and grassroots support.
  • 56:30 To learn more about Heidi’s work and to find her book Dynamic Reteaming, visit HeidiHelfand.com and connect with her on LinkedIn.

Links from Episode 18 – Heidi Helfand on Dynamic Reteaming