045 - Roadmap to reteaming with Heidi Helfand

We speak with Heidi Helfand, author of the book Dynamic Reteaming, and Director of R&D at Procore Technologies. Heidi explains her roadmap for leaders going through organizational change as she shares the five different models of reteaming.

• Dynamic Reteaming on Amazon
• Webinar: The balance of bottom-up leadership

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

[00:00:00:000]

Hello, and welcome to All Hands on Tech, where today's leaders talk tomorrow's technology. I'm Daniel Blaser. In today's episode, we speak with Heidi Helfand, author of the book, Dynamic Reteaming, and the director of R&D at Procore Technologies. Heidi explains her roadmap for leaders going through organizational change, as she shares the five different models of reteaming. 

[00:00:28:962]

All right, Heidi, first off, can you provide just a little background on your career and maybe how you became interested in the concept of reteaming?

[00:00:38:132]

So I've been in the software industry about 20 years or so, and I've been a part of different startups. So the first startup I was a part of, I was the 15th employee.  It was Expertcity. We got acquired by Citrix. And we built GoToMeeting and GoToWebinar and GoToMyPC, these products that are about screen sharing. And I was a writer, I was an interaction designer, I was a technical project manager. And one of the things that was always constant was these teams changed. Your organization grows and morphs. And it's really just inevitable, especially when you double, triple, in size. So I was at that company as the 15th employee, and I left when the company was about 800 people. And then I went to another startup, and I was hired as the 10th employee, and I was hired in their agile coach, scrum master kind of process-oriented role in engineering. And I was the 10th employee there, and I left when that company was about 650. In that one, some of us were on the first team at the previous startup, and we had a lot of do-overs, but I guess that a tangent. But even with that company, we deliberately would change teams for a variety of reasons, like spreading knowledge around, or people would want a change and they want to work with someone else or want to learn something different and felt like staying in that one team kind of could be stifling. So there's a lot of learning that can happen when you switch teams. And so there was that. And then I was at a conference, or there became a point where everything I would read would be like, no, what you want to go for for effective teams is to have your teams be stable and to stay the same. And that kind of bias I saw in a lot of agile reading, a lot of scrum and other methods or frameworks. And coaches that I knew would talk about it. No, we really what we really want to go for is this. And I remember being at AppFolio, the second startup, and I built a coaching group there. We had, I don't know, five coaches that I managed, and we were helping all the teams be more effective. And if we would've applied that philosophy, it would be counter to helping our company grow and thrive. Because as you grow and you add people, especially really fast, if you're in a fast-growing company, things just need to adjust and change. So leaning into that change is important. Fighting that change is counter-productive. And so I wanted to prove the point that there are very successful companies that are out there that change and morph as they grow, and that's valid. Keeping teams the same because of some philosophy does you no justice if you're in a dynamic environment that's growing and changing and you want to really have this thriving culture of learning. And so I really wanted to, I became obsessed with proving the point that you can be a highly successful company and reteam. And you know what, everybody's going to do it because whether you like it or not, people come, people go. Suddenly you get a new executive that comes in. They change everything. Sometimes you need to adapt to the change, and other times you catalyze it. So I became really just obsessed with proving this point that you can have a really successful team if it changes. And our first startup, we got acquired by Citrix, and the products became very successful. The second startup went public June 2015, traded on the NASDAQ, very successful company from that perspective, and still continues to grow and change. That's AppFolio, very proud of AppFolio. So then I was like, was it just us? Was it just the Southern California tech scene out of Santa Barbara? And so then I began interviewing people, kind of like this, like schedule an hour call with someone, interview them, and my colleagues from around the world just told stories of how their teams kind of changed and how. And then from all those different stories, I wrote about five patterns, five base patterns of team change. As I started collecting these stories, I saw these patterns, and so I wrote about the patterns and then how to get better at it.

[00:05:27:631]

Speaking of the interviews that you mentioned, were there any outliers? Or did all the conversations kind of fit neatly into one of the five patterns that you identified?

[00:05:38:136]

It was almost like the flip of that. Because I had all these stories, and literally, over here, I'd transcribe the data, and so then I'd code it for patterns. So here's an example. I have like stacks of these out of all the people I interviewed. So I discovered the patterns just through these stories. So I didn't have them before and see how things fit. It was more like, oh, interesting. I'd go through and I'd highlight themes, like, why are people talking about stagnation? Stagnation is a big theme that relates to what I call the Switching pattern, where somebody feels like their stuck. Like I'm the only one that can maintain this codebase, and I'm stuck in this team. But wait, I really want to learn Python or machine learning, but I can't switch to the other team because I'm stuck here. And so it leads to discussions about how can we have resilient teams that, you know, maybe we pair program so that then later when somebody wants to grow, they can move because they're not the only person stuck on that team. So, you know, hearing the stories, I just got out a highlighter, and these things just emerged. And so it was really fun because, you know, having a call with someone, I didn't know what change has been like at their company. And so it was really exciting. And so I'd do these interviews, and then, oh, my gosh. This supports this pattern. So the patterns started showing themselves. And the most common one through a lot was teams growing big and splitting in half. So people just started telling me these stories. I would just ask the question, can you talk about how teams have changed over the years at your company? Like a big open question like that, and then the conversation ensued. And then people start sharing these stories. Or I'd start speaking at more conferences or, I only put out like one blog post, I think. And people would be like, you know what, we do that too. That's at our company too. And I think people had become motivated to talk about it because it had been so shunned. Like, no, you're not supposed to do it that way. You're supposed to keep your teams the same, you know, forming-storming-norming-performing. He forgot the phase stagnating, which is one that many people can feel. It's why we leaving companies sometimes. You feel like you're stagnated.

[00:08:14:560]

You already touched on one of the patterns, but I'd love to dive into each of them a little more in depth. Would that be okay?

[00:08:20:805]

Yeah, so the first pattern is, I think I call it the One by One pattern, actually, so that's a good place to start. And so that's the general idea, that people are going to---you have a team, the team is a system of people. And so who comes in and out of the team changes the shape of the team, the intelligence present in the team. And so, yeah, so the One by One pattern is basically that. It only takes the addition of one person or the removal of one person to have a different team system. The team is a little bit different. I like to tell the story of Tim. There was a guy I worked with at one of the startups. He was a juggler. When Tim joined, suddenly we were all juggling when we were taking breaks. When Tim left, that juggling kind of left with him. There was less juggling. People bring different things to the team, whether it's a skill or a hobby or interest, or just personality. You can feel that things are different. And so the One by One pattern is really present when your company is growing or when it's shrinking. It's not such a happy time lately with our global pandemic, and companies are laying off people. It's a very difficult situation, so people leave. It's part of the One by One pattern. Or groups can leave. Groups can join. So it's essentially that kind of like one in, one out. So there's a lot in the book about onboarding. So let's say it's the flip of the current situation, and times are good, and your company has a goal to double in size, and so you try to hire a lot of people. And you just want to get them in as fast as you can. So people are constantly joining, and then you have to determine where to put them. Which team do they join, where do they go? And then how do we make it easier when people join a single team or join a group or an organization? So there's a lot of kind of tactics about making it easier when people join. So that's like the first structural pattern. _____ if one person leaves for whatever reason. Maybe they go to a different team, or maybe they leave the company. There's practices that you can do to help the team that remains. And so it's one in, one out is One by One.

[00:10:45:687]

Yeah, yeah, that's really interesting. It seems like this kind of one by one makes for a much slower shift.

[00:10:54:055]

Yeah, it's like a reteaming at the edges. It could be a little bit more consumable. And I think for many of us, this has been happening in the places we work for years. Oh, we have a new employee. We have a new hire. Oh, let's help them get up to speed. It's almost normal. And we might not realize the degree to which our team is changing. But after a while, if you keep doing this, at some point people are like, oh, my gosh, we're so big, we've doubled in size, things are so different. How do we maintain our culture? And they ask that particular question, which is almost kind of like a trick question because it's like, well, you've already changed. Your organization is different. If you're 100 people and then suddenly you're 200, there's a lot more people. And it is different. So it can kind of creep up on you if you grow gradually. And then certain things come up like, we need career ladders, hierarchy emerges, other things happen. One of the other points of the book is like, alright, this stuff plays out similarly no matter what company you're at, so be prepared for this kind of stuff. People are going to---when am I going to get promoted? What's my career trajectory? All these things are normal that will come up. There's a lot of things to focus on, but I think we can proactively in our companies kind of plan for some of this stuff that is going to---one day you're going to get badges. The doors are going to be locked, and you're going to have to---maybe in the past, things are more open, but you're not going to know all the people if your company continues to grow. So one day badges are going to arrive. But there's things that you can do to make it easier when you add people, especially having mentors, buddy system, pair programming. A lot of these ideas aren't new. There's some other things about just, you know, you don’t forget the people that, there's always a focus on the new person and bringing the new person up to speed. There's a couple points in the second edition that are different, which is, like think about the people who are already there. Don't only pay attention to the new person; you have to pay attention to the people who are already, especially if you're growing really fast. Because it can impact morale when everything changes pretty quickly or sneaks up on you and then you realize it. And then the other thing is, one of the other kind of new points is about research that talks about, it's not just bringing the new person aboard and indoctrinating them about your company. It's also like, what about them? Sharing their personality, their interests, and other things has led to greater retention. So I cite some studies in that. It's a very feature-rich chapter, the One by One pattern.

[00:13:58:663]

Yeah, I really like that emphasis on new talent enriching a team. It's a two-way street. 

[00:14:06:063]

Yeah, you get diverse ideas and thoughts when new people join. And it's kind of like, you don't want to shut that down. And a lot of the times when people join, maybe they're a bit reserved about sharing their ideas. They don't want to say anything wrong. They don't know how things work. But if we, the people that hire them, can really encourage the, especially at the beginning when they have fresh eyes over the whole situation, I think it can be a really good thing. And it can help them feel more included earlier on. So it's all about belonging.

[00:14:40:577]

That's great. Should we jump to the second pattern?

[00:14:43:882]

So the next one is, I have it next to my book. It's the Grow and Split pattern, which we were talking about before, which is like, after a while, these team systems or departments, it could happen at different levels, this stuff. They just get to a point where things feel ineffective. Our meetings are taking longer. The ways that we've been organizing kind of break down when the scale gets a little big. And so sometimes people will say, well, we need more people. We need to build these features. We need to add to our teams. And inevitably, you get to a point where it's almost this like rigidity trap where things are slower, work is unrelated, our meetings are longer, and things are just harder. And so sometimes the team, if the team is encouraged to have retrospectives and reflect on their structure and reflect on how can we be more effective as a team, if the team has some kind of autonomy over their design, sometimes these teams say maybe it makes sense that we split into a couple of teams or a few teams. And so Grow and Split is all about that. So it's recognizing when you might want to split, and how do you go about that split, and then what do you do after you split? So we have a team, the team is working in a certain way, they manage their work in a certain way, they know each other. They get big, the split in two. So you can do things to help enable them and to help launch them after they've split. All right, well, what's our mission? What are we going to focus on? Why are we this team? Why do we exist? What are we getting paid to build, like, what are we here for? So there's stuff about the work. There's stuff about the people. Do we actually know each other? Maybe we had a couple new people added. Maybe that team system is a bit different. They got so big that they formed cliques and the relationships aren't really set. So I usually, and day to day, this is a lot of the work that I do at Procore. In fact, I have two squad calibrations that I'm doing this week. I focus on getting the people, the work, and the workflow reset. So there's different practices that you can do that I write about. There's a calibration chapter in the book that has a lot of the activities that I do day to day. And people keep asking me for them, so I've written them out in the book, about team calibrations. And so yeah, so there's things that you can do to make this stuff easier. Now, not all teams should split. Sometimes it's valid to have a big team. That's why I like to put the team change decisions into the hands of the people and not have this external kind of executive director, whoever, saying---you know, there's a story in here that one team was like, everybody was like, your team is too big. And they were judging this team. But wait, this team was a highly productive team, delivering value to their customers at an acceptable rate. It was an enjoyable experience. They have their ways of working. I sometimes call it poorly done foreign aid. It's like you're judging us from the outside. You think we need this, but, no, we're good. Maybe we need something else, but don't change us because you think---don't you like the rate of delivery? People can be a little bit misguided. Sometimes larger teams work. And usually I think it's because they have really good ways of facilitating their meetings, they're very organized, and they have some pretty good kind of glue people who are keeping their team together. Maybe they have some kind of coach or someone else who's involved that's helping, or a good manager helping keep stuff moving. So one of the things that I like to say is I'm not about, like, team gets to this size, you always split it. No, there might be a valid reason why that team wants to be together, like pair programming. If your teams pair, it's nicer to have larger team because then you have more pairing variety when you switch pairs. 

[00:19:13:666]

Yeah, I think this Grow and Split pattern, it's really important because it just empowers the team. For leaders, how do you know when the timing is right for reteaming? And it's not just a change for the sake of change?

[00:19:30:743]

Sometimes reteamings are top down and are very deliberate and have very good reasons for happening. And whether we like it or not, we don't always get a say in the situation. We don't always get to decide. Sometimes we're just going to be moved, or we're going to be split or whatever. You know, we acquire a company, and lot of changes ensue. Or we get acquired. Sometimes this stuff is out of our control, which can be pretty frustrating. To that, I think education for the leaders is really important about reteaming. And that might be one of my new quests. How do we develop this capacity to grow and change learn from it? It's not about, I'm going to go in there and reorg these people and move on and never talk about how it went. So how can we get these feedback loops in there so as an organization we develop a capacity to have humane reteaming? And this is another thing I write about, and it's different in the second edition, it's new material. We have an initiative. We have a reason why we want to change. Well, what problem are we trying to solve? Usually, if you have a problem, there are many different ways to solve it, and there are pros and cons to each of the approaches. And if you're inclusive with the design of your reteaming and you get ideas from people on the ground, I think you have a greater chance of success. Kristian Lindwall, I believe now he runs some kind of infrastructure or machine learning groups at Spotify in New York, he tells some stories in there about how they had an idea of, they had to reorg a tribe that they had. The missions were getting kind of overlapping, and it seemed that they needed to rethink their structure. Well, they visualized their reteaming plans on whiteboards and brought the contributors over, and they helped them together through feedback figure out the final structure. And it played out for a couple of weeks, I think, in his story. I call it like a whiteboard reteaming. And the cool thing there is that, if you're not involved in the technical work, you don't always have all the clarity that you need to make the best decisions. So it's important to get the voices of the people that are doing the work. And then you'll learn that, like, oh, hey, no, this solution is better, or this team should be over here and here's why. And so being inspired by that, we did a similar thing at Procore a few years later where we had an open reteaming on whiteboards. And so I think it's important to develop that capacity to get the inclusion of the people. But then at the end, at a minimum, having a survey about how the experience was for the people. Because if you're reorging over and over, if your company is going to grow and triple in size, you're going to be morphing and shifting. And so what is that experience like for the people? Have a retrospective after. Have at least a survey. And then when you do it again, apply the learning. So I think you can develop the capacity to do this really, really well. And that's I think kind of the cutting edge of this stuff, being able to shift and reflect and develop that capacity to reteam so you don't lose all your people, so you don't have this kind of like really crappy experience.

[00:23:14:560]

I really like your anecdote that you included in your book about the Spotify team all whiteboarding the reteam together. Including everyone is just such a powerful way to approach it.

[00:23:25:771]

Yeah, and making the decision making clearer, like, we have this challenge, we need to change to help solve this challenge. We want your input. Here's how you can provide this input. We're going to make the final decision, but we want to hear what you think. And then, okay, we'll take these things into consideration and we'll talk about it later. And then we're going to have to deploy this out and we're going to get your feedback along the way. So laying out a specific reteaming timeline and plan is something that I think is really important too and especially so people know you're going to have the opportunity to tell your thoughts and help shape this as we go. I think it can't be understated. And it's more of a kind of open philosophy, which, my bias is very much kind of the bottoms up. And I just, I don't know, I just, the individual contributor, the person that is working and that is creating the amazing technology that we all use, I think their voice needs to be very present in the development of the organization because their engagement and their excitement and their learning is key to the success of the company. So doing like engagement surveys is also really important, tapping into the sentiment of the people and how they're doing. And then it's not this---like in my world, people have a voice, and we're doing this together. And we've got to recognize that there is rank and privilege with the higher-level positions, but they will only succeed if the people believe in them. And so treat us well, and let's learn together. And we solve---Kristian Lindwall says this in some of the interviews with him. It's kind of like, we solve really challenging problems all of the time. Trust us. Let us in on the conversation because who wouldn't want to have more options? If you have challenge A, and ______ solution A is proposed and there's pros and cons, solution B, pros and cons, solution C. Let's make the best decision for the company. It's worth the investment. It's not one and done. I think that's shortsighted. 

[00:25:54:261]

I think there are a lot of companies that need to hear this, and they need to have some frank conversations, to be honest.

[00:26:00:371]

Yeah, Grow and Split, and then my philosophical rant there. Isolation is another pattern. So you form a team off to the side and you give them process freedom. And so it's good for emergencies, it's good for pivoting your company, it's good for spurring new innovation in a company. If you have an existing company, you have processes become kind of heavy after a while, especially if you grow bigger, bureaucracy just sets in. It's part of the corporate lifecycle. It's hard to innovate when you're moving like a glacier. If you take a team, put them off to the side, and you tell them, you can do things differently, you don't have to follow that other process, they can do some amazing things. So the first startup I was part of, Expertcity, we were trying to build a marketplace for tech support delivered through screen sharing. Nobody bought our product. We had to pivot. What I now call Isolation reteaming pattern is what happened. We had a small team pulled off to the side. I was on that team, I was a writer, tech writer, at the time. We were told, you don't have to do waterfall development like they were doing. You can do something different. And we didn't have to work with pixel-perfect mockups of the design of the stuff that we were building, which was hugely liberating. Worry about the look and feel later. Just make something functional. And we created a product call GoToMyPC, which let people see and control their computers from a distance. I think GoToMyPC's still around. But it helps people that their computer is at the office, they can't take it with them for whatever security reasons, they can get into it, see it, and control it from home. But, yeah, also if you have a perform---let's say you have an outage and you need to compile a short-lived team to kind of solve that problem. So that's another example of Isolation. And so there are pitfalls of it too. I remember being at a company, and some salespeople were very excited about, like, if we build this thing and we get this client, we get to do all this, they enlisted some engineers, they built this cool thing, they got the client, they got the money. But then this was somebody else's codebase and they left a mess, and it caused relationships to be kind of scarred, and it caused a lot conflict. You've got to do this with the people in mind. So I think you've got to work out your contracts between your teams, and you've got to work out maintenance for the thing that you're building. If you have this existing codebase and you need to leverage some of it for this new thing that you're building off to the side, if you don't work out who's going to maintain it and have that foresight, you could have some problems. So all these patterns have like, this is how it works, these are the stories, and these are the pitfalls of the patterns. Stuff doesn't always go well. This stuff is hard, so there's some caveats to it. It's not like install this reteaming pattern and your life is better. No, you can screw it up. And so you've got to develop a capacity for it. So that's Isolation. Then there's Merging, which is really opposite of Grow and Split. You've got two teams, let's say, that merge together. We were talking earlier about pair programming variety. That's one of the reasons. There was a pattern for a while at a company that I was with where each team had very strict code ownership of a tool, and it could be that it's not the highest company priority to work on this tool. It could be that we want more teams working on this other tool. And so what we did was, we combined teams to form these communities, and they owned several tools. And they would have kind of a pull-based system where they'd have a initiative that was important, and then they'd reteam based on the initiative. But the community of teams, let's say four teams, owned a whole set of tools. There's like that. So that's kind of like a team level or organization level. I tell the story of William Them who was an engineering manager at Trade Me in New Zealand, kind of like an online auction in New Zealand. They combined to pair and switch pairs at a regular cadence because they were porting a system from one language to the next. Then there's company levels. We acquire a company. Suddenly we have 40 new team members. Where are they going to go? It's a bigger kind of change. We get sucked up, we get acquired by this other company. How's that going to play out? Sometimes it really is horrible, and people get laid off because there's duplicate roles or the direction is changing. It can really be like rip your heart out. So there's some stories in there that are like, whoa. I think we need to talk about this stuff because it just happens.

[00:31:11:722]

I agree, yeah. I think it's really valuable that you also tell some of those stories, even though they may be tougher to hear. 

[00:31:20:595]

If a company is acquiring company after company, again, how can we---let's say we have a Net Promoter Score inside our company. All of our employees rate us on engagement and how they feel about the company. How does your score fluctuate as you acquire company after company and how you manage that? I think it's important to kind of look at those kind of metrics and to try to get better at doing it and find ways that are putting the employees first. And how do we lessen the ambiguity around some of this stuff? William Bridges wrote a book called, it's like Managing Transitions, and I cite it in the book. I think that's what it's called, Managing Transitions, something about transition. And it's just this idea that, and in that talk that you watched, sure we have structural changes. That's not all. The people have to adjust to these changes, and it can be really, really hard. And there's a lot fear that's generally present. So the book is called Transitions by William Bridges. But talking about the ending. He calls it a neutral zone, that floating period where you're not so sure, like, do I do this job anymore? Where's my place here? What am I supposed to be doing? I haven't quite, I'm like, you know, you can be kind of lost in this kind of space, and then hopefully you get to that new beginning, but how can we make this time of floating, or this time of feeling, that unease about this as small as possible and get people to their new realities, or new beginnings, their new team situation? And how did we dictionary? Like, all right, we acquired this company, this was the plan, this was the timeline of all the changes, and let's gather the feedback, and how did we do? What are we going to apply the next time? Because maybe in 6 months we're going to acquire another company. There's some companies, they acquire company after company. So how can you really get good at this and recognize that you need to pay attention to that? I think that where some of the awareness of this stuff needs to happen. This is something to get better at and to get mastery of. But you can't do it unless you reflect on what happened. And a lot of times I think maybe people avoid it because it was really hard in that we had to let a few people go. And that has to feel like the worst thing to do to someone, or one of the worst things. So this stuff is not easy. Yeah, so Switching pattern is the last pattern, and it's really about a couple of things. One I want to grow and learn and be more fulfilled in my job, so I have the opportunity to switch teams. And I think when companies share opportunities internally, it helps people extend their life span at the company. And who wouldn't want to keep great employees? There's some stories from companies in here that do that, that give opportunity for even changing roles and doing something different. And I love that idea. Then there's also deliberate switching in order to spread knowledge and to become more resilient as a company. And so at AppFolio, for example, I remember when we had teams that were focused on commerce, they were writing software that received rent checks. AppFolio's a company that, they make software for property management companies and law firms and some other verticals. But when we were working on Property Manager, there was the, I remember some of the leaders noticed that, hey, it was just this one team, they're doing these features that are just so critical. We should really have more than one team good at this. So they deliberately reteamed to spread that knowledge because they recognized that the knowledge was getting siloed. So how do we spread the knowledge so that later when something comes up and we need that knowledge present in multiple teams so we can act on it, how do we do that? So Pivotal Cloud Foundry, there's stories in there from Evan Willey. He talks about how they would keep track using an internal tool of how long people were on different teams, and they'd switch them at a regular cadence. And as an employee, you know this happens. It's almost like, before you get hired, you know you're going to pair program, and you're going to switch. So knowing what you're getting into is important. There's stuff about hiring that relates to this. But you can really build some resilience if you build in regular switching. And again, it becomes part of how we do it at our company. So Switching pattern is pretty cool because it connects into those ideas of, well, wait a minute. How do we become a learning organization where people are really developing mastery, autonomy, and purpose, and feeling like they're not stagnating? I could have a new opportunity within my company. So there's ideas like that with the Switching pattern.

[00:36:54:574]

How do you know if you're progressing in the right way? Obviously positive feedback from the team is one important input, but what other indicators do you recommend that leaders look for to make sure that they're on the right track?

[00:37:07:638]

How do we know if we've made the right decisions and we're doing well? I mean, I think it comes down to, are people buying our software or the service that we have? Are we delighting our customers? Are we delivering software continuously to them and they keep buying it? Is our company succeeding? Are things going well, like economic downturn and all that aside, COVID, all that stuff aside. But I think it's really about, you know, it's like the people, the work, and the workflow. So there's several things that you can do from kind of the lean/agile perspective to help workflows become effective, and I write about that in the book. Looking at how can we have a stable delivery, how can we have a stable cycle time so that we can make forecasts of when things are going to be done? The teams have to be able to get together and operate, so if you change their structure, they need to be able to operate. So how are you going to coach them for effectiveness? So there are ways of managing workflows that I advocate. There are other talks that I have about that with my colleague Tim Doherty, and we talk about, they're really like lean/kanban metrics that we look at. So if we have a stable cycle time, which cycle time is, we measure it from when you start developing something to when you deliver it. And so it's about being predictable in that way. So we have to have predictable deliveries so that our friends in sales and other departments can make commitments that they can rely on. So you need to have predictable delivery, you need to have stable delivery. So we have different workflow tactics. But then it's kind of like, all right, well, that doesn't matter if you're building the wrong thing. So you have to do your market validation and know that you're building software that people want to buy. That first company I was part of when we were trying to make that marketplace for tech support, nobody wanted to buy that product. We did market validation, built GoToMyPC, it saved the company. So you could have an effective team that gets their work through and that's delivering regularly, but if you're not building anything that's compelling, they're going to fail, the company's going to fail. Or you're going to need to pivot and try to save it like we did. Then it's kind of like, all right, you could have that workflow, you could have the compelling, you could be building the right thing and delivering it regularly, but if all the people are miserable and they're afraid and feel like they can't speak up, you've got other problems there. And so I think at the end of the day, you need to have the customers, you need to deliver to them regularly, and you need to have people who are excited to come to work each day. So you've got to focus on the people, you've got to focus on all these things, or you have nothing. So if the people are miserable and they feel like they're pawns, and they're, you know, oh, they're moving us around, and they have no excitement about what they're doing, that's not going to work. So you've got to have the people who are learning and engaged and want to come to work each day. And they're treated with respect. They feel safe to express their opinion. You need to be building the right thing that people want to buy. And if you don't have that, well, you're going to fail. And then you need effective ways of working in the team so you get stuff out the door. So I focus in these three areas that you really need all of them. You need the people, the work, and the workflow. I write in the book about---it's great to find out as early as possible if you're going to succeed or fail, so you want to get the stuff out there quickly. Like the book Accelerate. You want continuous deployment. You want to find out as soon as you can if you're going in the right direction for the customers. Are you building that thing that's really going to change their lives and they're going to want more and they're going to keep being your customer? You don't want to find out after a month. You don't want to find out after 3 months, 6 months. Those delivery timeframes are too slow. So you want to be able to continuously deploy, you want to be able to bounce back, because you will have outages. But developing these capacities, and there's metrics that go along with them, is really important for the topic of delivery. But you could have all of that, if you treat people like crap, you're going to fail.

[00:41:43:851]

As we kind of wrap up our conversation, what overall advice would you offer for leaders who are trying to figure out the right reteaming strategy?

[00:41:52:316]

Yeah, I think whether we like it or not, reteaming is inevitable. People are going to come and go. You might as well be prepared and get good at it. And so what does that mean? You've got to know how to plan and execute and learn from a large reteaming initiative. You have to get good at this at different levels. You've got to put the people first. And yeah, I mean, this stuff is not easy. A lot of the times we're doing the best that we can, and things are hard, so you've got to learn from it. You've got to have the feedback loops so you develop a learning capacity to morph your organization continuously. If your goal is to build a successful, large, flourishing company, you need these tactics so that you develop resilience and so the people want to stay working at your company. You've got to put the people first, got to include the people. I think that's the key message. Be inclusive.

[00:43:08:744]

Thank you for listening to All Hands on Tech. we included a couple links in the show notes, including to Heidi's book, Dynamic Reteaming, and a link to the webinar in which she was a panelist. Thanks again, and have a great rest of your week.