Dynamic Reteaming with Heidi Helfand

Episode 18

The only constant is change.  Heidi Helfand knows a thing or two about changes in organizations. From re-teaming to re-organizations to just shuffling a member or two, in this episode we’ll learn how to think about these inevitable changes and what to do when they happen.

 

 

Show Notes

• What are some of the kinds of change that a team might undergo?
• Dynamic reteaming comes in these five structural patterns
• The metaphor of the eco-cycle
• Different types of mentoring
• What does it mean to have a “successful” team?
• Inner and outer roles
• A recipe for disengagement

Links:

• Heidihelfand.com
• Book: Dynamic Reteaming
  • Amazon
  • Leanpub
• Twitter: @heidihelfand
• Sponsor: GitPrime

Transcript

Announcer: Welcome to the Programming Leadership podcast where we help great coders become skilled leaders and build happy, high-performing software teams.

 

Marcus: All right. Welcome to the show. I’m Marcus, and this is Programming Leadership. I am so excited to heave Heidi Helfand joining me today. Heidi is the author of Dynamic Reteaming, and that’s the topic. We’re going to talk about how we use our teams differently and better, and frankly, as I’m a neophyte, I’m just so excited about this. Heidi, welcome to the show.

 

Heidi: Hi, Marcus. Thank you. So happy to be here.

 

Marcus: Thank you. Well, look, let’s just dive in here.

 

Heidi: Okay.

 

Marcus: So the name of the book is intriguing, and the book can be found on Leanpub, Dynamic Reteaming, but okay, let’s just step back. What is this thing called dynamic reteaming?

 

Heidi: Well, in essence, dynamic reteaming is team change. Teams change. It’s a natural occurrence as opposed to staying the same forever. So yeah, the book goes into details to really expand on this topic and explain what it is.

 

Marcus: So what are some of the kinds of change that a team might undergo over … You’re right. Nothing stays forever. So let’s say over a period of time, a year, or I’m imagining it to be measured in years. What kind of change are we talking about?

 

Heidi: I have been a part of different startups that have grown larger, and so a lot of my experience, I’m at the third company now. I’ve been at three very successful companies from an early employee to hundreds, thousands of people, and what I’ve noticed is that a lot of the literature that I would read in my roles, I started out in UX, got into project management, got into coaching throughout the years, and one of the things I notice is the best practice for effective teams I would read about it, and it would say keep your teams the same or stable. And then looking back on my experience, I thought, “Well, my experience has been different. There’ve been a lot of changing teams.”

 

I became curious about that, wrote the book, Dynamic Reteaming, and did research along the way, not only from personal experience but from interviewing colleagues around the world. I found that team change happens really in five ways, there are five patterns to team change, and I think these are basic structural patterns. The book goes into detail about these as well as why does this happen, why do your teams change. It could be as little as you have a team and someone new joins, or you have a team and somebody leaves. I call that the 1×1 Pattern.

 

Another pattern is what I call the Isolation Pattern. Maybe there’s an emergency in the company, maybe the code isn’t performing as we expected, there’s some kind of crisis, or maybe we have to move really, really fast and build something and get it out there and ship it, maybe we have a competitive pressure or something. So what you can do is you can form a team, put it off to the side, and let them run fast and give them process freedom. I call that the Isolation Pattern. That’s the second pattern.

 

Another pattern, which is very common in companies that scale or grow bigger is what I call Grow and Split. You have a team, more people are hired in, that team gets kind of big, and it splits in half, and then you have two teams. It can happen at larger levels, like divisions or orgs. You could have a whole R&D organization split in half. I’ve seen that.

 

Then there’s the opposite of Grow and Split, which is the Merging Pattern. You have two teams and they come together for a variety of reasons, and now they’re together as one team. So that’s the fourth pattern. The last pattern is what I call Switching. This is an exciting one, because we as humans sometimes need a change. Maybe we want to work with different people, maybe we want to learn something different and we want a different opportunity, so maybe we switch to another team.

 

So what I’ve found is that dynamic reteaming comes in these five structural patterns, 1×1, Isolation, Grow and Split, Merging, and Switching. In essence when you’re at a company and you have a lot of dynamic reteaming, it means that a lot of this is going on at once. I look back at my experience here, two years Procore Technologies, all of these patterns have taken place in some way, shape or form. And they happen at different levels, so we work in this kind of ever-evolving complex system. There could be changes that feel very small, or one person in, one person out of a team, for example, or even like a Switching pattern is a smaller reteaming. Then you have the teams that grow big and split.

 

You can have all of this stuff going on, and the system, the whole company can feel very dynamic. These are reteaming patterns, and they’re dynamic, and they’re all happening at once all over the place. Depending on your company, maybe you have more change, maybe you have less change. Sometimes, you don’t want it to happen at all, and then it does, it’s imposed from the top for a variety of reasons. It’s probably not going to-

 

Marcus: The great re-org.

 

Heidi: A great re-org. Or you acquire a company. It’s not necessarily going to be the decision of the people whether this happens, and it’s just not appropriate. So sometimes the changes happen, and then we deal with them. Other times, we catalyze the changes. Maybe an individual needs something new, so you coach the individual. Or maybe the squad, the team, they feel like they grew kind of big. “How could we be more effective?” I’ve seen things like that. The book talks about all these different things.

 

Marcus: That’s really interesting. Can I interrupt you here for a minute because my head is spinning.

 

Heidi: Definitely, and please, cut me off, because once I get going with this stuff, it’s one thing leads to another.

 

Marcus: I want to take just a moment and thank my sponsor, GitPrime. GitPrime has sponsored the show, not just because they’re fantastic people, but because they really believe that leadership in engineering is about people. It’s about conversations. And get prime is a platform that allows you to have better conversations with people. Yes, it has lots of other benefits. You can probably plan better. You can see metrics about individual performance, but let’s just take that one idea about individual performance. Whenever I talk with a GitPrime user, and by the way, lots of my clients are get prime users, they always tell me how surprised they were at what was really happening on the team. See, it’s really easy for you as a manager to observe generally how people are working. You can look at PRs, you can look at who’s assigned, what tickets you as the CLM, the software engineering manager.

 

You get a notion for what people are doing, but there’s always these beautiful surprises about who is really performing well and who’s secretly struggling about who’s the person that saving everybody’s bacon through fixing a lot of stuff behind the scenes and who is absolutely doing all the PRs. This kind of data lets you move from looking at people as just, “Well, they’re all engineers and they’re all kind of doing engineering work,” to seeing exactly where each one of them is strong and has opportunities to grow and that’s why I love this tool so much. I believe that new and surprising conversations come out of data that when you can sit down with somebody and start to understand and intuit why things are happening, you’re going to create even better quality of exchanges. And by the way, you know here on this show we talk about the fact that leadership is what keeps people connected to their work and prevents turnover and keeps them motivated. It’s about the relationship. I like to say they get prime not only lets you build better software, it lets you build a better relationship with your team members. Start a free trial today at gitprime.com.

 

Marcus: No, my head is just spinning with questions. So from one perspective, I see that there’s kind of systems thinking perspective. This almost sounds biological. You think about your skin cells flake off and they regenerate. Maybe that’s a 1×1. And then maybe you think about … I was thinking about how cells grow, and then they divide, right? There’s your Division. And sometimes, they come together. I don’t know. To be honest, my sister has cancer, so we think a lot about that kind of cellular system where part of it runs off on its own and grows in a really different way from … There’s complete process freedom here because there’s independence, Isolation, right?

 

Those things are just running through my head. Those feel like patterns maybe we see in other parts of the world or of our lives as well. But I want to hit on something and ask you a question about something you ended with, because I could imagine that a lot of people listening to this might say, “How do I prevent those things?” Because the mindset that what we want is stable teams. Now you started with that, and then of course for you that became a fundamental mindset that you change. You said, “Is that true?” and you found out it wasn’t true. So I’m curious. Is that a problem or a mindset that many people have is that what we want to do is create stability and have the impression that nothing should ever change?

 

Heidi: That’s a good question. I think it’s been part of the narrative that effectiveness is tied with that, and I remember looking at that and thinking, “Gosh.” The first company I was at I was on the original team. We invented Go To Meeting and Go To Webinar, and then we were acquired by Citrix for a great amount of money. And then the legacy of that company was acquired, was it a couple of years ago now, by LogMeIn. We created a lot of value there, and we grew and we changed. We weren’t doing it wrong. We weren’t stable and staying the same and not growing and changing.

 

And then I looked at the second startup, AppFolio, which is a software company, another software is a service company creating software for property management companies and for law firms to be more effective, workflow software. I was the 10th employee at that company. I left when there were about 650 people. We grew and we changed a lot, and we had a lot of dynamic reteaming happening. Then we went public in June 2015, the stock is traded on the NASDAQ, it’s a very successful company. That company didn’t have fully stable teams either.

 

So when I would read some of this literature, like by Hackman. He wrote a book, Leading Teams, and I appreciate the research and I respect a lot of the research, but I looked at that, and I was like, “Wait. If …” I remember at one point another Agile coach and I, Paul, we were like almost trying to fight some of the changes that were happening, and it was really counterproductive to the goals of the company. We would read that the most effective teams would stay the same, but trying to really keep that as a constant was almost counterproductive. It was more effective to go at the change and try to be more effective with that change. So that’s where the shift is.

 

If people want to keep their team the same and they’re doing well and they’re shipping value and the customers are delighted and it’s an enjoyable experience and people are safe to express their opinions, keep that team the same. It’s fine to want to keep things the same, but it can be really counterproductive if your company goals are to grow and expand rapidly, globally, multiple-markets, 20 people hired next week. To try to be counter to that is not where I would focus. I would focus rather on “Okay. If you have these teams that are merging together, and then they’re reteaming on the priority of work, how do we make that more effective when the teams are changing to reform based on priority?”

 

Well, I would try to gel the whole team. So if we have teams that are merging, get that community to know each other, care about each other, and then the work later is easier. Come with some team norms that we can replicate across these different teams, so that when we change there’s still some constance. There’s a, I think we pronounce her name Ruth Wageman or Wage-man, Wageman, she writes about, she’s at Harvard, she writes about having role clarity. If you keep the notion of the role constant, then when teams change there’s that scaffold in there that it makes it easier for the people. So I think it’s like let’s acknowledge that if we’re in an environment that has changing teams, we can do things to amplify and get better at that as opposed to focusing over here trying to keep it all the same. It’s not where I would focus. So I had that insight and dug into that with this book. “Well, how do we make it easier? Things are going to change.”

 

Marcus: I think that that fundamental idea of things are going to change, I’ll use another metaphor now. It reminds of when we were raising our kids, because when you look at your kids at any point in time, especially when they’re grade school or something, you think, “Oh, this is exactly where we’re at, and it’s probably going to be like this forever, and I really wouldn’t want it to change too much.” So as they grow up and the system of the family starts to necessitate some change, sometimes it’s very hard. And some people in the family want things to stay the same, like mom and dad. And some people in the family want things to change, like an 18-year-old son who is just itching to get out of the house and onto his own.

 

Heidi: Right. There’s that kind of tension there.

 

Marcus: Yeah. And so what seems like if … But I guess looking back on it, I can recognize that I wish I would’ve seen the circle of life. And I think imagining man, things are going to be changing, and instead of pretending that they’re not, maybe this, you mentioned been at Procore a couple of years and you’ve seen all these patterns, I could imagine that instead of pretending they’re not, which is a common thing, or wishing they weren’t, I feel like you’ve got these really great ideas for how to make this change less painful and how to, I don’t want to say create change for change’s sake, but how to just be sort of real, get real with the changes that are occurring. I was curious. Does it feel … Go ahead. What are your thoughts on that?

 

Heidi: I don’t know if you noticed in the book. I use a metaphor. You were talking about biology earlier. I use a metaphor of an eco-cycle. I’m just kind of holding up the photo of an eco …

 

Marcus: I have seen that. By the way, if you’re listening to this at home, we’re sharing video, and we’re both very animated. We’ll put a link to that picture. Maybe she’ll allow us to scan it in and put a picture with the show notes. Go ahead.

 

Heidi: Actually, your listeners can have access to a chapter from my book, and I believe this picture is in there. It’s a photo of an eco-cycle.

 

Marcus: Thank you.

 

Heidi: Yeah. It’s at my website, heidihelfand.com as well. But a metaphor for team change is really like an eco-cycle. You were just talking about growing up in a family, so you have birth, adolescence, maturity, and then we have death. Birth, adolescence, maturity, death in this eco-cycle, which I learned from friends in a community called Liberating Structures who learned it. He loved Liberating Structures community.

 

Marcus: I love this.

 

Heidi: Yeah. Keith McCandless and Fisher Qua, a wonderful community. Henri Lipmanowicz, they wrote a book called Liberating Structures. They apply this eco-cycle concept from these researchers that wrote a book called Panarchy, Gunderson and Holling. Anyway, an eco-cycle’s a really great way I think to look at teams, because I think in the beginning of this podcast, I was like, “Teams age and change.” You’ll have the birth phase of a team. Maybe they’ll get into adolescence, and then who knows? They’ll go through and they’ll have a disruption, almost like the death of a team. Teams disband, teams dissolve, or sometimes they change. They get disrupted. Suddenly they have three new team members that join, and then you have to integrate them in the team.

 

Heidi: I’ve found that team change is a natural occurrence. Again, sometimes we want it to happen, sometimes we don’t. There is a tension. Some people might prefer more change, some people might not. You were talking about raising kids. Maybe the adolescent, the teenager wants more change than is present right now. I have a teenager.

 

Marcus: So maybe that sounds familiar.

 

Heidi: Yeah. So I think it’s a useful lens or metaphor. We have, looking at forest ecology, when you have a forest that grows really, really dense, sometimes it gets disrupted with a wildfire, new seeds are emitted, and then there’s sort of a renewal. So I think teams can get renewed as well when they change. People can for sure. If you’re stuck on one team and you’re there for two years, you might really, really want to change. And then once you get it, you might feel a sense of, “Wow. I’m reinvigorated.” And it could be because of the content, it could be because of the people.

 

Marcus: It reminds me there were a lot of times when I would have teams as a manager, and we would hire a new person, and this is kind of your 1×1 Pattern. So we add someone. But I, as the manager, neglect to understand the real impact of that. I think, “Well, the team hasn’t changed. It’s still called the Web Team. What’s really changed? It went from 5 people to 6 people.” But in some ways, that was a really small-minded or immature view of what was happening, because that was a form of dynamic reteaming, and yet I didn’t really acknowledge it and I didn’t have a way to understand it, so I pretended it, quote, wasn’t a big deal. My team members didn’t always feel the same. Do you have suggestions for how we can introduce like a 1×1 change in a way that is less chaotic or maybe feels more safe?

 

Heidi: Yeah. Definitely. It’s almost like a reteaming at the edges. It’s like a smaller kind of reteaming that’s less in your face than if a team totally busts up and the people are reallocated elsewhere, which is a lot more severe. I think it starts way back to seeing a need for hiring. Maybe the team feels like they want to have more people join or maybe it’s someone else’s idea. The team needs to know about the hiring and have participation and a stake in it, I feel, makes it easier. Maybe they participate in the interviews. They have a stake into who they’re bringing in their team. That is, I think, a really good kind of lead-in.

 

If you think the experience of being an employer, let’s just talk about software engineer. If I’m interviewing and then I get hired in by people that I get to work with, they’re hiring me into their team. Now, my experience starts right when I apply, and then maybe it ends eventually when I leave, but there’s a user experience there like we do for our customers, but let’s look at the engineer experience.

 

I’ve seen for years people have mentoring systems where with pair programming you help to bring an engineer up to speed and help them get set with their dev environment, learn the customs and the norms of the place. Maybe if you hire, you have a few people at once, you get them together to do some of the shared tasks, and then get them off with their mentor. Shared task meaning if you have three people start in one day, they could probably get their dev environment set up together with a helpful person as opposed to duplicating that effort. That’s one of the things that we learned at the second startup that I was at.

 

One-on-one mentoring, we used that pattern for many years at the second startup I was at and then had more formal onboarding. Procore, we hire a lot of people at once. We’ve had very large hiring classes lately, and we have a very sophisticated onboarding program. They announce all the hires on LinkedIn and show photos of the classes of people coming in, and we meet with them during our lunch. We have a company lunch every Wednesday. And people get integrated into the teams. We have onboarding that’s within our engineering group, product management, whatever group that they’re, we have another onboarding program. It’s very predictable how we do it at Procore. We’ve gotten better and better at it. It’s very collaborative.

 

I think the other thing with onboarding new team members, I was with a team the other day, and some might think, well, to be a mentor of a new hire starting, maybe I need to be at the company for a long time. I remember even at the second startup I was at, we found that someone that has joined and has been here a couple of months can make an excellent mentor to someone else, because they’re closer to that experience of being a new person. They might have a different sort of empathy.

 

Marcus: Right.

 

Heidi: Sometimes I think people might want to limit. A mentor has to be at the company for a certain amount of time, but I would challenge that. It’s a great path to becoming maybe even a manager if you become a mentor, and so you can gain skills to support people.

 

Marcus: I agree.

 

Heidi: There’s that. If you have a team that is set, and you add one new person in, it’s almost like the entrance of that one new person might not drastically change the processes in place. We do have a new team system though, because that new person brings new ideas, their background, their personality. Depending on how maybe introverted or extroverted that person is, it could feel like a really big change if they’re a larger-than-life person, very vocal, or it could feel like more of a quiet change coming in. With the 1×1 Pattern, it’s more about bringing a person onboard. I guess they call it onboarding. You’re bringing them on the boat. The boat isn’t really changing that much.

 

But sometimes when it’s more than one, it might get the whole team to talk about, “Well, how do we want to be together as a team, and what does success look like?” It’s really a good opportunity to reset your team. Even if you feel like it’s a small change, it’s a good point in time to get the whole team together at least for two hours and talk about what does it mean to be a successful team, who are we as people.

 

I’m working with an engineering manager tomorrow who’s doing a market of skills activity, which people get together. The idea, again, these are two teams that are merging together. Two or three teams in this case, it’s a Merging Pattern. We have a new community of people coming together. “Well, who are we?” If you can gel the whole … You know, forming–storming–norming–performing, Tuckman Model, right? If you buy into that, and it’s a catchy model, maybe if you have a community of people that’s going to reteam according to different initiatives and you know that’s going to happen, just try to get that whole community of people to know each other, and then later the switching is easier.

 

So we’re doing a market of skills where people come together, they each make a poster, and they share. “These are my hobbies, these are the skills I bring to the team, this is what I want to learn in the next few months, and this is what I offer to teach you.” It’s a very quick way of sharing the basics about ourselves, it breaks the ice, it helps people find common ground, and then I find doing things like that, again depends on what the team wants to invest. I don’t hold teams hostage in any stay with me for two days and we’ll gel your team. That’s expensive, it’s not realistic. We’ll spend a couple of hours, maybe do an activity that resonates with the team. I always kind of test it out. “Hey, do you want to do something like this? Yes or no?” And “Oh, well, what about this?” We’ll find something, get together for two hours, foster the relationship building, and then it really goes a long way. That’s some of the real stuff that I do here.

 

Marcus: I love it. I’m imagining one of the teams that I’m sort of just remembering back to a time when I brought someone in to the team, and I didn’t recognize that there was a team change, because it just seemed like adding one person. My assumption was that the one would conform to how things were. “Well, we were already a team. We were doing things.” I think there’s a sense of that. The one is doing the conforming to us. But what I didn’t really ever ask was what does it mean for us as a team now that we have a new member?

 

And I think that same thing happened when one left. I thought, “Well, we’re down one, but it’s not that big a deal. We’ll just keep doing things.” But had I gotten the team together and said, “What does it mean for us and how do we want to work together now that we’re smaller, now that we lack that person’s perspective, now that we don’t have their skills?” I think the team may have said, “Well, you may not be aware, but these four things that we do, that person was really internally leading the charge on, and maybe we need to either alter how they’re doing them, or someone else needs to decide to step up, or we need to ask if it’s still important.” But I never did that. I made the assumption that things were just going to stay the same. I think that was …

 

Heidi: Well, actually, in what you’re talking about is super important, so that’s the other part of the 1×1 Pattern, people leave, and talking about that and acknowledging it is critical. I was with a team, I don’t know, 4 or 5 months ago, and it was a team that had split in half. The product manager had left to go to another opportunity, and there was a new product manager coming in. So I was there to help reset the team in that situation, and we talked about, I learned this from Organizational Relationship System Coaching, which is ORSC. The company is called CRR Global. Yeah, crrglobal.com. So I’m trained in coaching teams as systems through ORSC. They have wonderful coursework in coaching.

 

Anyway, one of the things that you do is you acknowledge the change, that person left. This product manager, a very unique character, very inspiring, he would do things that were out of the job description, like many of us do. ORSC calls those inner roles. So our outer role is our job description. I am a software engineer. I do these things. An inner role is something that you do beyond your job. So this product manager, one of the things that he would do, and I learned this when we were doing the reset and talking about his departure, one of the things that he would do is when they’d accomplish a goal, he’d take them over to the cliffs where Procore is located right next to the Pacific Ocean in Carpinteria, California, and we have this, we’re on an ocean-side cliff. It’s very picturesque. He’d take then to the cliff, and they’d scream off the side of the cliff. And they’d do that to mark different milestones.

 

It’s like okay, you have traditions that start in teams, so what do you want to continue on and who’s going to own it? So we came up with a list of things that this product manager did that we wanted to have live on, and then people own them going forward. If we didn’t have that conversation, maybe these things, like you throw a ball and it bounces away, maybe these things would’ve just left. But they decided that we’re going to keep doing these things, and these are not things, again, in a job description.

 

When I was at the first startup, and one of our founders left, it was a very, very difficult situation. I remember giving a talk about this, and it almost brought tears to my eyes. It was just like that he left, and it was so hard. And people tried the best that they could to understand all the things that he did beyond the role of he was our CTO. This was at the company where we invented Go To Meeting. He had so many inner roles and so many things that he did that we couldn’t even really write down that. It just made it harder.

 

I think acknowledging the change is really important. Talking about it with the team, especially if you’re in a situation where someone gets dismissed for whatever reason, you need to talk about this hard stuff. When I was a consultant, I was with a company, and there we’re a lot of people that got laid off. It was at a different company. I was consulting up in the Bay Area, and having a sprint-as-usual and having a regular sprint ceremony is they’re not really acknowledging this big change around you feels really awkward. But it takes courage to sometimes have conversations about people leaving, especially when it’s a lot.

 

This stuff isn’t easy, but I think as humans we need to process stuff, we need to talk about it, and then we need to say, “Okay, now we’re moving forward. What do we want that to be like?” If we don’t talk about stuff, I think it can fester and lead to things that aren’t so desirable. So I’m a big advocate of talking about the challenging stuff.

 

Marcus: Good. Two things come to mind. My friend Jerry Weinberg once told me, “Just don’t pretend that it didn’t happen.” And I have that written here on a little card, and I’ve remembered that for a long time, because I have a tendency to want to, especially when it’s hard stuff, pretend it didn’t happen. And the word pretend stands out for me, because it sounds so darned silly and fictitious when I say it. But somebody leaves, and I can’t tell you how many times the way the team found out was an email. “Oh, an email got sent out. Bob’s no longer with us.” And that was the way I thought grown-up companies did things, because our legal department had said, “Don’t say anything. Just tell them they left, that Bob is gone, and you can’t talk about anything else.” Well, of course, maybe it would be disrespectful to talk about the details, but it was entirely silly to imagine that it hadn’t happened or to just continue pretending it hadn’t happened or that Bob was just a cog. You just have to go get another cog.

 

Heidi: Yeah. It can be awkward to have the conversations, so I think it’s really important. Even if you’re saying the case of you find out later through an email or this person left, it’s almost like you don’t have closure. We contact people on LinkedIn. We can try to follow up. “Hey, I loved working with you. I’m sorry that you left.” I was always try to personally talk with people if I’m ever in that situation, but even getting the team together and talk about, “Okay, we all know that Bob left. We got the email, we don’t have the complete information. Let’s just talk about that, and we can kind of then move on.” What does it mean?

 

Marcus: What does that mean?

 

Heidi: Especially also, and you can tell me if you’ve experienced this too, a lot of the times as companies are growing and changing in all sorts of ways, we’re dealing with partial information. We might not ever satisfy the curiosity of why these things happened, and I think it just helps to acknowledge it. And then you’re like, “Okay. Now what? Let’s reset, let’s move forward, let’s look forward. Maybe Bob did this one role, and we’re going to have to work a little differently until they hire somebody in to replace Bob.”

 

Marcus: Or maybe Bob did an inner role, and you can never hire someone to do that.

 

Heidi: Could be.

 

Marcus: So the team has to then make a decision. “Do we like screaming off the cliff? We now know how to do it. Do we continue? What does it mean if we do? What does it mean if we don’t? Maybe we never really liked it anyway, so let’s do something different.”

 

Heidi: Yeah. That’s the other side of 1×1, right? Sometimes we’re glad they’re gone. Depending on the person and the situation, maybe they were disruptive, maybe we had worse problems when they were there, so sometimes we’re glad they’re gone, and it’s a very real thing. People don’t talk about this very much. Sometimes when I’m giving a talk I have a picture of a ghost, so like a ghost role. Sometimes they linger on like a ghost. It takes a while to shake them off. It’s another ORSC concept, a ghost role. Sometimes they do linger on, and then after a while it fades out, and you’re onto a new normal. So how long is your memory of the person, how long were they disruptive? Hopefully, we all don’t. I have memories of sometimes we’re working and we perceive the other person as very challenging. Sometimes the punchline is that, “No, you’re the difficult one. Not that person.” But feels like they are.

 

Marcus: Everyone brings joy. Some when they come, and some when they leave.

 

Heidi: There you go. That’s reality.

 

Marcus: Let’s go back to … That’s reality. So I want to ask about the inner roles, because you mentioned market of skills. I thought that was a really beautiful, really cool way for teams to get to know each other. Do you advocate for teams to create an inventory of inner roles or to talk about those things in a more open way, because maybe there’s things the team really depends on, and the team norms and cultures are undergirded by screaming off the cliff or something? Is it something we talk about or are inner roles just something that we just know are there and maybe we shouldn’t openly discuss?

 

Heidi: I think it really depends on the situation. How do I provide value as a person coaching teams? I have an inventory of all these different activities that I can do, and I come across a situation, and then I might make an offer to a team. “Hey, maybe we should do an activity around inner roles because of this. What do you think?” And they’ll be yes or no. So that’s how I operate. I don’t have a set thing that I do at every exact team, because I think teams have different needs, and you want to do things that are appropriate, so it’s not like poorly done foreign aid. So you want to make offers and see if they resonate to get teams from here to there.

 

Marcus: Because people should elect to do things. You’re not going to infantilize them.

 

Heidi: A lot of the work that I do I function at Procore like an internal Agile consult/coach, so I’m pulled in. I work on more of a pull system, and then I make offers, see if they resonate, and then I deploy this service. I don’t know if that answers your question or if I meandered away.

 

Marcus: No, I think it does.

 

Heidi: Sometimes I do an inner roles thing, usually if it’s somebody left and what do we want to carry on. But you could do it when you have a team that’s starting up again. Or you could do it with …

 

Marcus: I’m imagining even teams that have now worked together for a year, they have a culture, some norms, but that doesn’t mean they all understand what contributes to those things, even though there’s a lot of unspoken bits of support and relationship and things like that that happen. Maybe I’m just latched onto that idea. I’ll do a little bit more reading.

 

Heidi: I will say that I did work with a coach who he would have the teams invent inner roles that they wanted to occupy going forward as their team, like somebody’s going to bring the bagels on Tuesday, or someone will get the donuts, or somebody will get us all together for stand up. Maybe it’s not in their job description, but it’s something that they wanted. But you can invent them.

 

Marcus: I think I’ve heard of teams that do something where it’s like what’s your secret identity, like, “We’re superheroes,” and so yes, the job description. “On the outside, I’m a Rails engineer, but inside, I’m the team cheerleader, and I’m going to be the one who’s always trying to give everybody high-fives and be the encourager.”

 

Heidi: Yeah. It could be a very creative activity to do with the team.

 

Marcus: But at the end of the day, what you keep bringing me back to that I really appreciate is that if we invite people to things versus forcing them on things, generally, the invitation may or may not be accepted, but someone who comes with an invitation is there willingly versus someone who says, “Oh, I had to sit through this silly thing. No one wanted to be there.” Asking the team, “Do you want to do this?” feels like a really important first step that I think lots of management, managers and management structures tend to skip over.

 

Heidi: Yeah, that’s a big part of my philosophy just as a consultant and coach. I call it “Throwing Spaghetti on the Wall”, and that’s basically how I get work internally. I make offers, I network, I get to know people, I understand what they’re going through, I ask about their teams, I get curious, so I was like, “Hey, what do you think if I came in and we spend an hour and we did this?” And sometimes it works and sometimes it doesn’t. So it’s like that sometimes the spaghetti sticks on the wall and sometimes it falls off. I think it’s just what intuitively makes sense to me, and I also have a bias, more of a bottoms-up, power-to-the-people bias that I have a hard time forcing people to do things.

 

Marcus: Amen.

 

Heidi: It’s hard when you’re a manager. I’m not a manager right now, but I have been one in the past, and if people feel like they’re volun-told by a manager when a manager’s like, “What do you think if we did something like this? No, really, I want you to say yes or no,” but then people might just do it because you have that rank. So I find that yeah, I think I have greater success when I make offers. People take them or reject them. It’s hard for me when there’s top-down forced changes that people don’t want. I have a lot of empathy for that, because I just want people to be excited and fulfilled in their work.

 

Sometimes, though, I’ll have to say, even though I don’t like saying it, sometimes people are forced to go through a change, and then later they like it. Sometimes we don’t know. But other times, we really want that agency. Especially with reteaming, people can have different experiences with it. Sometimes you’re subject to a top-down change, and suddenly you’re over here, and it’s really bad for you. Sometimes it can work out, but I really think it’s better to include the people in it.

 

And it’s why in the back of my book I have a couple of activities with how do you include people when you’re doing larger scale reorgs. We did something here, more than a year ago, where there was a reorg with about 80 people, and the engineering leadership visualized their reorgs on white boards and offered people the opportunity to switch teams if they wanted to. They visualized the hiring. It was more of an open, inclusive type of reteaming. There’s a great book called Creating Great Teams by Sandy Momoli and David Mole, where they talk about having a marketplace for self-selected teams. So there’s degrees of freedom in reteaming, and it just depends where you’re at and what you’re up for. I really also like-

 

Marcus: I’m writing down all these books.

 

Heidi: Yeah. I could give you this list of books too. There also in my book in the back. I just love it when a team reflects on their own structure and determines the way that they want to shift their team composition in the pursuit of excellence or in the pursuit of being more effective. So when it’s initiated by the team, they own the team change, and I just think that’s one of the coolest things ever, because I think it’s forgotten from Agile. Team change has always been such a constant in the Agile world that when you open it up as a lever for teams it could just be super powerful.

 

Marcus: I love that. What you’re talking about also reminds me of everybody has these different experiences. The Satir Change Model talks about how we resist change and we get thrown into chaos. I was talking to somebody the other day who said, “This is the nth reorg in five years, and we’ve been in nothing but chaos. Every new CIO comes in and institutes the new way, and of course the people at the bottom are just like we’ve stopped caring. It hurts so bad. We’re just numb, and the reality is that we’ve had nothing but change for five years, so I’m not going to get really attached to anything.”

 

And at that point, I almost get kind of a PTSD smell of trauma. You just cannot convince this person, and I feel bad for the new CIO who’s come in or something. They have all the best intentions, but the reality is is that this team has been so hurt by the constant rate of change and the way change has been forced on them that I doubt that that CIO will be very effective. And it’s not their fault, but because they don’t recognize it, they don’t step back and say, “Let’s just stop all the change. At least let’s not make any structural changes, and let’s figure out where we’re at, because everyone’s disoriented.”

 

Heidi: Sounds like a lot of reteaming by abstraction. The people making the decisions are way up here. The people feel like they don’t have any agency, and it’s a lot of thrash that’s happening over and over and over. Yeah, that’s a recipe for disengagement right there. I think people need to feel like they have ownership, that they can contribute to the development of the organization, and I feel very strongly that we can have collaborative organizational development. Recognizing that can really be a super power for your company if you include the people.

 

Marcus: I love that you said, “Why not give the team the change lever and be asking them, ‘What do we need?'” Maybe it’s uncomfortable to say, “What would we subtract?” but the reality is is that what we thought we needed when we started may not be all that we need or it might be too much that we have. When I usually go on a long car ride, I pack as best I can, but invariably some of the stuff I brought I won’t end up using. Maybe I’ll throw it away or maybe I’ll just keep it in the trunk. But I think that ability to change is what brings excellence in …

 

Heidi: Yeah. In the book there’s a story by Kristian Lindwall, who’s with Spotify in New York, and he talks about giving the people the ability to choose teams. It’s where my company learned how to reorg with whiteboards when we did it that time. He did it at Spotify with the infrastructure tribe he was working with. He said, “Why not give the problem to the people? We’ve solved more difficult problems as engineers before.” I always remembered that because it’s how respectful is that? We can have some opinions about how to change our org, and it impacts our code. If you believe in Conway’s Law that the organization of the people and the communication between the people is mirrored in the code, why not give the artisans, the crafters, the people that are making this incredible software for our customers, why don’t you give them participation in how we’re going to grow and change? I feel really strongly that to include the engineers. Then as people become-

 

Marcus: I love that.

 

Heidi: The people become engineering managers or architects or whatever, they become the people that are going to make team change decisions. It’s like, “Well, don’t forget. Don’t forget your including the people.”

 

Marcus: Well, Heidi, thank you so much for being on the show. This last phrase you said is going to ring through my head. “Why not give the problem to the people? We’ve solved harder problems than that.” Heidi, where can people find you and the book online?

 

Heidi: Yeah. So the book is going to be on Amazon.com in August, and it’s also on Leanpub. You can find me at heidihelfand.com. My Twitter is @heidihelfand. You can email me, heidi.helfand@gmail.com.

 

Marcus: Wonderful. We’ll include all those links in the show notes. Thank you so much for being on the show with us today.

 

Announcer: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com and on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening, and we’ll see you next time.

 

Announcer: This has been a HumblePod Production. Stay humble.