BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Q&A on the Book Dynamic Reteaming (2-ed)

Q&A on the Book Dynamic Reteaming (2-ed)

Key Takeaways

  • Conventional wisdom says that having stable teams leads to more productivity
  • Having teams stay stable is unrealistic in the dynamic environment of software development today
  • Team change is a natural, cyclical occurrence, and leaning into the inevitability of change, as opposed to the quest for “stability” is more realistic
  • Without careful thought to how to re-team effectively in the specific context, team instability can have negative consequences for teams, individuals and organizations
  • There are a variety of approaches to re-teaming that take advantage of the dynamism without losing productivity

Heidi Helfand has released the second edition of her book  Dynamic Reteaming in which she makes the case for changing the focus from building and maintaining long-lived stable teams to creating an environment where teams form and reform in response to changing needs and both internal and external pressures.  This approach seems to go counter to much of the literature around team formation, especially in the realm of software development.    Heidi spoke to InfoQ about why she wrote this book and why dynamic reteaming can be a more effective approach to unleashing creativity and high performance in teams.

The book can be purchased here and InfoQ readers can download a sample chapter.

InfoQ readers can get get 20% off on Dynamic Reteaming using the promotional code  20RETEAM until September 15, 2020 11:59:59 PM PDT

InfoQ:  Why did you write this book?

Heidi Helfand: I wrote Dynamic Reteaming because I was tired of advice stating that effective software teams are the ones that stay stable as the goal. I found that advice like that, especially in high-growth startups, is short sighted, and counter to the goal of growing and expanding into a successful large company.  And it went counter to my experience working at two successful startups - one where we built GoToMeeting and GoToWebinar that got acquired by Citrix, and the other, AppFolio, which is now a successful public company that grew from ten to thousands of people. We weren’t “doing it wrong” at either of these companies as our teams shifted, reorganized and scaled.  So I became curious. Was dynamic reteaming just a pattern in high-growth tech companies in California?  Then I embarked on interviews with worldwide colleagues, derived 5 dynamic reteaming patterns, and wrote the book. It was an incredible journey of discovery and learning. And now the second edition has been released by O’Reilly. I wrote the second edition in order to provide more specific “how to” advice for companies that are continuously reteaming, based on what I’ve learned since releasing the first book.

InfoQ: Who is this book for?

Helfand: This book is for people working inside software companies who influence or decide on changes to their teams.  Sometimes they are the CTO, directors, VPs or managers. Other times they are empowered team members who shift their own team compositions to better manage their own work.

InfoQ: The strong message over the last few decades has been that teams need to be stable in order to become high performing.  Where did this idea come from and why is it so prevalent?

Helfand: I think the stability bias might come from a team development model by Bruce Tuckman in 1968 in his article, “Developmental Sequence in Small Groups” in which he writes of the stages Forming, Storming, Norming, Performing (and later Adjourning in 1977 with coauthor Mary Ann Jensen). These words imply a linear progression for teams and groups to attain some kind of performance nirvana. And, forming, storming, norming, performing is super catchy - like some kind of old-school meme, which is why I think it caught on. I wonder though, if people know that Tuckman came up with that model when reviewing 50 or so other articles in the realm of psychoanalytic studies of therapy.  Software development is clearly not group therapy. But as catchy phrases go,” forming, storming, norming, performing, and adjoining” can be a useful metaphor to refer to the jelling of teams.  So it’s not that I’m against it, I just think that team change is a natural, more cyclical occurrence, and leaning into the inevitability of change, as opposed to the quest for “stability” is my chosen focus. It feels more practical and authentic for those of us who are used to working in fast-growing software companies with continuously changing teams. I mean, when you’re hiring like crazy and doubling in size, preaching team stability is counterproductive. Instead, you want to lean into the change and strive for it to be seamless as the strategy.

InfoQ: Your message, that teams can (and should) change their makeup frequently goes against conventional wisdom - why is this disruption necessary?

Helfand: No. My message is this: Your teams will change. It’s inevitable. You need to be prepared and get good at facilitating it. The rate of change varies. Some people are in companies with more change, and some with less change.  During startup to public company hypergrowth, it might feel like your teams are changing constantly due to the addition of all the people.  Whereas at other places, where growth is less frequent and you’re just maintaining what you have, it might feel like you’re changing like a glacier. It’s super slow. 

So I’m not saying “start quickly now and break up all of your teams”… instead what I’m saying is that sometimes you want to change the composition of your teams for a variety of very good reasons.  The book talks about 5 patterns of dynamic reteaming, which really illustrate the structural changes in teams due to reasons like growth and attrition, the desire to work on a new area of work or product, for spreading knowledge, for handling emergencies and for fulfillment and learning.

In the “switching” reteaming pattern, for example, you deliberately move people from one team to another, at a digestible cadence, in order to spread knowledge around your organization. This helps to build resilience and redundancy, so people aren’t stuck working on one feature forever and so that when someone leaves, their work is easier to carry on.   

Moreover, remember “forming, storming, norming, performing?” This is where I like to say that Tuckman forgot a step there which is “stagnating.”  As humans, being on the same team for “too long” can feel like we’ve stopped learning. We’re not progressing.  Recognizing that people grow and change and want new opportunities is key here.  Don’t just keep us in the same team forever - it will limit us.  Strive to retain us by offering new team opportunities.

InfoQ: You’re very clear in the book that this reteaming needs to be done with purpose and intent.  What are factors that come into play when organisations are looking at adopting reteaming as a strategy? 

Helfand: Reteaming is either catalyzed by the people in the teams, or by people who are outside their team.

When a team has the authority, and makes the decision to shift their own composition - like maybe a large team splitting in half, they are usually trying to solve problems like these: “Our meetings are too long. Our work has diverged. It’s too hard to make decisions in this big team.” They are trying to become more effective by shifting their composition to solve these problems. That is purposeful. And, if they are empowered to be in charge of their own composition, they are in an organization in which they can do this - maybe a helpful leader told them that it’s OK to own their team composition. Or maybe, a strong leader within the team convinced the leadership that this makes sense, and so they go about it. Normalizing team change “by the team for the team” to solve problems is something that leaders can do.

Now when people outside the team, or larger structure like a department or company for that matter, decide to reorg hundreds of people, yes, that is also dynamic reteaming. It is a specific kind of “tectonic” team change. Doing anything like that takes an extreme amount of planning and preparation. There are things you can do before, during and after reorgs to help facilitate them. The biggest thing I would love to see at companies is leadership teams gathering feedback and reflecting on their reorgs after they happen, so that they can develop the ability to do them better. This is a muscle to build. I really feel like reorgs are inevitable. We need to get better at them and put the people first. There are activities in my second edition about this topic. You can’t just shuffle all of the teams, and snap people in place. You’re dealing with humans. There is transition time after you have structural changes. Mastering how to do this is extremely difficult and I believe can be attained, if people care enough and put in the work to do it.

InfoQ: When should organisations consider having less stable teams, and are there circumstances in which stable teams are preferred?

Helfand: If you find that you have situations where one person or one team is the only one that holds that knowledge and you know you’d have a tremendously difficult time if they left, you need to devise a reteaming strategy so that when they leave (because they will), you’ll have prepared for it. No one stays at companies forever. We need to be strategic and plan for peoples’ exits. We need to build in knowledge redundancy. It’s why I love pair programming and mob programming because this idea is built in. But we can go beyond that.

Cross team switching to spread knowledge helps here too. If you want to integrate switching for knowledge sharing in your company, you can start at a cadence like every 3 months, and then have retrospectives along with that to see if that rate of switching is working for you, or whether you want it to be more or less frequent. The last chapter of my book talks about generating your reteaming by having retrospectives on it. Experiment and learn. Hunter Industries did that. There is a story in my book about how they had a lot of dynamic switching, it became too fast, and after reflecting on the situation, they slowed it down. There is no one size fits all prescription for the rate of dynamic reteaming. Find your cadence through experimentation and reflection.

InfoQ: What are some of the triggers/patterns that indicate reteaming may be needed?

Helfand: There are at least five triggers, which relate to the 5 patterns of dynamic reteaming.

  • First is the deliberate growth or shrinking of your company, such as when a person joins or leaves your company. Many of us are used to this, and onboard and offboard people without thinking about it as even reteaming.
  • Second, when you have an influx of people, like when you acquire another company - what I call the merging pattern, there are natural consequences to this. You need to determine whether to blend the people in or keep them separate.
  • Third, maybe due to all this growth you feel like your particular team is working on too many different things which makes standup take forever, or you can’t make decisions as easily anymore because you have 15 people in your team instead of 8, you might apply the Grow and Split pattern and split into two or three teams.
  • Fourth, maybe you are in an existing enterprise, and you desire to start a new product offering, you can apply the Isolation pattern and form a team off to the side, give them process freedom and empower them to build something new.
  • Fifth, maybe you have people in your teams that are really ready for a change. They’ve been on “that team” for what seems like forever to them. They’re stagnating. They’re bored. Or maybe they’re so sick of working with those teammates. If you want to retain them, you need to check in on their engagement. Reteaming might be just what they need.

Dynamic reteaming is really about when you have all these different types of team changes going on in different parts of your organization at once. There are changes at the person level, team level, team of teams level, department level and company level. And now we are experiencing changes in teams influenced by a more “global” COVID-19 level - some companies are really struggling so you see people - sometimes hundreds- have been told to leave. Some other companies, due to their industries and how they serve remote working for example, are growing.

InfoQ: How does the idea of reteaming fit with concepts of team self-selection?

Helfand: Dynamic reteaming is “team change”. It’s about forming teams, switching teams and changing teams and other team-like structures across your organization. In general, people arrive onto teams in a variety of ways. Maybe they are hired into a particular team from the start. Maybe their manager gets their input and changes their team assignment. Or maybe someone else “higher up” reorgs them into another team. I’ve seen all these examples play out in my 20+ years of software development. Self selection is a different way to get people on teams. It’s a way to orchestrate, out in the open, who gets assigned to each team by providing the people with opportunities and choice.

In a self-selection marketplace, people like product managers and engineering leads describe the missions of the teams that they are forming, and through a highly facilitated event, team members are encouraged to share their team preferences, and ultimately have a more public “say” into the team that they join. Sandi Mamoli and David Mole wrote a wonderful book about how to run a self selection event called Creating Great Teams. In Dynamic Reteaming, Second Edition, Chris Smith from Redgate Software shares how his company goes about self selection step by step.

InfoQ: Given the recent shift to remote working as a result of COVID-19, how do remote teams retain their shared context and does this have any impact on reteaming?

Helfand: The world has changed tremendously due to COVID-19. People are sick and dying. There is a great deal of fear and uncertainty. The economic fallout from this global pandemic is palpable. Layoffs have ensued. Reorgs have resulted. Some companies are morphing and shifting in order to survive. No one wanted this, and we are forced to adapt. It’s a really, really challenging time like many of us have never imagined.

In terms of remote teams retaining shared context, let’s say your company was already quite distributed pre-COVID-19. Maybe you have offices in different locations and are used to having online meetings with screen sharing. What you probably have noticed is that now you can hear and see people better than when clusters of people were connected together via different conference rooms. You share context using screen sharing, like you did before. But you don’t have the chance meetings in the hallways. Everything is more abstracted and you need to work harder at social interaction. Maybe you get exposed to new tools to help make your collaboration more interactive and personalized, like using breakout rooms that enable pair and small group discussions via your online meeting tool. That probably helps to increase the human connection and aids in sharing context, but too much of it can get annoying. The more we interact in our online spaces, the more we figure out a rhythm and our preferences for working in them and finding ways to share context that makes sense to us.

For those who relied on physical wallboards for tracking their work, had co-located and co-seated teams, the transition I’m sure has been more pronounced and challenging. It’s almost as if it’s been a greater strategic advantage to have been distributed before the onset of COVID-19.

In terms of the impact of remote working on reteaming, it depends on the context and scale. Imagine that in this new remote working environment, the only change you have is someone switching to your team from another team at your company. Assuming that person has a decent work from home setup already, you just need to help them connect in, and add them to your chat, email, recurring meetings and the like. Then you onboard them to your team and help them build a sense of belonging. We just added someone who was on another team over to our team recently at my job, and it was pretty low overhead. Since this person was already at the company but just changing teams, we were able to focus on relationship building and sharing the context of our current work initiatives. We did some team calibration activities that I write about in Dynamic Reteaming, Second Edition. There I include step-by-step activities for how to launch new teams, even if distributed, to get them off and running.

When someone leaves your team, and you didn’t want that to happen, there is not only the figuring out of what they were working on and how you can carry that on, but also the emotional loss of not having that team member around anymore. And, when this happens across, let’s say 50+ teams at once, the whole climate becomes challenging and people are typically sent into a swirl of emotion, disorientation and uncertainty. This is layoff territory and it’s not easy whether you are in person or remote. People that remain at the company will adapt over to the “new beginning” at different rates. It’s imperative to offer one on one and group coaching to the people transitioning through the changes. Being able to talk about the transition helps us process and understand what is happening so that we can figure out our place in the “new beginning.” Once we get to that place, we calibrate and move on, helping our company pull it together and succeed. Then ideally, we reflect and learn from what happened and don’t just move on without talking about it.

About the Book Author

Heidi Helfand is author of the book Dynamic Reteaming. She coaches software development teams using practical, people-focused techniques, with the goal of building resilient organizations as they double and triple in size. Heidi is currently Director of R&D Excellence at Procore Technologies. She draws on her vast experience from coaching there, as well as at AppFolio and Citrix Online, where Heidi was on the original development team that invented GoToMeeting and GoToWebinar. Heidi is based in Southern California.

Rate this Article

Adoption
Style

BT