Dynamic Teams: Reteaming Patterns & Practices

The Challenges of Reorganizations and the Concept of Whiteboard Reteaming

Charles Humble: Hello, and welcome to this episode of the "GOTO Unscripted." I'm Charles Humble. I'm a freelance techie editor, author, and consultant. And this is the fifth episode in a mini series of podcasts that I'm doing for GOTO, talking to software engineering leaders. I'm aiming for each episode to have actionable insights and suggestions for further research, such as books and papers to read, conference talks to watch, and so on. My guest today is Heidi Heidi Helfand, author of the book, "Dynamic Reteaming." With over 20 years of experience in the tech industry, including roles at AppFolio, Procore, and GoToMeeting, Heidi Helfand has gained a deep understanding of how to help organizations successfully navigate changes and scale their teams. She's particularly passionate about helping companies build great products and high performing teams. And she's interested in the people side of engineering. Heidi Helfand, welcome to the show.

Heidi Helfand: Thanks, Charles. Great to be here.

Charles Humble: It's wonderful to have you on. So I was really excited when I read your book originally, because so much of the advice around teams that I'd read before talked about how you should try and keep your team stable. I'd found that in reality that wasn't really practical. Teams just weren't stable. Was that kind of your experience as well?

Heidi Helfand: I've been a part of several startups that grew and changed from, like, 10 people to thousands of people. And you gotta lean into the change.

Charles Humble: Right. Yes, yes. And early on in this podcast series, I interviewed Elizabeth Hendrickson about reorganizations and the challenges of them. And one of the things that she spoke about was how often reorganizations are done without paying enough attention to what the individuals on the team want. And that you can end up with, you know, people in roles that they likely wouldn't have applied for. And in your book, you talk about whiteboard reteaming, which I found a really compelling idea in this context. Can you talk about that, and this sort of idea of transparency in a reorganization? Because I think in practice, it's not done that often. And it's a really interesting idea, I feel.

Recommended talk: Structures Shape Results: Software Insights • Elisabeth Hendrickson & Charles Humble • GOTO 2024

Heidi Helfand: I've learned and I've experienced that it's really helpful to get the people involved in the future org design and change. When I was writing "Dynamic Reteaming," I was reflecting on different experiences that I had working at different companies. And I interviewed Kristian Lindwall, who is an engineering leader at Spotify. And he told me a story about how they had a... They were calling them tribes at the time. They were like teams of teams that needed to have a change. And the engineering leaders got together, kind of figured out a future design, but brought it to the people in their open area where they would have their fika or like coffee sessions daily. And they worked together with the people in the teams to get the final result. And they learned that some of the things that they had planned maybe needed adjustment based on the input of the people doing the work.

And Kristian, he influenced us a lot. When I was at Procore, we had him come on site and give us a visit. And then later, some timeframe after, when we were needing to expand our teams... Procore makes software for construction. Wonderful company. But when we needed to do a similar activity, we pretty much emulated what he had done. And I write kind of the recipe for this in my book, "Dynamic Reteaming." But we learned as well that even with the best of intentions, if you're not super close to the work, and you try to impose an org change, you could get it wrong. You might not have the best solution. Yeah, so those experiences for me are kind of really eye opening.

Avoiding Analysis Paralysis in Organizational Change

Charles Humble: One danger I can see with it is that you could end up sort of basically going on forever. So do you have any advice on how you avoid just sort of constantly refining and never actually getting to the point of doing it? I guess you can timebox. But any sort of specific advice around that?

Heidi Helfand: That's a really good point. I think with any kind of organizational change, even if a team is growing bigger, and then they realize, hey, you know, maybe we'd be more effective if we split into two or more teams. You can't run through mud and have these things be something that you only talk about and you don't execute on. So I think having timelines and schedules, bringing in a project manager to manage the change, can be a really helpful thing to do. You don't want things to be just a discussion, you want action with it as well. You also want to have a sense of buy in, especially if you're impacting the daily lives of people. So you do need to have patience, and you can't snap people into place. That just doesn't work. People try, but your mileage may vary there.

So I think, you need a deliberate collaborative plan with a start and an end, have a timeline, bring in a program manager, project manager, and really just try to make things happen. We used to do that frequently at AppFolio, another software company where I worked. We'd have checklists of the things that we would need to do when our teams changed, in a variety of ways. And really, like, you know, having a person responsible for the execution of the plan is really important.

The Five Patterns of Reteaming

Charles Humble: Right. Yes. So in the book, you have five patterns for reteaming. So, one by one, grow and split, merging, isolation, and switching. Can you sort of just give a quick walkthrough of what they are?

Heidi Helfand: Sure. So these are like base patterns that people can use on their own or in combination when envisioning different types of transformations. And they are also things that will happen whether or not you try to do these things deliberately. I feel like there are natural patterns about how our organizations evolve. So the first one is one by one. Someone joins your company, someone leaves your company, related to onboarding. So it's the first pattern, one by one. Grow and split, a team grows bigger, maybe you're hiring people, or people switch from another team, it gets bigger in size. And for a variety of reasons. Usually, things take longer, work diverges. It's harder to make decisions. And then the team will split into two or more teams. Merging is the opposite of grow and split. Two or more teams merge together to form a larger team. Or it could be a smaller team if you're in a downsizing situation, and you really just need to combine efforts because you don't need as many teams anymore. That's merging.

Isolation, great for new product development, new ideas, emergencies. Take a team, put the team off to the side, beneficial silo, give that team process freedom, let them do their work, tell the rest of the people in the team to leave them alone. So it's an isolated team by design. And then switching is related to really, like, resilience. You want to have people switch teams to learn something new and to pass on information. So let's say two teams know something more than one team only. So you have, like, a little bit more redundancy. It could be that someone wants to grow their career, and there's an opportunity on another team, they switch to that team. So for the pursuit of career goals. Or fulfillment, or maybe it's just that, you know, we're tired of working with these people, we want to work with different people for like a social reason and a lifestyle reason at work. So we switch to another team. Yeah, so those are the five patterns, one by one, grow and split, merging, isolation, and switching.

Charles Humble: I found the isolation one really interesting, for a couple of reasons. One of which is that, it's another example of kind of going against the grain of common advice. So much of what we do in IT is about, you know, breaking silos down. And here you'll say, actually, they can be quite useful. So can you talk about that maybe in the context of your experience at ExpertCity?

Heidi Helfand: Sure. The ExpertCity story, I love telling that one. So I was at a startup called ExpertCity. I was the 15th employee. And I joined as an editor and also did interaction design. And I was at that company for a long time. The first product that we were building, we wanted to change the world. So we were building this live marketplace, where you could pose a tech support question, and live experts would bid to answer your question using screen sharing. So we developed very early technology in screen sharing, right? And so it was very exciting to be on these teams. I was part of the web development team, and we were visioning out like the future flows, and the features. We were building this, like, really cool product. We had hopes and dreams for it. 

So I'm in my office, we all had individual offices at this time. And I remember our CEO came into my office and he was like, "Heidi, you got to stop working on the marketplace." This is what we called our first product, "Because we're canceling it. As it turns out, nobody's paying for it. We're not making any money. I think we made six bucks last month. And this is going to be no more."

It was very hard for me. I was very early in my career. I think I cried about it. I was like all dramatic. Like, you got to save the marketplace. Like, it was quite a thing. But the thing was we needed to change. We needed to pivot. We needed to do something different. And I was not... I'm IC, it's very early in my career. But one day I find out that I'm invited on this team to build a new product, to build something else. Like, we're not doing this one anymore. We're gonna work on this other one. And I was part of this small team. And we got to do things differently. We organized differently. We didn't have to follow the strict waterfall process that we were doing at the time at the company. We were able to, like, break free and not have pixel perfect mockups. We were able to... We even named the product actually. We named it Easy Remote Control, this product that we were building. We had little icons that developers made. And, you know, we were like, look and feel can come later, we're just gonna get the functionality of this thing down. We worked really, really fast. And we just had this freedom. It was very liberating.

We wound up creating a product called Go To My PC, which was very significant in the trajectory of this company. Which lived on, got acquired by Citrix, got acquired by LogMeIn. Like, the company lived on. And I feel like this ability to work differently... Everyone else was told, like, leave them alone. Like, we got to focus. We got to have faster iteration because we needed it in the early stages of this product. And, you know, I didn't call it isolation back then. I was along for this ride. And I was like part of this experience. And, you know, it really changed things. And then at subsequent startups that I've been at, I've witnessed and noticed this pattern in action as well. And it can save companies. It's a thing for a pivot. It can create new products. It can turn products around. And yeah, a beneficial silo is sometimes useful. Not all the time. You know, a lot of these things are kind of, like, you got a problem you want to solve, what pattern might you apply? So, that's the way I look at it, at least.

Charles Humble: I think it's really interesting. I love that story. And part of the thing I love about it is going through that horrible thing of, this product that you're investing time in has suddenly been killed. Again, it's probably happened to most of us if we've been in IT a while at some stage. It's a very kind of dramatic experience that I think certainly the first time it happens to you, it's quite an unsettling thing. I mean, there are parallels with the kind of skunkworks teams, is an expression I've heard used, which is sort of a fairly similar idea. What conditions do you need to set up... How do you make the isolated team successful, do you think?

Heidi Helfand: It's interesting, because it is not a new idea. Skunkworks is a term, tiger team is a term, like a squad off to the side or a strike team. There's different terminology. And, you know, one of the things that makes these teams successful is direct reporting up the food chain to an executive. So you don't have to go through the regular sort of bureaucracy, especially if you're in an enterprise. And that particular idea I read about also in a book called "TeamWork," which is an old book from...I think it's from the 70s. And the authors tell the story of the chicken McNuggets from McDonald's. Very early days that chicken McNuggets was struggling in the marketplace. If we look around now, you're like, how could that be? It seems like a very popular food. Like, anyone who has kids... Like, I mean, who doesn't, I'm a kid, right? I love a chicken McNuggets. But at one point, they had these stores in Indianapolis, Indiana, in the states, and the chicken McNuggets weren't doing so well.

And they brought in this consultant. I think his name was Bud Sweeney. And what they did was, he formed a small team, and they moved to a different location. So that's one of the points to help the isolation team become more successful. If you move to a different location than the normal setting, that's something that can help you feel like you have a new beginning or a separate... Like, you really are a different and new team. You're not part of this regular culture that you are with. So when they were trying to turn around the chicken McNuggets, they went to a different meatpacking plant than the chicken McNuggets that originated it in. And so that was one thing. And the second thing was reporting to an executive. That's the second thing that Bud Sweeney had with that.

And it doesn't mean that an isolated team doesn't talk to anyone. Like, they worked out the communication channels if they needed to, for example. And all good, isolated teams do that as well. You know, you're not, like, totally separate. I mean, you're part of the system, but maybe your communication is rearchitected, so it's a bit different. So I think those are some of the things. The process freedom. Another example, at AppFolio, when we were creating a product called SecureDocs, that team was off to the side, given process freedom. We were told not to bother them. That's another point. We don't want to distract them, right? Don't pull them into your meetings about other things. Like, leave them alone. But yeah, I think like, with these isolated teams, it's just the ability to work differently is like one of the key features. SecureDocs, they needed to do ideation. They couldn't be held back by, like, a two week scrum sprint that many of the other teams were doing at the time. That was way too slow of an iteration pace.

Comron Sattari, one of the lead engineers, who later became CTO of the company that became SecureDocs, this is an isolated team that became so successful, launched out of AppFolio, became its own company, and then was acquired, I think, a year or two ago. But, you know, Comron was like, we needed to iterate almost hourly, almost daily. We couldn't wait two weeks to do something. There could be a cadence mismatch between the way your regular teams operate, and the way you need to operate perhaps for an isolated team. And like, one more point, emergencies. Like, many of us were working in these large systems. And sometimes things go wrong, and you have a production incident. Well, naturally, people gather, and they work on the issues, and then they go back to their teams. It's kind of another variant of what I see as an isolated team. And it's a natural occurrence. Like, people organize and have ways that they like to organize, for instance. So it's just a different kind of function of that isolated team.

Charles Humble: I think there's sort of an insight that I would add to this. I actually came across it in the most recent book from Gene Kim and Steven Spear, which is "Wiring the Winning Organization." And one of the things that they talk about in that book is that in order to do strategic work, you kind of need to pull that out of the normal kind of everyday flow of things. Because basically, you don't have... When you're working operationally, you don't necessarily have enough time to step back, and think, and reflect. And they invent a whole language for this, a wonderful word, slowification, which I got very attached to. But just again, it's that idea of, if you can take people outside, separate them off from their normal responsibilities, and then they can start sort of thinking and being more creative again, it is really hard to do that, I think, in our day-to-day jobs.

Recommended talk: Insights on Leadership & Innovation • Gene Kim & Charles Humble • GOTO 2024

Heidi Helfand: That is a really cool idea. And I know for that strategic work, it's, some people have offsites, they change their location, maybe they eliminate all their day-to-day regular activities to have, like, focus together as a leadership team, let's say, or a planning team. And yeah, that's really cool. Even just moving around your worksite can be refreshing and help you focus in a different way.

The One-by-One Pattern: Onboarding

Charles Humble: For sure, for sure. There are a lot of just really interesting insights in your book in general. And I particularly like some of the stuff you had around onboarding. Can you talk about that a bit, maybe in the context of the one-by-one pattern?

Heidi Helfand: Sure, yeah. So, one-by -one patten, someone joins your team or company, somebody leaves. So onboarding is something that if your company is growing a lot, or really fast, you can get really good at onboarding. And really reflect on your onboarding as a program. And we did that for many years at the fast growing startups that I was a part of. So, you know, in the smallest case, somebody's joining your company. And it's helpful if they have a first pair, or like a buddy to work with. Some people do this if you're a software engineer, and it's a great way to get somebody up to speed. They can help you set up your dev environment, walk you through the code base, and start working together on actual work. So, you know, you want to try to get that transition going. So that's kind of like one of the things. And people in other roles might do some shadowing or do some body work as well, just to have that, like, one to one guide to help you get into the company.

I mean, the worst cases, I remember when... I've been on and off consultant for many years. The worst case is like, you arrive at a place and nobody's there for you. And you're like over here at this desk. And it's like such a waste of time. Like, we don't want that. We want people to feel comfortable and welcome. So that leads to belonging, right? So, like, one of the key ideas of onboarding someone in your company is to help them feel a sense of belonging, like they're part of the group. And so some of that is in teaching them about your company. But there's research, and I probably cited in the book, that is cited in a book, "The Culture Code" by Daniel Coyle, that cites research from a call center in India. I think it was the Aditi call center, where they did this study with some researchers and learned that if you get new hires to talk about themselves... Not only like indoctrinating them about the company and teaching them what's going on there. But if you get people to share about themselves, they found that they had higher retention later.

That idea was so resonant to me, because it's like, I view a lot of this as like community building. So you want people to feel comfortable so that they can contribute. And so it just needs to... Conversations in general need to be a two way street. If one person is only talking about themselves, or, you know, company, company, company, company, and like the person is getting sucked into this thing, and doesn't get to shape it at all, it just feels odd and wrong to me. So just this idea of, you want to, like, encourage this person to share. You know, nobody has to tell their deepest, darkest secrets about their soul. Like, it's not about that. It's about, like, oh, what do you think about this? Like, how would you do this? Like, eliciting thoughts and opinions from people that join. Because I think a lot of us, we join a new company, and the safe thing to do is to sit back and listen.

I remember, in particular, I remember working with different engineers over the years, and some of them would really be quiet, like, for so long before speaking up, but others would have this different sense of contribution. And I remember I could see their faces, the ones that would kind of jump in and lend their opinions and thoughts. And, you know, if you have a learning kind of environment, it can be something that is really enriching and helps them feel this sense of connection. All this can go wrong, you know, if the people are triggered, and they're like, not ready for especially an opposing idea. But in general, like, getting people to share, I think is an important thing.

Charles Humble: Definitely. I think there's something that sometimes can get missed in the process of onboarding, which is not thinking about the people who are already in the company. So I don't know, maybe someone who was hoping to get promoted or something, and then a manager was hired in from outside instead. Do you have any advice on that?

Heidi Helfand: That's a huge one. So if you imagine like this, this is a change situation. Many of us don't think of it like that, because it's like, oh, we hired a new person, they're joining the team. But depending on their role, and what they're doing, I mean, you need to pay attention to the people who are already there as well. Right? Like, you bring someone in, and let's say they're in a managerial position, right? But maybe there was someone on the team that wanted that job. And so bringing this new person in, if you don't know that this person wanted this job, you know, there could be some kind of underlying conflict there. It could be that, you know, like, it was open, maybe someone else even applied for this role, but they chose to bring in someone from the outside. You need to coach and mentor the person that didn't get the role, so that they can help this new manager be successful. It's not always easy. You know, how do you help them be successful when people have challenges with new people joining, that's, like, one of the questions that is important to ask the person that was already at the company. Because it's like, we're all here together to build something really cool and valuable, and help the company succeed.

Having us all work together is really, really important. I think visualizing the open positions in the hiring is a good one also. I like to call it opportunity matching, sometimes, let's say, a bunch of new roles. If you're in a physical space, you can have a whiteboard that has, these are the new roles coming up. These are the managers to talk to if you're interested in a new role. You can do this online. You know, let people know what you're hiring for. You might be surprised at who volunteers to be interviewed for one of these positions. I think it's always good to kind of keep that open. But the other thing that it does is, it gives people a sense of how your organization is growing. So that when these new people arrive, they're almost like...your existing organization is primed for it. They share in that future evolution. So it's potentially a form of risk management of drama or dissatisfaction. So that's a couple of the things.

Charles Humble: I really like that. There's a kind of emerging theme as you're talking, and I think about the  transparency that you need to do a lot of this stuff well, which I think is just really interesting and really important.

Heidi Helfand: I guess one last point. You know, and it brings me back to that point about belonging that we were talking about before. And really, not only do you want the new person to feel like, oh, they belong, and they feel comfortable. But it's always this continuous thing with the people who are already at the company. Like, you belong here, too. And even as the company grows and changes, you belong here, you belong here. And there's differing opinions about that, like, some people think that as your company grows and changes, you need different types of people at the company with different skill sets, more entrepreneurial, let's say, at startups and at growing companies, and maybe people with more administrative or other characteristics at bigger companies. There's an interesting book called...it's Ichak Adizes's "Managing Corporate Lifecycles" book. Very fascinating and interesting book related to these themes. We were students of that book at some of the companies I was at.

Charles Humble: That's really interesting. Because there's that whole thing of how do you maintain a culture as organizations grow and change, and whether that's even the right thing to do, I think is at least an interesting question.

Heidi Helfand: It really is. And people ask that question, that exact question. How do we maintain our culture? It feels so different now. We're not the startup that we used to be, we're double that size. You know, when you go from 10 to 20, it feels like a different company, and 30, and 40, and 50. Like, all your communication architecture needs to change. Like, all this stuff becomes different. And yeah, it is a different company. So it's kind of, like, what are the aspects that you want to keep for the long run? And that gets in the space of, like, it sounds cheesy, but like company values, traditions, symbols, things that we do across time, that give us a sense of who we are as a company, or what is important to us. So those are some of the things. You know, I think that stuff is fascinating.

Recommended talk: Dynamic Reteaming: The Art & Wisdom of Changing Teams • Heidi Helfand • YOW! 2017

How Core Values Foster Growth

Charles Humble: Yeah, I do, as well. The value stuff I find really interesting, because when I first sort of came across, you know, core values and those sort of things, the sort of Britishness in me was just like, no, not doing that. It all sounds ghastly. But actually, in particular in organizations that are growing really fast, I think there's tremendous value in having well defined values, and well defined, you know, this is what the company is for, that you can use as a filter and kind of check back against when the company starts growing. As I said, I've kind of really changed my position on them. I was very skeptical when I first encountered them. Because we've all had those, you know, meaningless mission statements that sound like, these days, you might generate them as a large language model or something. You know, just like meaningless word soup. But actually, if you do them well, I think they can be really effective.

Heidi Helfand: Can I tell you about a company that does them really well?

Charles Humble: Sure.

Heidi Helfand: And I was blown away, because I've been at companies where I helped write them. And I can't remember them to this day, I think. I remember like one of five. Right? But when I joined Procore Technologies, initially, as a consultant, I remember meeting these engineers, and it was this vibrant, big, open, almost like warehouse of a big open space, but really cool design. Because, you know, Procore makes this construction software, so it's all about builders and building. But I would meet these engineers who would really... And what we would say at Procore, live the values. So the values are ownership, openness, and optimism. And so, ownership, I would meet engineers who would say, I'm going to take ownership of that, or in the spirit of openness, let's bring this other team in the fold so they know what's going on. And like, how can we bring more optimism to this situation?

They would use these values really as principle operating principles almost. And they were catchy because they were the three Os—ownership, openness, optimism. And I was just really like...you know, it was almost like... I mean, they were useful to people. So these engineers were using them, and they were taking ownership. And they're doing all this stuff. And it's one of the reasons I joined the company at the time as an employee, because it was just like, there was this... These were all very constructive. Right? And they were very... I guess that's a pun because they're construction software, but they were constructive. They were useful.

Charles Humble: I think that's a really good test, actually. There's two things in there. One is, are they useful? You know, can I actually do anything with this? And the other is, when you have people in the company actually using them, that's a sign that they're kind of resonating and making sense to people, which I think is a really good signal.

Heidi Helfand: Joseph Grenny, he's, I believe, the author of the book, "Crucial Conversations." He came to Procore and wanted to give a talk to all of us in the tech group. And I believe it was him that said, you know, values are only useful when you stand up and defend them. Like, is there something going against a value? If the value is useful to you and your company, you're going to say something about it. Like, no, we need more openness here about this topic. And like, things like a whiteboard reteaming that we did at Procore. Definitely, like, we could use the value to be like, hey, we want to bring more openness to this big change that's about to happen. So, you know, let's take a look at this together. And you have this, like, optimistic viewpoint that... You know, it's scary, when we rolled out those whiteboards from a back room to, like, get our peers feedback on these changes, like, it was pretty frightening. But you just kind of like to lean into that optimism of that, you know, we're doing this. So we're going to share ownership of this future and be open about it.

Charles Humble: I think as well, you learn a lot... When a company is in crisis, it tends to be more likely to abandon its values, if you see what I mean. Because they are not real than, you know, things like transparency, or openness, or those sorts of things quite often will go out the window when the company is in crisis mode.

Heidi Helfand: Nothing's perfect.

The Right Time to Split Teams

Charles Humble: Yes, absolutely. It's fascinating, I think. One of your other patterns has to do with splitting a team. So are there any particular signals that you might look for to know when it's time to split a team?

Heidi Helfand: There's a few. Meetings are longer. You usually meet for 10 minutes in the morning for stand up. And suddenly, it's like 45 minutes, because there's so many people. Then you might notice that people aren't paying attention to each other because the work has diverged so much that people don't feel a need to listen to each other. The notion of, like, working together jointly is kind of fading a bit. 

So, yeah, things are taking longer, the work is diverging. It could also be that it's hard to make decisions. Because there are so many people, especially if you're used to getting buy-in with the whole team before proceeding on certain types of things. There could be that. And then that awkward thing where now you're this large group, so two people are talking and everybody else is silent. And it really feels like that a lot. And you're trying to rush through meetings, because if you get everyone's voice included, things take longer. And so I think it breaks down into some of some of the solutions you might create together, because it's much harder to get all voices heard and participating.

You can facilitate differently. So some might try that before splitting a team. Maybe we facilitate differently. So we use some "Liberating Structures," let's say, which is a great book and website that talks about different ways of helping people create the next step by different types of communication patterns. But yeah, sometimes people are just like, you know, let's split into a few teams and move on from there, it'll be easier for us.

Charles Humble: Splitting always seems to me quite fraught because quite often, you only have, you know, one of somebody, particularly if it's a specialism like UX say or a DBA or something like that. Obviously, you can have central teams, what Team Topologies calls enabling teams, where you put some of those people. That's one way around it. But do you have any advice around that?

Heidi Helfand: So that's, you know, such a real thing. And if you do have people aside in an enabling team, or whatever, and they have to serve 12 teams, you have a dependency that you need to manage. And what's the priority and where do they go. It's something you can try. But sometimes people merge together to deal with a shortage of specialists, and then engage the people in different ways of organizing so that they work out more locally, when they need this person's help, or that person's help. And when teams split, sometimes it means that, like, the product manager is now managing two teams, and their workload of meetings and refining and getting thoughts together is going to be more challenging. If there's a unique quality role on a team, suddenly, they have two teams. User experience or design, they usually have a lot more than one to two. They might be supporting five teams, and there's that dependency situation.

Again, none of this is perfect. So it's kind of like... And then if you merge teams and try to foster some kind of self-organization, it helps to have a default pattern with how to do that. If you've heard of the fast agile pattern, they integrate open space and working on things. It's kind of an interesting one. Or sometimes you'll have, if you merge teams, a couple of leaders will emerge or be entrepreneurial in their approach to team organization, where you get your new backlog of work, and people will form smaller teams, and dissolve, and then come and form smaller teams and dissolve. And people like to do that sometimes, and manage their own kind of local... It's like a startup within a company. So some teams feel like it's... Some teams, if you merge them and the people are not, I would say, entrepreneurial enough to organize themselves, you could have challenges and you need to get somebody in there to help facilitate.

But some really great teams that I've worked with, they want to organize like that. And so give them the chance to be part of a larger team where they really kind of form smaller teams, and then go back, form smaller teams and go back. It's a common pattern since, you know, now we've got front end engineers, back end engineers, AI people, like, data analysts. Like, there's all these different specialties so much more than, you know, 15 years ago. Like, all these different specialists of all these different types. And nobody's gonna hire... You're not gonna have like one for each team. I think a lot of this is, like, the "Toyota Kata" Mike Rother approach. It's almost like, you have a current condition in your team. You have a future condition that you want to get to. What's the next evolutionary step to get towards that? And like, reflect along the way to kind of refine how you get there. And the best teams I've worked with have had the freedom to organize and reorganize, based on their perspectives and how they drive the organization.

Charles Humble: In the context of merging, you have the idea of the story of our team in the book as well. Can you talk about that a bit?

Heidi Helfand: The story of our team is a really cool activity that you can do. And it scales. I've done it with 100, I've done it with 10. Basically, what you do is you form a shared timeline together. You can do it online, or you can do it in person. It's good for an offsite, like we were talking about before, when people are taking a strategic break or trying to focus on a specific goal. So basically, what you can do is put paper on a wall or use whiteboards, and draw a line. The right side of the line is today, the left side is some point in the future. And you have everybody get up, stand in line in terms of when you joined the company or the team. And you can pick the dimension. So these people stand in the line. And then I tell them, okay, turn to the whiteboard or the timeline. Put that in your name and your start date. And then we all see that. I'm like, okay, talk with the two or three people near you. What happened at that time frame? What were the significant accomplishments that you made as a team? What were the world events that happened? People put COVID on, you know. What other changes happened at our company?

And they make this timeline, and then you have them tell the story of the team. And you give each person an opportunity to talk or you do it in batches, if you're doing it with a larger group. And you can use your phone to record it. And then you get this kind of story about the team. And you can do it with companies that have merged. So you have like one timeline for the existing company, and then another timeline, and it joins, for the company that you're acquiring. And it's really cool because you get a sense of shared history. And you get a chance to give the teams the ability to share what they're proud of, what they've accomplished together in the past, in their team. And these are...some of these things just won't come up in regular conversation. Like, hey, guess what we built before. You know, it could be awkward.

So it gives this opportunity for people to share these, like, cool things that they've built, or what they learned, or even sad times. You could take that timeline and code it red, yellow, green. Like, green are like the happy times that we shared. Red, this was horrible, this was awful, but we got through it. You know, yellow is kind of like, whatever, it just happened. So it's a very powerful activity. And that's one of my favorite things to do. I love doing that.

Dealing with Toxic Team Members

Charles Humble: I think it's excellent. A lot of what we've been talking about has been sort of quite... You know, there's a sort of implicit assumption that team members are sort of all very good and positive, and the teams themselves are working fairly well. But of course, that isn't always true. So do you have any advice on dealing with toxic team members?

Heidi Helfand: Yes, toxic team members. Like, you got to talk with them. And you got to find out what's going on. And sometimes they need to leave. And this is where good management practices come in. When someone has a problem with another person, you know, the typical go to for many of us is, okay, well, have you talked to them? You could be wrong. It could be like, oh, my God, this person's toxic. They're causing all these problems. But maybe they're being ignored, maybe they're not being included. Like, what's going on there? You know, one leader said to me once, perception is reality. Well, sometimes that's not fair. So I think it takes some time and some patience for leaders to coach people to try to work things out. If they can't, then they can escalate to you. But sometimes people are wrong. Sometimes they are right. And sometimes... You know, maybe this person is not motivated, or is looking for something different to do. And maybe they're going through something in their personal life, and they're taking it out on the team.

You know, one of the questions is like, what do you tolerate as a company? What kind of behavior? You know, it's not that the person is bad, it's like, the behavior of the person might not be appropriate. Are they getting attention? Are they getting coaching? Are they getting mentorship? So I always like to give people the benefit of the doubt. But if things fester, you know, you got to, like, go in there. And sometimes, you know, you need to make difficult decisions, and people need to move on or do something else. Sometimes people try to isolate a person who's disruptive. You know, a lot of it depends. But yeah, I remember I was with a team once, and the product manager was afraid of the developers. And after a while, that team just had to dissolve. Like, there was a funk going on there. And so, you know, keep your teams the same, keep them stable.

Time does not solve all the problems. Back to this traditional wisdom that we were talking about before. Sometimes the dynamic is off, and you need to just get rid of the team. And I know that probably sounds harsh, but looking at the bigger picture, especially if you're a senior leader, you know, some things just need to change or have a fresh start. And really trying to understand what's going on is important, you know. So if you're really separated from the situation, there's this abstraction problem, but what is going on with the people in the teams. I like the idea of having local coaches that are not managers to help people through different conflicts and other things. It's normal to have conflicts. We are not all holding hands and dancing around together. You know, sometimes we need to work through stuff together as humans. And a lot of the human side of engineering work is really important.

How can we facilitate this relationship building so people get along, but they have productive conflict. And yeah, so sometimes you're gonna get curveballs and you have to decide, you know, like, here's our... It's like that Toyota Kata. Here's the current condition. Here's a future condition. What's the next thing that we can try to try to improve this situation? And then reflect on it. And we're doing this continuously with interpersonal stuff, with organizational change stuff, with the technology that we're building. We continually like trying to...it's like action research. Like, action and reflection. It's what we do.

Resources

Charles Humble: We're just about at the end of our time. So just as a way of wrapping it out. You've mentioned quite a few books already. But are there any other books or resources that you would maybe recommend for people who are going through a reorg or going through other kinds of changes or transitions?

Heidi Helfand: So, I love..., "Liberating Structures" that we mentioned. The book, "Creating Intelligent Teams," is an interesting one as well for different activities you can do with teams, like at offsides, for example, or a different team time. I have a new book on Lean Pub, called "How to Change Your Teams," which is a very short guide, which looks at this from the perspective of, we want to deliberately make some changes, how do we go about it? So there's that. You know, "Team Topologies" is also a great book that inspires a lot of people and future team design, especially if you want to vision out the future of your tech org. They've got a lot of great ideas in there as well. And yeah, there's a few.

Charles Humble: That's fantastic.

Heidi Helfand: And "Transitions," William Bridges, the book, "Transitions: Endings, Neutral Zone, New Beginning," that's a great book. Especially if you've been in a situation where maybe you got reteamed and you're not particularly pleased about it. It's a good book to reflect on changes that happen to you or to others.

Charles Humble: Fantastic. Heidi, thank you so much. It was absolute pleasure to talk to you.

Heidi Helfand: Great to see you, Charles. Thanks.

Books and resources

Dynamic Reteaming: The Art and Wisdom of Changing Teams by Heidi Helfand
How to Change Your Teams by Heidi Helfand
Wiring the Winning Organization by Gene Kim and Steven Spear
Teamwork: What Must Go Right/What Can Go Wrong by Carl Larson
Liberating Structures
The Culture Code by Daniel Coyle
Managing Corporate Lifecycles by Ichak Kalderon Adizes
Crucial Conversations by Joseph Grenny et al.
Creating Intelligent Teams Dr Anne Rød and Marita Fridjhon
Transitions by William Bridges (Author), Susan Bridges
Team Topologies by Matthew Skelton and Manuel Pais

Podcasts

Insights on Leadership & Innovation by Gene Kim & Charles Humble
Structures Shape Results by Elisabeth Hendrickson & Charles Humble