#149 - Dynamic Reteaming: The Art and Wisdom of Changing Teams - Heidi Helfand

[00:01:16] Episode Introduction

Henry Suryawirawan: Hey, what’s up, my listeners. Welcome back to the Tech Lead Journal podcast, the podcast where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If this is your first time listening, don’t forget to subscribe on your favorite podcast app. You can also subscribe to Tech Lead Journal contents on various social media on LinkedIn, Twitter, and Instagram. And for video contents, subscribe on YouTube and TikTok. And if you have been enjoying Tech Lead Journal, support my look by either buying me a coffee at techleadjournal.dev/tip or becoming a patron at techleadjournal.dev/patron.

My guest for today’s episode is Heidi Helfand. Heidi is the author of “Dynamic Reteaming”. In this episode, we discussed dynamic reteaming concept or team changes in simple words. Heidi explained how her experience working in various startups and scale-ups led to her coming up with the dynamic reteaming idea. She also explained how dynamic reteaming differs from the common advice of having long-lived teams. We then discussed the five patterns of dynamic reteaming as outlined by Heidi in her book, such as one by one, grow and split, and isolation. Our discussion also covered various other topics, such as onboarding, offboarding, maintaining company culture, ideal team size, and leadership role in dynamic teams.

I hope you enjoy listening to this episode and learn some new perspectives on team changes and how we can approach it better. And if you benefit from this episode, I would like to request that you share this episode with your colleagues, your friends, and communities, and leave a five-star rating and review on Apple Podcasts and Spotify. It will help me a lot in getting more people discover and listen to this podcast. And I really appreciate it. Without further ado, let’s go to my conversation with Heidi.

[00:03:17] Introduction

Henry Suryawirawan: Hello. Welcome back to the new episode of the Tech Lead Journal podcast. So we have Heidi here. Really excited to have you here. We’re going to talk a lot about dynamic reteaming and how we can do better in terms of team changes. So welcome to the show, Heidi.

Heidi Helfand: Thanks, Henry. Happy to be here.

[00:03:34] Career Journey

Henry Suryawirawan: So Heidi, I always love to ask my guests to first share about maybe their career journey, any highlights or turning points that you think are interesting for us to learn from.

Heidi Helfand: Yeah, I’ll start by saying that I’m actually a career changer. I’m trained as a teacher of linguistics, English as a second language. So in my early career, I spent teaching English at different universities in the US. So I would teach foreign students who were studying in the US, and just really very much into language. And I had an unexpected career change into software when I used a very early version of screen sharing software. And I was using it with my students and they were learning different English skills by learning about new technologies. So we were experimenting with technology and reading, writing, and speaking about it. And we learned about this technology that, at which you could see and control someone’s computer remotely. And I was floored by this technology. I thought it was amazing and really going to change the world.

These days we have, you know, things like Zoom or whatever, but I was on the original team we built GoToMeeting and GoToWebinar. So I was at that startup when it was very small. There were 15 people and I just, on a whim, sent an email to them and they were looking for a writer. So they saw me with all the English teaching skills that I had and they brought me in as a writer. And then I became an interaction designer, technical project manager, and so forth. So my career took a complete turn in the early days and then I just continued in software for many years as a TPM and a coach and the Engineering Director, VP of Engineering. I’ve worn a lot of different hats through the years. So yeah, now I’m a consultant with Artium. And yeah, we help teams get better at what they do, and build software, etc.

Henry Suryawirawan: It’s really interesting the journey that you had, right? So you started from the non tech background and suddenly, you know, you had an opportunity. And I think you pursued it all the way, right now, become VP of Engineering, SVP, and all that. So I think that’s really inspiring for people to learn from.

Heidi Helfand: Yeah, I don’t think you can plan all this stuff out. I certainly did not envision this as my career. And I actually turned my back on the teaching aspect of myself for many years. Because I was like, I switched into this high tech startup, the software, it was the dot com time. It was like 1999 and there, you know, I went from one fast growing startup to the next. And I really turned my back on the fact that I’m a teacher and a facilitator by training. And also the writing and the English part of it, I’m a writer. And it took me many years to kind of go back and acknowledge that those are key strengths that I bring and we need to communicate and collaborate together as we’re building software. And so it took me a number of years to kind of mesh together that experience and really recognize it.

[00:08:30] How Dynamic Reteaming Idea Came About

Henry Suryawirawan: Right. And I think, you went through a lot of startups and you went through a lot of journeys, up and downs, I believe. And probably that’s why also where you learned about this dynamic redeeming, right. So maybe if you can give us a little bit of background. How did you come up with this idea of dynamic reteaming. What did you see as a problem back then? And what did you learn maybe out of those?

Heidi Helfand: Yeah, so it’s interesting because I had a pattern of going to different startups that grew larger. So the first one where we built GoToMeeting and GoToWebinar, I was the 15th employee and I left when there were around I think 800. Went to the second startup and I joined as the 10th team member and I left when there were 900. The third one, I joined a little bit later. I think there were 800. I left when there were 3,000 and so on. And so, I experienced a lot of, it’s almost like greenfield software development, but the organizational version. We were building these organizations and people as we were building the first versions of these software products.

But I always, like, found myself in this space of leading enabling teams. How can we get better at what we do? How can we deliver on time or have matched, better matched expectations of when our work was going to be done? And anyway you always have to deliver and you have to meet your commitments. There’s a lot of stress. But then there’s a lot of changes going on when you’re doubling, tripling in size. And I read a lot. You can see all these books over here. And a lot of the traditional wisdom that I would read about teams said things like the best teams are the ones that stay stable or the same. And there’s almost this, and even in like early literature from Scrum, for example, everybody is like, you need long-lived stable teams and all of this.

And I look back at, for example, the second startup I was at. I was on the first team, and I left when there were 25 teams. And so we had influx of people and the teams would adjust and do their own kind of reorgs as necessary. We had a lot of that change. And I don’t see, like it wasn’t helpful to us in our journey of startup scaleup to rely on this traditional wisdom of teams, because we weren’t doing it wrong. I have the fortunate history of being part of successful software companies. I’ve been part of two startups that IPO’d, one, the first one got acquired. But these are very, you know, we were able to build products that people would buy and pay for and that they’re on the open market. You know, so I’m really proud of that journey.

And so I, after a while, I was kind of like, well, is it just us? And I got curious and I interviewed people around the world and came up with five patterns that I wrote about in the book, Dynamic Reteaming. And the five patterns are what people will likely encounter in fast changing organizations as they’re scaling up, sometimes they scale down. And so it really is a descriptive piece on what to expect at a fast changing software organization. So yeah, kind of a long answer there, but, yeah. I’m a practitioner, I write about what has happened. And I’m grateful that I’ve been able to interview a lot of worldwide colleagues about their experiences, too, because it wasn’t just a Southern California thing where I’m located. The fact is, team change is inevitable. So, let’s get better at that. Let’s lean into it. So that’s what the book’s about.

[00:12:08] Dynamic Reteaming

Henry Suryawirawan: First of all, let’s try to define what do you mean by dynamic reteaming in the first place, right? Because maybe some people may have heard this term the first time, although your book has been written since 2019, right? The first edition. So maybe you can give us a definition, what is dynamic reteaming?

Heidi Helfand: Yeah, so dynamic reteaming is when, like an easy definition is team change. The fact is your teams will change. And you might experience this on different levels, like in your individual team, or in the team of teams, or in the company. And when it’s happening at all these different levels and you notice it, I describe that as a dynamic reteaming. It could be even, like, the changes in one team, and it just changes the social dynamic, the team dynamic. So there’s this notion of a team dynamic or a team system, the unique combination of people that are together form a team entity. This is from Organizational Relationship Systems Coaching, ORSC. And so that team entity is different when someone comes and somebody goes from the team. And so there’s something about the social dynamic of how we work together. So that’s kind of like more on the dynamic part.

And the reteaming is really just this. It happens in five ways in the book. And I think these are base patterns for how teams will change. So it’s about social dynamic and it’s about the structural changes in teams. But even something that’s one person leaving or one person joining can feel really huge to the social dynamic of a team. And it can be a really big deal even if it seems like it maybe isn’t. So there’s a lot to cover in that space.

[00:13:51] Social Dynamics

Henry Suryawirawan: You mentioned social dynamics, and I saw in your book, you also mentioned about this a few times, right? Could you probably elaborate a little bit more? What do you mean by this social dynamics and system? Are you referring to the socio technical part in, you know, some other literature is referring to? Maybe, uh, what do you mean by team dynamics and social dynamics within the team?

Heidi Helfand: Yeah. I think after my book was published that the term sociotechnical, maybe it had been written about in earlier years. I was not familiar with that literature. I’ve noticed that term kind of emerged on the scene in later days. I don’t refer to that term in my book. So, what I mean by social dynamic is, it’s really about how the people interact together and which people are together on a team. I think each team has the potential for really great chemistry, depending on who’s together as a team.

I think, you know, a lot of my writing about team dynamic comes from this training as in organizational relationship systems coaching, coaching teams as entities, because if you think of the individual people in a team, we all bring our own personalities, our differences. Everything unique about us. And so we can come together with other humans to create something of value. That’s what we try to do in our software teams. We want to delight the customers in our business and everything and build something valuable together. And there’s something that is quite special when humans come together.

And sometimes it can feel like a musical band coming together and it flows and there’s all this music. And at other times, it can be quite challenging working with other people. And the collection of people that are together on a team, it might not go so well. And I’ve always been very curious about that, because I think it’s really out of the bounds of my understanding. And sometimes I think we get lucky. Like, if you look back in your career. And imagine some of the amazing teams that you were a part of. Sometimes it’s even hard to explain what made it so wonderful. And I think it has to do with that combination of people.

And, you know, we can get into other things like, well, who gets to decide who goes on teams? In part of the book, there’s a, it’s almost like a continuum with where you have more choice or freedom in that decision or less choice. I mean, sometimes we’re just assigned to teams. Other times, maybe the opposite end of the spectrum, we go and we form our teams. And then there’s different gradations in between. Does that have anything to do with the success of the team? Maybe. Maybe not. We can turn to ask the Harvard researchers about that.

But yeah, when we do encounter that team system and everything’s easy and we’re delighting the customer and we’re matching our expectations on delivery, it’s an enjoyable experience. We’re proud of what we did, we’re celebrating. There’s something quite special about that and that’s what I try to help cultivate in teams.

It’s not to say that we shouldn’t have any conflict, because conflict is normal on teams. Sometimes you get new things out of the discussions where we don’t all agree, so we don’t all have to agree. But we got to get through that kind of grown zone of conflict, disagreement, of sometimes things need to kind of like give it time and then we’ll converge to a decision later.

And so there’s a lot of tactics in my book about helping teams excel through a lot of these human challenges. And I think they really, you know, we’re dealing with technical systems, we’re building things. But a lot of the times how we work together is worth investing in, because I think we can shape the results by coaching.

Henry Suryawirawan: I think it’s always interesting when you see a high performing team, right, or the team that just thrives together. So you can see it when you see it, I guess, right? So I think not all teams are high performing as well. I think the combination of individuals that you mentioned, right? Maybe the characters as well. Maybe there’s a diva programmer, right? There’s also people who love to serve other people. So I think all these play a big part in the dynamics of the team.

[00:18:14] Dynamic Reteaming vs Long-Lived

Henry Suryawirawan: But I want to come back to the thing that you said, right? The common belief that people have about teams. So many literatures, like you said, right? We should build a long-lived teams, product team, right, not a project team. A team that understand the domain inside out, right, after working on it for quite some time versus this concept of dynamic reteaming and have frequent changes. So maybe if you can come back, what do you think are some of the benefits of having these frequent changes versus, you know, the assumed belief of, you know, long-lived the product team working together.

Heidi Helfand: Yeah, you know, it’s interesting because I’m working on another book. And I work on it every morning at the very early hours of the morning. I wake up, I have my coffee, I start writing. The book is called Context Switch. It’s on LeanPub. But anyway, one of the things I’ve been writing about the last few days is experiences at the first and second startup that I was at.

Because at the first startup that I was at, we worked in component teams. And it related to what we were building, we were building the screen sharing software and the architecture had these COM servers, these endpoints, these web brokers, all this stuff. And we were in these component teams. I became a technical project manager at one point. And so as we grew, we kind of like filled in these component teams. And then project managers like myself, we would manage the development. Like, let’s say of one of these products. And people would be on multiple teams from the components. We were like form these teams out of people that were working in these different component groups, right?

So, we’d reteam like that. And I write about it as an anti-pattern in dynamic reteaming called the percentage anti-pattern. What resulted is, one person that had knowledge of this web server might be assigned to like four different project teams. And it was like, became such a time management challenge that like, oh, you’re 10% here, 20% here, 30% here, like sometimes the numbers didn’t even add up. And it was like the people were reteaming for the project. So, that was very challenging and there were other things about the way that we worked that were really challenging. But it was interesting because like the people were in these long-lived component teams and then they reteamed according to project.

So the second startup that I joined was almost like a do-over from the first startup. And one of the co-founders of the first startup started the second startup, which is called AppFolio. It’s a public company. They make software for property management companies, law firms, other investment products as well. And I was the 10th employee there. In our first engineering team, we wanted to work differently. We didn’t want to copy this kind of component based project management style that we did at the first team.

But for the second ones, we were one team. It grew big, it split. I write about it a lot in Dynamic Reteaming. I was there from one team to 25 and what we were building there is teams with full stack generalists with collective code ownership. We were doing a lot of test driven development, extreme programming. And we had consultants that were in our team helping shift our mindset. So the developers that came over from the first to the second startup were used to coding alone and working in different ways.

And so anyway, we had consultants that joined our team. We paired, we switched pairs, did continuous integration, had better feedback loops. And what resulted were teams that, they could have worked on anything. In fact, the teams named themselves after nerdy band name combination like Hex Pistols, Deflapper, Ace of Rebase. And so they were like these cross functional teams of people that were together, and then the work would get assigned to them.

So in the first case with the component teams, those people reteaming fast according to project, and it was problematic. But with these teams, they were like, these teams were together, but the thing was, we morphed from one team to 25 teams. So people joined the team. People left the teams. They grew and they split. Sometimes they merged together, sometimes people would switch from team to team. Essentially the five patterns of dynamic reteaming kind of played out in that growth. But we still had to deliver the whole time. And so I think these two cases are interesting, because in one, is a reteaming that I wouldn’t really want to copy that again.

In the second case, it was almost like the work was coming to the teams. And then the teams were more general. They were a bunch of web focused teams, later built, had some other variety. And I think, you know, years as the tooling universe and everything front end, everything became more complicated. I’m not suggesting have full stack generalists today, or that that’s attainable. But it’s what we did. And so we had these teams. And after a while, too, work would come to them, but then there was a pull system for work as well, where they could pull work to themselves. And so there’s something about that, that I think is quite interesting.

And it’s a space that I’m writing about right now. And it’s like, you know, not all change is good. Some of it is, especially when you are catalyzing it and you have a say in it. This was very clear scale up, startup scale up. In this other case, there were some other things going on. But still, in the end, they all built software that customers loved but the experiences were quite different.

Henry Suryawirawan: So I think, yeah, the key thing for people to learn from your sharing just now is that not all reteaming works or successfully work, right. It’s because there are maybe patterns and anti-patterns that you should avoid. And I think one of the things that I also learned by looking at your book is that, there’s this quote that “if the team stays stagnant, you also stay stagnant together as a team”, because you don’t learn new things, or maybe you just habitually, you know, do the same stuff all over again, right?

Heidi Helfand: Yeah. Yeah. And one of the interviewees said that exactly as a quote. And that person that said that quote, I remember. We were in one team and the team grew bigger, we got to be about 13 or 14 people. And then we split into two teams, and then three teams. And there was a feeling of loss for some of the engineers after a while, because they were used to this first team pairing and switching pairs. And then when the team split, it was this human challenge of, wait a minute, I don’t get to pair with my friend anymore. Um, like why? And then they started regular switching patterns so they could have pairing variety.

And I thought it was really cool, because it met a learning goal of I want to learn from this person. It met a human goal of, sure, I’ll see them in the office and, you know, we take breaks together or go to lunch, but we’re thought partners when we pair. And you split us, you know, you split us in half. And so there’s some very human reasons for reteaming that I write about when I talk about the switching pattern a lot. I mean, it was awesome over the years because of all the pairing and switching pairs and all of that. There’s a lot of knowledge spread. It’s not one owner for a system and then they leave and then you have challenges. So there’s like some good kind of, you know, redundancy there.

But then there’s stories of love and loss in the book. You know, sometimes people leave. You’re happy for them. They have a great new opportunity. But you don’t get to work with them day to day anymore. So that can make us sad. So, you know, there’s a lot, I think in this space. And when you have an amazing team system together, really appreciate it. Take the time to tell people that you care and that you like working with them because nothing really lasts forever, so you have to enjoy it.

Henry Suryawirawan: Yeah. And especially in this disruptive time, right, where, you know, opportunities are in abundance. Crisis are also in abundance sometimes, right? So I think team will change no matter what.

[00:26:19] One by One

Henry Suryawirawan: So maybe this is also a good segue to go into your five patterns of dynamic reteaming. I think the first one is called One by One, right? I think for some people it’s pretty common in all the teams they are in, right? It’s like adding new people in or some people leaving, right? Is there anything special about this pattern one by one that we can learn from you?

Heidi Helfand: Yeah, so with the one by one pattern, it’s really the space of onboarding. And so when someone joins your team, you’re trying to teach them about your company, your code base, how you like working as a team and all of that. One thing to learn and keep in mind is that the new person joining also brings their uniqueness. So encourage them to share about themselves. There’s research that’s written about in the book Culture Code by Daniel Coyle. He cites some research that talks about how you’ll retain people longer when people share about themselves. So, it’s not just indoctrinating them about the company and your ways of working, but see what you can learn by encouraging them to share about themselves. So, that’s, I think, one thing that people might not always think about.

Henry Suryawirawan: Right. So I think that’s very interesting, right? Instead of just sharing about company or, you know, this is your project, this is your product, and this is all the that you need to learn, so also ask them, invite them to share about themselves.

[00:27:42] Onboarding New Joiners

Henry Suryawirawan: Anything that you should ask for that person to share about? Is it about their background or is it about something else? What do you think are interesting for new joiners to share with the team?

Heidi Helfand: Yeah, so, when somebody joins your team, it’s a good chance to do some short activities where people can share what they are comfortable sharing about themselves. There’s an activity in my book called marketive skills, which I learned from a wonderful coach, Lyssa Adkins. And in that activity, you can do it in an hour and you can do it remotely or you can do it in person. People make a poster or a card about themselves to share. These are the skills that I can bring to the team. These are some of the interests that I have outside of work. This is what I want to learn in the next few months and this is what I offer to teach you.

And it’s kind of cool to hear what people bring to an activity like this, because they don’t have to get too personal or anything. It’s just like, well, what do you like to do outside of work? Some people like to cook, they like to hike, they like to do sports, whatever it is, they can choose what they share. So it’s nice when everyone is doing that and you kind of create a space for it.

I think also another way that you can draw out a new joiner to your company is, as you’re having meetings and doing other things, you can encourage them maybe outside of the meeting, like, we really want to hear your opinion, like, don’t hesitate if you have an idea or suggestion. You know, maybe say that to the person outside of the meeting. Some people don’t mind if you ask them in the meeting, oh, hey, what do you think? Like I don’t mind that, but I think for some it could feel like maybe it’s a little bit scary if they’re new. So, you know, communicating with people outside of meeting and asking about their preferences can be very helpful.

And really, I think the other really important thing when someone new joins is to think about this notion from John Gottman’s research on relationships about turning towards, turning away or turning against. And just the idea of if somebody reaches out to you, maybe they send a message, answer them. If you don’t answer them, especially if they’re new, they might feel like they’re being ignored or that you’re turning away from them. And they might not feel so welcome. When someone’s new, you want to over index on helping people feel like they belong or like welcoming them. So when they make a bid or when they make an effort to communicate, you want to communicate back.

And I don’t care if you’re busy. We’re all busy. I don’t care if you’ve got too many things on your plate. Take the time to pay extra attention to the new joiner and help them feel included. It’s hard when you’re new and you get a confidence dip. And so I write about this in my book Context Switch. But we want to help provide like an extra supportive environment for them.

Henry Suryawirawan: Right. Thanks for some great, interesting tips. I think the marketive skills is something that I think some teams, you can experiment and do this, right? So that you can welcome the new joiners better.

[00:30:54] People Leaving

Henry Suryawirawan: So what about if people leaving, right? So this is also common. And especially these days, there’s this massive layoff sometimes happening as well. So anything that interesting for us to learn from as well?

Heidi Helfand: Yeah. And so there’s activities in the book related to this. So, there’s a special care that you need to take when people leave a team. It can be very challenging. Sometimes people leave and you don’t know why and you find out after the fact. The company wants to respect their privacy. And there are things that we just need to accept. Even if we don’t like that it happened and it’s a wonderful thing to talk to your manager about as your closest person to give you advice. I always recommend people talk to their managers. On teams, sometimes people leave. Maybe they get another job or another opportunity. And it’s also a time, when they leave for whatever reason, to talk as a team about what did they do in their role, kind of beyond their role, that you want to continue on.

And I like to tell a story about this with a product manager that I worked with at the third startup. Product manager left. He had a new opportunity. We were happy for him, but sad that he was leaving. One of the things that he did was when the team accomplished a goal, they would go out by the ocean and they would scream like on the side of a cliff. This company, it was Procore, had an office in California on an ocean cliff. I mean, it was beautiful. And so they would do that ritual and he would always get them out there and they would celebrate. And so after he left, I was with the team and I said, okay, what did he do beyond his job description that you want to carry forth? And that was one of the things that they put on their list.

It could be that maybe the person that leaves used to bring sweets on a certain day of the week, or maybe they were always the one who right before you were going to deliver something important, they were the ones that kept it together for you and your team. So maybe you want to do something related to that. But like really acknowledging and celebrating what people do outside their role that you want to carry forth is one way to cope with people leaving.

I also recommend a book, Managing Transitions by William Bridges. It’s not about software, but it’s about life transitions. So you have an ending. For example, the person left. Or it could be like an even more challenging situation, a layoff situation. So you have an ending, a neutral zone, and a new beginning, the future. So you have to acknowledge the ending and ideally have a forum to talk about what happened so people can ask questions. These need to be one on one and addressed as a group or as a team. It takes a while for people to get to the future state or the new beginning state after a tremendous change like that.

And so William Bridges calls it like the neutral zone. It’s almost a liminal state. People might experience a lot of fear. They’re worried. Am I gonna lose my job? They might feel like distracted. They’re awake at night. They can’t believe what’s happening and didn’t imagine it happening. They’re surprised and shocked. And all of this, this is where a lot of attention and support can come into play. When leaders have open door sessions or the manager encourages you to talk to them. People can support each other, but there’s this kind of like period of uneasiness.

Then there’s that future state, like the new beginning, the future. So there are things that you can do to turn towards that future state. But the fact is people are going to traverse across that liminal time, that uncertain time at different rates. Some people will be in the future state. They’ve moved on. They’re ready to roll. Whatever it is, they’re like there. Other people, it might take them a lot longer. And the fact is, in your teams, or teams of teams, all of this is invisible. It’s not like everybody’s talking about, oh, I’m over here, I’m here, and I’m here. So I think, you know, it’s a time for having extra empathy to help people, you know, to coach them through the change. And it can be really, really hard. It takes a long time for some people. Some people will leave, some people won’t. Different opportunity is created sometimes when this happens as well. There’s like a lot of different facets of it.

But I really like anchoring to that model by William Bridges, and I really recommend his book to people when they’ve experienced something like that. Maybe they were laid off or they were the ones that weren’t laid off, and they are witnessing this happen. That is also, you know, it’s heavy to bear in a different way. I have a lot of empathy for it. And people that are going through that, once they get to that place where they can look back on their experience, you know, they will have perspective. But it’s hard when you’re in the middle of it. It’s really, really hard. So we need to help each other.

Henry Suryawirawan: Thanks for sharing this concept, you know, managing the transitions, right? I think some people may have gone through these difficult situations. Not only for the people who got laid off like you said, but the people who stayed behind as well, right? So there will be a lot of emotions I’m sure that went through their head and mind.

Heidi Helfand: There’s a lot of kind of mirroring with the reteaming stuff, because you can imagine a person leaves, but then there’s all the other people that are there that are going through it. It’s the same thing when someone joins. So you have a newcomer joining the team and we pay attention to them. But then you also have the team that is already there. They’re going through changes as all these new people are joining. Do you see that kind of mirroring? So we need to pay attention to all these four groups of people. And it’s an interesting kind of mirroring aspect.

But, you know, when a lot of people join, people usually get into the, oh my gosh, the company feels different. How do we maintain our culture? That’s one thing that people talk about. It feels so different now. We used to be 10 people, and now we’re 30. It feels like a different company. Then you get to a hundred and then there’s all this process and that feels a lot different than it did when you were 10. 10 people. So those people need help and like support as well.

[00:37:18] Maintaining Culture

Henry Suryawirawan: Yeah, you mentioned about maintaining culture, right? So what is your tips, you know, with all this dynamic reteaming, right? Because as when people come in and go, right, especially if you’re in a startup or scale up, definitely your culture will change. So what is your thought about, you know, maintaining this culture?

Heidi Helfand: Yeah. Yeah. So it’s interesting, like being part of early startups and being present as things doubled, tripled, whatever from 10 to 900. I mean, that’s a lot of change. It helps to have… So company values are one thing, department values, engineering values. We have individual values. So like, these are things we believe in for ourselves, for our teams, for our companies. Sometimes company values can be very powerful and they can withstand the test of time.

For example, Procore Technologies, they build software for construction. They are the ones I was talking about up Carpentry, California on an ocean cliffs. Very successful company. And I had the privilege of working there for, I was there for like four years. I was consulting there before I joined. And I was like one coach for 50 teams. So when I was consulting, some of the engineers started talking about the values, like they were actually using them. And the values are ownership, openness, and optimism. They’re three words. They called them the three O’s.

So some people would say, like, in the spirit of ownership, I’m going to run with that. I’ll let you know how it goes. Or people would say things like, we need to bring more openness to this situation. Let’s talk about it. Or then optimism. Like, what’s the other view of this? Like, if it was a decision that, you know, maybe you didn’t like so much, what’s the optimistic side of this? What’s the silver lining? And there’s other examples, but those were values that are useful. So they were useful when the company was very small and they created them. I wasn’t there at that time. They were useful when we were 800 people, when I was there. 800 to 3,000 or whatever. Today, they still have those values. They write about them publicly on their blogs.

I think sometimes values can be like glue over time. Symbols also. At Folio, we took a very early whitewater rafting trip, the early company. And we had this rafting oar. I have a little one over there, but the paddle, when you would go whitewater rafting, that thing became a symbol. We used to sign those when we’d accomplished different milestones over the years. And the little one I was looking for, when the company went public, we all got these little commemorative oars. And so from a very early small team, we had the rafting oar that we signed with a sharpie, all of our names. When we did our first release, we signed it. And all these years later, you can walk in their building, you see these oars on the wall. So it’s like another kind of symbol. It’s kind of like we’re working together. We’re going the same direction, like all of that stuff.

And also traditions are helpful. That company would take annual retreats, for example, with the product and engineering teams. They continue that to this day. They take some time in the summer and they do some kind of overnight trip or day long trip.

So, traditions, symbols, values, those kinds of things help. But yeah, I mean, you know, it does feel different as all these things change. And they will. So, I think just acknowledging and again, celebrating when you have an amazing team situation. You know, let people know how you feel.

Henry Suryawirawan: So I think it makes sense, right? Again, coming back to the social dynamics, when you add or when you combine different people together, definitely you’ll see a different cultural thing, right? But always goes back to, you know, your values or your traditions and symbols, right? All these things can anchor you back to what, you know, your identity, so to speak, right? Your company identity or your team identity.

Heidi Helfand: Yeah, and I think naming is important in that, right? Like, I remember there was one team at Apfolio, it was a team called the FU Fighters, right. F-U Fighters, Fu, and instead of F-O-O, like that band. And the Fu Fighters were a team; a team entity that the members came and went over many years. And at one point, there was one engineer, and he’s like, wait a minute, I’m the only one left. And then there were other people that joined him in the team, and they decided to retire the name Fu Fighters and give that team entity a fresh new name because he felt it was time. And then he sent an email to kind of retire the name. But I think sometimes when teams change substantially, they get a new name. Or, you know, sometimes your company gets acquired by another company, and then the company name changes. And so that’s one way to kind of restate the new identity.

But again, the people, you know, you got the endings, the neutral zone, and the new beginnings. Not everyone might relate to the fact that you’re now part of this larger entity, because your company was acquired and you have a new name. You might see yourself at the old company with the old name for a while. You know, will you get to that future state or not? Who knows? But it’s a thing. That’s it. I I find all these topics very interesting because, you know, I understand them to a degree. But that’s why you write books, because you want to like dig in and try to understand things better.

[00:42:42] Grow & Split And Merging Patterns

Henry Suryawirawan: Right. So let’s go to the second pattern, right? Grow and split. I think this is also quite common in some companies, especially when they grow, right? So maybe the first question is like, when should we think about splitting? There are a few thoughts and ideas about principles when you split the team. So maybe would love to hear from you from dynamic reteaming concept. When should we split the team?

Heidi Helfand: Yeah. So sometimes our teams grow bigger. And for example, maybe you had a team with like four engineers, a product manager, maybe someone in a quality role and a design role. But then maybe suddenly your company’s in a growth spurt and the team is growing bigger and it feels like you’re not as productive as you used to be. Maybe it takes longer to do things than it did before because you have more people. There’s more communication channels. It could also be that the work becomes unrelated. And you’re in this stand up and people aren’t paying attention to each other anymore. So work becomes unrelated. The meetings get longer. You might get into that situation where you have this larger team and then the meetings become very quiet. There’s a large group and only two people are speaking. Now you can adjust your facilitation so that more voices are heard and more people collaborate and speak, but it doesn’t happen that often. I think facilitation is a skill set that not everyone maybe has or or knows what to do. So sometimes it can creep up on you this like a vine growing on a fence. So it just gets bigger, less productive. And then someone might say, hey, feels like maybe we’d be more productive if we split into two teams. So sometimes it emerges like in a team retrospective.

And the opposite is merging. Not to skip ahead here, but it’s relevant. So when you’re losing a lot of people, sometimes things consolidate and merge together. You know, the grow and split aligns with company growth. The merging aligns sometimes with attrition or losing people or the company’s downsizing. So maybe those teams, they could be bigger, they could be smaller, but people get more work. That could be challenging. They might, if the teams have not paired or switched pairs or shared information, there could be a great learning curve to deal with a new area of responsibility you didn’t have before. Sometimes teams merge together so that they’ll have pair programming variety.

There’s a story in my book from a company in New Zealand called Trade Me. And there was an engineering manager, William Them, who shared a story about the teams merging together. But then they had very tight facilitation. So I think if you read about ideal team size in the industry, people might suggest that you have smaller teams. And that’s fine. That might feel good. You might feel like you get into good iterations like that. But larger teams also work too. If you are organized and you facilitate, that can work as well. It takes a different kind of work. So grow and split and merging are mirror patterns, so to speak.

[00:45:51] Ideal Team Size

Henry Suryawirawan: I’ve read and heard a lot about this ideal team size. You know, some people call it two-pizza teams. Some refers to the Dunbar theory, right? So there’s an ideal number of people forming together. So maybe from your view, just now you mentioned about large team can also work too. What are some of the things that maybe we could learn to make a larger team work? Or maybe do you agree that this ideal team size is something that we should try to adhere to? So maybe your thoughts about this.

Heidi Helfand: Yeah. So, where I’ve seen larger teams work is when the larger teams have some decision making authority for how they organize. So, for example, you could have like 15 people, but they’re given explicit permission, and they’re authorized to organize their work how they see fit. And it can be quite empowering for those who are entrepreneurial or for those who want to discuss and talks amongst themselves about how they might organize to get the work done. It can be quite liberating for people that like to do that.

And you can have a base pattern for how to organize if the people aren’t sure. So you’ll have these like large teams. They have a one backlog of work for all of these people. And then they team and reteam based on priority. I’ve seen that be quite successful. But again, it takes care. It takes coaching. It takes people and leaders, people that are into it and they want to work that way and they want that, like pretty close to that concept of how can we enable self organizing teams. Like, if you have this like team of teams and they organize into smaller units, they drive it from retrospectives. You can get a lot done, and it can feel very good to do that. I think when you have like a four engineer nucleus, like four engineers that pair and switch pairs, maybe someone that has a quality role, designer role, product manager, I’ve seen that kind of pattern work really well.

There’s a lot that, you know, it’s hard these days with frontend engineers, backend engineers, iOS engineers, like how do you organize to handle the multiple platforms? Do they all work on their own and then you have that component team integration problem later? Do they work differently as this team together? But then they’re the only one and it’s hard to pair unless people want to become more general. Like there’s a lot of challenging aspects and whenever you join a company as let’s say you’re a leader and you have some ability to make decisions on how this is going to go. You’re joining a story in progress. It’s either a scale up. It could be a turnaround. It could be, ah, it’s working great, do more of this. And you kind of get there and you help the teams change to accomplish the objectives.

I think there’s a lot that can be done with a small team. I feel like it’s easier, even if it’s, I’ve seen tremendous work by interns working in teams of three and doing incredible things together. If you’re a smaller team and you’re an entrepreneurial kind of mindset. You’re not waiting for someone to tell you the priority. You’re catalyzing this discovery and working forward. You can get a lot done. I think people sometimes, like with the roles on teams, might become a little bit lazy. I’m waiting for what the product manager is going to tell me to do. Like that doesn’t work for me. We all need to kind of work together. There’s issues sometimes with role boundaries. But in general, I think, you know, four people in a team, you can get a lot done. You can get a lot done with a pair. What do you, what do you think?

Henry Suryawirawan: Yeah. So I think from my experience, you know, having seen some growth in the company as well. I think ideal team size probably is about, yeah, five to 10-ish probably. And especially if you’re a manager, right, you can’t be managing maybe more than 10. It just gets so tedious, you know, with all this one-on-ones, relationship, making sure people get equal opportunity in the project, things like that.

So that is my experience though. So that’s why I asked you about this thought, because some people say there’s an ideal team size that we always refer to. Not too big. And then we split, right? But you also mentioned that larger teams can also work if they are self organizing they want to work that way.

Heidi Helfand: Yeah, and I think, you know, level is also important and experience. If you have four people and yeah, they’re all maybe quite experienced. Maybe it’s a different experience than if it’s four people and they’re just out of school. But I wouldn’t underestimate them either. Some people like to have a balance in their teams. If they have career ladders like senior, junior, mid, like they like to try to make the ultimate recipe for teams. But we don’t ever want to underestimate our people that are just getting involved and I think there’s something about people’s motivation and drive that could really make a difference.

So, there’s a lot of dimensions in which we can look at this. We can build a lot in small teams that work fast. So the consultancy I work at Artium, so we’ll partner. It was very similar to when I was at the second startup. And we had engineers come in, consultants from Pivotal Labs, and they helped us learn test driven development, pair programming, they set up the continuous integrations.

We were working with tighter feedback loops. I work for one of those consultants now. So he started a consultancy called Artium out of Southern California. And, you know, we’ll partner with companies. Maybe it’s an enterprise, they want to start a new product. And we can kind of pair with the engineers that are there. Help them level up and build the first product. We can do it all, hire our replacements, like there’s a variety of different ways. But I lived through that method and I know these small teams can do a lot. So it’s pretty cool.

[00:51:43] Isolation Pattern

Henry Suryawirawan: Yeah. Thanks for sharing that. So maybe if we can go through one more pattern which is called isolation. So I think this is also interesting for some people. When do you isolate a team? Like you create a new team and isolate them. Because this, for some people would deem it as an anti-pattern, right? You don’t want to create a silo. But I’d like to hear your thoughts about this.

Heidi Helfand: Yeah, definitely. I think sometimes there are beneficial silos. For example, let’s say you’re at a startup and you don’t have product market fit, and you’re working in a process that is a waterfall process. It’s taking a long time, but that product is failing. It’s almost like an incident response team. If you form a team off to the side, give them process freedom, they can build something new. There’s a story in my book about that when we created GoToMyPC. Because our first product was failing and we were doing this waterfall, they kept doing waterfall with other things later. But the fact that we had this team off to the side working differently, having the permission to not be held back by the bureaucracy that had formed, like, enabled people to go faster.

In an enterprise, you can create a new product line by, early days, I called it innovation by isolation. So, at the second startup I was at where we were building the product management software, for example. But they wanted to catalyze a new product line. And so they invited some engineers to be in this team off to the side. And they were doing a lot of product discovery for this new vertical. And the existing teams were working in Scrum in like two week cycles and that was too slow for them. They needed faster iteration.

So not being part of some team working in a spike or something, and having to go through all the rituals with that team. That would have held them back. But they got to work at a faster cadence because they were doing market validation, they were iterating quickly. They worked in more of a Kanban type style. And doing that as a team off to the side was very helpful. And like our founders at that time told the other people, like, leave them alone. Happened in both cases.

I recently read this book on TeamWork. And McDonald’s, like there’s a story about the development of the Chicken McNugget that at one point the Chicken McNugget was out in some different restaurants and it was failing. And a consultant was brought in and they worked very similar. An isolated team off to the side in a completely different plant, and were able to turn around the Chicken McNugget and, you know, they’re spread around the world now thanks to some of the work they did in that isolated team. It’s a fascinating story. I’m looking over here to see if I can find the book, but I’ll send you the reference for it because it’s a very interesting story. And if you are into it and look on the McDonald’s website, they reference that. They called it a SWAT team, I believe.

Henry Suryawirawan: Right. So thanks for sharing this because some people might thought that isolation is always bad, right? But you mentioned the term innovation by isolation and also thanks for this story about Chicken McNugget. I think, that’s also an interesting one.

[00:54:56] Role of Leader/Manager

Henry Suryawirawan: So Heidi, in all this dynamic reteaming, what’s your view about the role of leadership or the managers of the team, right? Because as the team personnel changes, definitely, there are a lot of things that a leader or manager should take care about. So maybe what are some of your advice for leaders or managers?

Heidi Helfand: Yeah, I always think it’s great for managers to encourage career development of people. Sometimes managers get very protective of their teams and their people. But it could be better for the person to work on another team. So always, as a manager, as other levels of leadership in a company, you have the company entity that you want to be successful. You have your own interests that you want to be successful. But you also have the person. And I think, you know, enabling their learning and growth can help retain them at the company. So don’t hold them in if there’s an opportunity that you think might be better for them, better for the company. I think there’s that.

And I think also, it’s really important for leaders to have patience. If they’re talking about changes that need to happen amongst the teams and managers are off having their private meetings about it, they could be doing this for a long time. And then when they bring it up to the people, it’s new to the people. And so, you know, ideally, you’re including the people in the change decisions, so that they have ownership over it and they’re not finding out right when you’re going to execute on the change. So, you need to have patience to include perspective.

It doesn’t mean that the team members get to make all of the decisions. No. Being clear on who’s making the decisions is also important. Some changes are just going to happen. Other changes, you can give input, but this person is making the decision. And then in some other ways, like we were talking about big teams, maybe they get to decide how they organize and it’s for them to work out. So the changes are going to go down in different ways. For managers, try to include people in giving input. Maybe the changes that you want will be more successful later, because people get to give input.

Henry Suryawirawan: Thank you for the tips for leaders and managers out there. I think, yeah, give your people a chance when there’s an opportunity for them to maybe learn something new. And always be patient. And also, you know, understand who is accountable for some decisions, right. So I think all these are great tips for us leaders who went through a lot of team changes.

So Heidi, it’s been a great talk learning about this concept about teams, you know, team changes and the patterns as well. We don’t have a chance to cover all of them, but I think people can refer to the book, right? There are five patterns. One by one, grow and split, isolation, merging, and switching. So I think you can learn how these best practices or best patterns, so to speak, about changing your team.

[00:57:47] 3 Tech Lead Wisdom

Henry Suryawirawan: So before I let you go, Heidi, I have one last question that I normally ask for all my guests, which is called the three technical leadership wisdom. You can think of it just like an advice that you want us to learn from you. So maybe can you share your version of three technical leadership wisdom.

Heidi Helfand: Yeah, so technical leadership centers around people working together. Encourage people to collaborate, work together, build their relationships. So that would definitely be one of the ideas.

The second idea really anchor to purpose. Why are you there working together for the company entity that you’re a part of? What kind of impact are you trying to make in the world by collaborating with this group of people? And how can you encourage and communicate about this purpose with your team? So think about purpose.

And the third one would be, you want to create a climate where people can feel included and they can bring their best selves to work. And I think it’s that leader’s job to, you know, it’s like you’re cultivating the soil of a garden and you’re taking care and you’re fertilizing it, so that the people can grow and thrive and work together. So like really think of how can you cultivate a better kind of earth and soil to help people be successful. So I think those are the three.

Henry Suryawirawan: Thank you. So Heidi, if people love about this concept, they want to learn more or they want to reach out to you, is there a place where they can find you online?

Heidi Helfand: Yeah, so you can find me on LinkedIn. Heidi Helfand. Or if you google dynamic reteaming I seem to come up. You can also find me, you know, HeidiHelfand@thisisartium.com So talked a little bit about Artium. I have a website Heidi Helfand. All these ways, Mastodon. I’m quite active on Mastodon these days. I don’t know if you’re on there, but I really love that network.

Henry Suryawirawan: Yep. I’ll make sure to put it all in the show notes, right. So thank you again for sharing about this concept, dynamic reteaming, Heidi. So I had a lot of learning today.

Heidi Helfand: Yeah, thanks Henry. I appreciate it.

– End –