 Well, we'll see if it continues to work, and if it doesn't, we will fix it. All right. Hi. I'm Heidi Hellfand. I'm really, really happy to be here. It's my first time in India, and I'm having a fantastic time. I actually met with a friend and co-worker that I worked with 20 years ago at a company, and I was so delighted to meet her and to be here and to explore your wonderful country. So thank you so much. I'm going to be talking about a topic that I call dynamic reteaming. This is a talk about team change, about when teams change for a variety of reasons, and I call it the art and wisdom of changing teams. It's also the name of a lean pub book that I have, which you can find out about later. But as we get started, how many of you have heard about this model for team development? Raise your hands. Kind of catchy model, Tuckman's model came out in the same time frame as Waterfall did, so very hot to have linear frameworks, right? Maybe things are a little more of a loop than just forming, storming, norming, performing, adjoining. It's a useful model. We get teams together, and we want them to gel. We want people to work together well, and I think it's been useful. Not many people know that there's actually a missing stage in Tuckman's model, and it's a stage called stagnating, and that's when teams are together for too long. Not enough new information comes into the team system. People might be sick of each other. Now I didn't make this up. This came out as part of the research that I've been doing on team change. Let me play a little video for you with a few participants that brought this up. When they all talked about stagnating, I was like, whoa, this must be a thing. I've been doing this research to derive patterns on team change. I've been interviewing people at different companies for almost a year now. Anyhow, let's see what this means. This is Bryce, and he'll tell us a little bit about stagnation. You just get new perspectives working with different people. Those new ideas, unless you actively have a source of input to your team, like you're reading books together or something, it's going to stagnate over time. Having someone else, getting experience working with other teams, allows you to bring something new. Even if you're not leaving your team or joining the new team, if you can work with other people periodically, then you have a source of input for new ideas. When you mix it up with completely different people that you've never worked with before, and you've actually, none of your teammates have ever worked to get before either, then you have really different, I mean, even hotkeys. You're like, oh, I didn't know that it was that key mapping there. If the team stays stagnant, the abilities you have stays stagnant, but we have people on the global engineering team for a reason, right? They're good at certain things, they're good team members, and so mixing that up all the time is important. Yeah, so I was like, whoa, they're all talking about stagnation. It seems like a missing phase in that model, and that's the origin of that slide. Now let's continue. So Brene Brown wrote a book called Daring Greatly, and she uses a research methodology called Grounded Theory. It's a qualitative research methodology in which she interviews different people, has the interviews transcribed, and codes the transcriptions for themes, writes about the themes. So she wrote this book, Daring Greatly, and it was about the topic of shame, but she had no idea she was going to be writing about that topic until she gathered the data. So this was inspiring to me. I thought, you know, I would love to dig into the topic of team change in greater detail, and so far I've interviewed about 30 people for about 30 hours, had the interviews transcribed, and so what you'll see in this talk is not just kind of my, it's not really my random thoughts about the topic, but it's based on this data. I was trained as a linguist, and what we would do in linguistics is we would get data sets from different languages transcribed into the International Phonetic Alphabet, and we'd study that data to derive themes, and we'd write about the patterns that we saw. And so it's kind of what I'm doing here, but with people about team change. But I always heard, like, in the software industry, and I've been part of two successful startups for the past 17 years, I've been in software industry 17 years, and I thought I was trained as a teacher. I taught English as a second language, I have a master's in teaching. And I always heard, like, keep your teams the same. Heidi, the best teams are the ones that are stable, and I think this has always been, a lot of the times it can be misinterpreted to me and keep your teams the same. Don't change them, and I think, you know, so I got curious about that because I was part of different companies in which teams changed a lot. And so I think it's different from keeping teams stable as the goal. It's more like, how are the people doing in the teams that they're in? So kind of shifting their perspective a little bit. Are people fulfilled in what they're working on? Are they in the right place right now for the learning that needs to happen for their own development, and is where they're at kind of fit for purpose for what the company needs right now? So we might change teams for fulfillment. These are some software engineers on an overnight tech retreat designed to foster relationship building so that later when they change teams, they know each other a bit more. So if you change your teams, you know, you're not doing it wrong. I think it can be the secret to your success. This is a startup I was part of. It went public June 2015. I was the 10th employee. I was with this company from the first team, hired as a Scrum Master Agile Coach. And I left when the company hit 600 people and went public. So I was with one to 30 teams. And so when people said to me, you know, best practice in Agile, whatever, is to keep the teams the same. I'm like, well, wait, we haven't been doing it wrong. This company is very successful. It's a thriving company. What's going on here? There must be something to it. You know, even here's a team from that company, the customers are so delighted with the software that they've delivered that the customers sent them a bouquet of cookies. So there must be something there. So dynamic reteaming is when you change up the teams. And, you know, I view teams as systems. Here's an 80s hair band, Van Halen. Anyone a fan of Van Halen from back in the day? Maybe one or two of you. One of the team members, band members left and placed it with this guy. And you could hear it in the sound. The sound was different. Maybe more familiar is this guy. Raise your hand if you know who this is. All right. Michael Jackson, right? So one of the other bandmates from Van Halen left and he paired up with Michael Jackson to play a very famous guitar riff in a song. Does anybody know the name of the song? Beat it. All right. Maybe that'll be my intro music at a later time. So it's dynamic reteaming with team chains. I'm not saying let's change up the teams really fast all the time. I'm not suggesting that. I think there's different business rates for reteaming. And it's a business decision. At certain points in a business, you might want to hire a lot of people. I remember at Apfolio, that's a startup I was talking about, we doubled in size more than two years in a row. It was a deliberate business decision to get in all these new people. So we had to integrate them into the teams. So there was a fast rate of team change. At other times, maybe it was a little bit slower in terms of growth. So you can tune the dial or step on the gas pedal accordingly. And then I think also as individuals, we might prefer different rates of change. And I think that's perfectly valid. You might have a great team that you're on right now. The chemistry is great. It's an enjoyable experience. You're delivering incredible things to your customers. Your customers are sending you cookies. Maybe you have a really great thing going. So you want to keep it together. That's fine. That's cool. Or maybe you're in a situation where you can't stand working with this person over here and you're ready for a change. That's valid too. So we might have different rates of reteaming. Some colleges have quarter systems or semester systems, shorter or longer. We might have different personal preferences for the rate of team change. A dynamic reteaming, it was kind of accidentally ambiguous when I was thinking about this, because you can reteam the dynamic of a team. If you've ever been on a team, again, and the chemistry isn't quite right, or somebody else might notice it, or maybe a teammate does, team member, you might want to deliberately change up the team. When we have recommendations that we don't think about critically like, hey, keep your teams the same. Keep them stable. Well, it could be doing a disservice to the human's present, depending on who's there in the room. So, you know, we have to, I guess, use our common sense and allow teams to change. But I think I haven't seen that as quite so open. I've seen in, you know, from Waterfall to Agile, maybe we allow more requirements to change or other types of changes. But it seems to be like the sacred thing that we have to keep our teams the same. And I don't think that's necessarily the case. So we need to tap into how people are feeling in our teams. We can, as managers, as coaches, as good teammates, we can pay attention to how people are doing. Does Joe look like he's miserable every day and he might leave the company? We might care about that and say, hey, Joe, how are you doing? And tap into how the people are doing. So they might need a change. And sometimes it might be, depending on the culture of the organization, it might be hard for someone to catalyze their own change. So as managers and as coaches, good team members, we can look out for each other, in my opinion. Because we want people excited to come to work each day. So I'm not saying that reteaming solves every problem, that if you have a problem with the dynamic, instantly break up the team. No, I think you should, like any other challenge we face, we can get curious about it. But I think it's something to consider. Because I think in the past, we've heard all this, keep your teams the same, keep your teams the same. But this is a valid option to consider as well. Maybe the team needs to get together like these people and talk about, these people are talking about their toxic team behaviors, whether they blame each other or stonewall each other, which is an interesting exercise. Maybe something like that would help. Maybe a retrospective. Maybe just two team members going out to lunch helps. Or maybe, you know, the team needs to be retired and people need to be spread amongst other teams. I worked with a team once. The product managers were afraid of the engineers on this team. Nobody wanted to work with that team. There was something there. So then we were like, okay, well, if we break up the team, is it going to spread that kind of feeling? You know, it was like a real fear. What are we going to do? We all wound up reading crucial conversations and doing some activities with that. And that team was together still for a while, but it was, oh, maybe we should split them up. So don't mess with geek joy. I think when teams have it really good, we want to keep them together. You know, if they're high performing, it's an enjoyable experience. They're building the right things for the customers. The customers are delighted. You know, whatever you consider success, delivering value continuously to your customers, you don't mess with geek joy. So how do companies do this? What are some of the ways? And so these are some stories from the research I did. I talked with Richard Sheridan, who is the chief storyteller and one of the co-founders of a company called Menlo Innovations in Ann Arbor, Michigan. And one way that they form teams and reform teams, they do a lot of pairing here, pair programming. Not only the developers pair, but other roles too, even non-developers pair. It's a very rich history and culture of pairing. So they form teams around the work. They do projects for different companies, more of a consultancy that builds software for different companies, and they actually manage their work on a table, and they'll have two people pairing, talking with the customer. They have this role called high-tech anthropologists. They talk to the customers about what the customers need, what the customers want, what they want to build. And in some cases, they will actually switch out whole pairs of people depending on priority and put new pairs in. Richard wrote a book called Joy Inc., which is a very interesting book about their company culture. It is a unique one, and inspiring to many due to their innovative practices. So another company that, at the time that I interviewed him, Seth Falcon, VP of Engineering, a company called Chef out of Seattle, in part. They had two-part team formation around work, and what that meant is they'd have a new project that came in. They would do this quarterly, and they'd get a software engineer, product manager, and a UX user experience person together, and they'd create an opportunity canvas, which is something described in the story mapping book by Jeff Patton, if you're familiar with that. And they would look at the type of work that they were going to build, and then they'd have another stage where they'd add team members that would be beneficial to solving the particular problems that they were going after. So kind of two-part team formation. So it wasn't this, you know, four developers here, one UX person here, one QA member here. They form the teams in a different way. So another example of how some teams form. Now, this one is, as opposed to having people go to the work, this is some people form teams, and then the work comes and gets assigned to the teams. More like maybe that's squad model where the teams might have a mission and the work comes to them. This app folio here with pair programming would have these kind of like a tribe model with tribes and squads, although they named them differently. And so the work initially was assigned to these teams. So they'd have like a squad, like Tesla here, or a tribe, Tesla here with the different squads, and then work was assigned to the teams. But then after doing retrospectives, they learned that the team members wanted more choice in their work. So they converted so the team members select the work from a series of thematic backlogs. So what's the best way? Do we do teams pull their own work, work gets pushed to teams, teams formed around the work? I don't know what the best way is, but we all have a way that we do it now. So we start where we are and we start reflecting on it. Kind of in the spirit of Kanban, we go from there. So this is a team having a retrospective. So feedback loops and retrospectives, I think are very important, not only in how we work together, but also in our team design. So who puts the people on the teams? So Sandy just gave a great talk about self-selected teams. And here's some team members self-selecting for a short-term hack day at App Folio. It's very high transparency when you're in an organization when you're able to form your own teams. I think it's very, as an educator, we would call Learner-centered. It focuses on the people and what their needs are. It also inspired, I think, Maria Montessori allowing choice in what we do and where we focus on it. Of course it has to be balanced with business goals and everything, but self-selected teams. Sandy's a great book. If you want to learn how to do that, I would recommend reading her book. During ReOrgs, I talked with Christian Linwall, who's an engineering site lead in San Francisco with Spotify. He works with some infrastructure teams. At one point, so they have this infrastructure tribe with multiple squads. As time went on, each squad has a mission of work, they saw some duplication in missions. And they stepped back and they thought, you know what, we need to kind of redo our missions and it had an implication to changing the squads. And so what they did was allow the team members to select their squads. And they had this whiteboard that was in one of their hallways and over a period of a couple of weeks, people could indicate which missions they were interested in. So all some of the missions stayed the same from before and there were some new ones added. So all the names were taken off and then they could put themselves up there, have discussions along the way. And then at the end of a couple of weeks, they had this in their FICA or coffee break area. So after a couple of weeks, they had their teams. And I think there was a case here where they wrote about it in the book where there was one totally uncompelling mission. Nobody really wanted to work on it. And you know what they did? They decided not to work on it. So they moved on. That was kind of interesting. So we have retrospectives on the team compositions. I think that's really, really important. And this leads to another example, Hunter Industries. We've got Woody Zul back here from Hunter who started the whole mob programming, which we'll see here. This is a picture of when I visited Hunter for the second time. They had multiple mobs. So mob programming where groups of team members are together working on the same thing at the same time. So they have multiple mobs here and you can see their chairs have wheels. So when I talked with Chris Lucian, their engineering manager, he was telling me stories about how it was pretty fluid. People could move from mob to mob. And since there's multiple people in each mob, it felt kind of less disruptive to have one person move to this mob, one person move to that mob. But the team members decided when they did retrospectives was that you know what? This is going too fast for us. So we need to do something different. And they came up in their retrospective with a trading system. So if I'm working over here on this mob and I want to work over here, if I work it out with a team member on the other mob, we work out a trade, we can do that. And then later we tell the manager. I thought that was kind of fascinating. It was like really putting stuff in the hands of the people. So the disappear anti-pattern. So the more I talk to people about redeeming, the more I learn that in some companies and there's stories here that they deliberately change teams as a strategy. We'll see later for sustainability, et cetera. But in some companies, and as I became a consultant seven months ago or something, sometimes redeeming happens and it isn't so great. And one example is what I call here the disappear anti-pattern. And when I refer to patterns in these, it's because I've seen them at least three times. Or the anti-patterns at least three times. And this one was pretty upsetting for people. And it was at a quarter, when a quarter would end, it wasn't these particular people, but when a quarter would end, what would happen is that the priorities would change in the company and people would get reassigned to different projects and they wouldn't say goodbye to each other. So it was like, you know, see this guy here, he just disappeared. It's like poof, you're gone. So at the quarter change, some of the team members would be gone so it was almost like in the company, it had internal threats to the teams. So this is something that I think is more of an anti-pattern and it was not pleasant for the people. A leader's job, according to Deming, is to drive fear out of the workplace. If you feel safe, we learn from Modern Agile, make safety a prerequisite, feel safe in your work, you feel comfortable to express yourselves. I think if people disappear and they re-team like that without the people's inputs or not in a humanistic way, it can be detrimental to the people. So why do we re-team? So some different reasons that came from the book, to, you know, grow companies, also, you know, unfortunately, to shrink companies. Companies lay off people. It's not a pleasant topic to discuss, but it's relevant to this topic. You know, also for sustainability of the company and to keep information redundant in your organization. People re-team for learning and fulfillment, to liberate people from undesirable situations or teams, and also sometimes we re-team because maybe the code suggests it. So here's some examples about that. This grow-and-split pattern was really interesting and I've noticed it at some different startups that I talked to. So this is the initial team at AppFolio that grew big, big, big, big, and then at some point some of the stand-ups and other things were taking forever. Too, too long. There was just too many people. We couldn't make decisions quickly. We split it into two teams. These are the teams that emerged and they, you know, named themselves after goofy rock bands with nerdy twists. So we've got Hex Pistols and Diff Leppard here. You know, but they felt a sense of identity. They were a small company breaking into two teams. And a similar thing happened at a company called Unruly in London. I talked with Rachel Davies, who was telling me some stories about team change. And their first team grew and split as well. And when they actually split, one of the team members baked this cake and they called it the Breaking of the Fellowship Cake. They're Lord of the Rings fans and they had this cake together. But it was like a meaningful, emotional event when the companies are small and they grow like this and they change. You know, combining teams. TradeMe, New Zealand company, Sandy was just talking about. I talked to an engineering manager there called William Them and with some teams that he worked with, these were teams that were making some pages responsive, you know, to show up in different mobile apps. They decided that they wanted to do more pair programming and it would be beneficial for them to combine multiple teams together and then do self-selection events where they chose their work and they switched pairs at a regular cadence. So innovation by isolation pattern, this is a pretty exciting one. I went to this company the other day so when I said at the beginning of the talk that I met a co-worker from 20 years ago, we worked on go-to-meeting, go-to-webinar as part of that startup. And before we created the go-to-meeting-related product, I was at this startup, I was the 15th employee and we were trying to create an online marketplace for tech support called the Expert City Marketplace and so you go to the website and you could get tech support help by experts that were standing by to help you. Well, the problem was nobody wanted to buy it so the company was about to fold. One of the co-founders, Klaus Schausser, calls it his $10 million mistake. So we had to do something. I was on the web development team. We were told we couldn't work on this anymore. We cried because I was like, wait, we have so many features we want to build but they were like, you can't work on it. Go to the beach. So innovation by isolation pattern, these people were taken from different existing teams, put off to the side in isolation. They were given process freedom and we built the first, this software called go-to-my-pc. You can see and operate your computer from a distance. We were given process freedom. The rest of the company was doing waterfall at the time. We didn't have to do that. And it was really, really refreshing. So this is a picture from that launch day. And yesterday I gave a version of this talk to the current go-to-my-pc team and that was really thrilling to me. So it's in the Bangalore office here. So this happened at another company which was Apfolio Co-Founder and after they built a property management software application they decided to build some software like a secure online data, secure online place to store documents and data. Same thing, took multiple team members from other teams, put them off to the side, gave them process freedom. But in this case, these people were not liberated from waterfall. They were liberated from scrum because they were doing two-week sprints and building a brand new product with the two-week sprints was really holding them back. And they needed really quick iterations. One engineer, I remember saying, like, we didn't know what we were going to do in an hour. I can't tell you what I'm going to do two weeks from now. And it would have been really hard to develop this new product in the context of an existing team that worked at that regular cadence. We needed a different, complete, different cadence. So they isolated themselves. So another example, re-teaming versus sustainability. So sometimes people switch teams to combat knowledge silos. This is Jim. He works in Portland and when he visits some teams in California, visits his company from time to time, once a quarter. He'll be with different teams each time. He was the first engineer at this company, so he shares knowledge of the system. Cloud Foundry, another company. They actually have a history in pairing. They have about 50 teams right now. And they re-team or switch people from team to team as a deliberate strategy for retaining knowledge and for sharing knowledge and doing something. Any of you heard of the Book Mythical Man Month? You know, if you add people to a software team, you're going to be late. It's all going to be later. But they try to combat this because what they do is they deliberately switch people from team to team. They wrote software to tell them when to switch people to different teams. So they deliberately do it to sustain the knowledge, spread around the knowledge, and tell the people to know each other. And then if we need to add a person from this team squad, whatever they call it, over here, it's not such a big deal. They're familiar with the environment and all of that. They also find that it increases empathy when they move people from team to team. So this software allocations, what they use, was developed by Pivotal. I guess when some of the consultants aren't out on a job, they're working on this place called The Beach and they create software products there. And so I thought this was quite fascinating. So reteaming for flexibility, for knowledge sharing. So reteaming for fulfillment and learning. We've got another video here, which was one of the inspirations for the phrase dynamic reteaming. Eventually you want to rotate people out. But you don't want to rotate everyone out at once, right? And so what we ended up doing is I think every six weeks or every couple of sprints or something like that, we would rotate one person out. So three of the team members would say the same. We'd take one person from another team and we'd rotate people around and eventually the teams would get all mixed up and you'd get that kind of bigger team mentality because you're working with everybody, right? But you've got more focus on a smaller team, right? What was that like for you? It was really good because you had that momentum with your team, right? And you knew what everyone was working on. We would sit right next to each other. Communication was super easy. But then every few weeks you get new blood, you get new ideas, you get new faces. And there were people you see every day in the office, obviously. But I was on a team. I really like working with Donnie, but Donnie was on another team. But I knew in a couple of weeks that he might be on my team and we could do something new together. Yeah, so I think there's very human reasons for changing teams. Conron explains this very well here. When they had one team and the team members were all pairing and the team got really big, there was a lot of pairing variety, which is nice when you're pairing to have a lot of pairing variety. The company, you know, they grew in split and then they had three teams eventually. And just that regular rotation of people from team to team to spread around the knowledge was really done because the developers wanted to work with each other. They wanted to work with their friends. Another re-teaming example from the research that I did was re-teaming to learn a new skill. Like this guy, Tushar, here, wanted to learn about data centers. So at this company they built and maintained their own data centers. And so he was able to switch to another team to learn about that, and then he went back to his other teams. I've seen examples of, like, tech support engineers going to product development teams and sometimes staying. It's nice to have that ability at work to move from team to team. Or even to re-roll. This is another example from Menlo Innovations in Ann Arbor, Michigan. They enabled people. There was a software engineer who wanted to be one of those high-tech anthropologists and do customer-facing UX-type work. So how cool is that? Like, wouldn't you want people to stay at your company longer? Wouldn't you want people to be able to try on different hats, wear different hats, try different jobs? You know, I was at two companies for 17 years. It was nice to be able to move from one thing to next. I got to grow as a person. So I think your organization can be stickier if you not only let people move, you know, from team to team, but also to, you know, try on different roles. So re-teaming of free people from misery, if some people have asked me before, Heidi, how do I know if someone needs a re-team? Well, one way is that sometimes if you'll have a team and you notice that, like, a majority of the team is silent during all your meetings, all your events and other things, maybe that's a sign that you have a new team. Like, in this case, this was a growing tech support team. And because they shared a manager with that web operations team I was talking about, they had all their combined meetings together. They worked in one-week cycles. But after a while, that tech support team grew, and then you had this, like, silent group who didn't want to speak because they thought their stuff wasn't really relevant to what the data center people were talking about. So we split them out. They had their new team. They didn't feel like they were wasting their time anymore. And then they got to create the events and meetings or whatever that made sense to them. You know, but sometimes people aren't going to say anything. It might not be, like, part of the culture to say, hey, I think we have a new team here, but I think the more we talk about this and more as coaches, as managers, as teammates, we notice these things. We can help people in our organizations find the next iteration. Our organizations don't have to stay so static. We grow and we kind of morph if we notice, if we take the time to notice. So these guys are sick of working with each other. We pay attention to the emotional field. And maybe we help them. Look, they've been together for so long. They're wearing the same hats. The dog is sleeping. You know, this is another thing. If it's working really well, leave it together. I have a story from CTO of Apfolio John Walker who was talking about he had some, like, like a really amazing high-performing team, however he defined it at the time. And the company was about three teams and he thought, I'm going to spread the high performance amongst the team. So I'll break up this team in the middle, spread the high performance. And, you know, he regretted it. So there's an interesting story in the book about that. Somebody in another division of the company years later did the same thing and learned the same thing. That story is there too. So reteaming because the code needs it. So sometimes we might notice that this team was working on the first version of their product, but the performance was really terrible. They had to do something before they released it. So they got some team members from multiple teams and put them off to the side. They were in this conference room for two weeks. They solved their performance issues. They called consultants in. They didn't have to work in the regular cycle because they didn't know what was going to happen in the next hour. They had freedom to iterate. And they solved their problem and they went back to their teams. So another reteaming example. Nayan Harjatwala, you can find him at this conference. He said to me once when I presented this in Detroit, Heidi, reteaming is inevitable. You might as well get good at it. And, you know, I agree with that because if you think about it, people come and go from your teams, right? They get, you know, they leave your company. They go to a different department. You know, people will come and go. And remember at the beginning I was like, I think, you know, teams are systems. So it only takes one person, like that rock band, to have a new team system. If you add a real loud, gregarious person to your team, it's going to feel a lot different than it did before that person joined the team. So, you know, that's a reteam. So we might as well get good at reteaming. You know, so practices to make it easier. So pair programming, that's one for sure. Pair programming and also writing code that, you know, self-testing code, whether it's test-driven or otherwise, it helps facilitate changing teams. If, you know, in the case of AppFolio, for example, a new person was hired on. Remember we doubled in size a couple of years in a row. Whenever a new person was hired, we'd balance, we'd share the load and they'd get assigned a team and they'd have a mentor. That mentor was their first pair. So if we had 10 people start on the same day, it would impact, you know, 8 to 10 teams and they'd have mentors and they'd help them get up to speed by pair programming. You know, mob programming, here's another team. This is a team that mobbed after Woody Zule came and spoke to us in Santa Barbara. That team was so excited about mobbing that they did it that afternoon. And so when you mob, if you imagine all the redundancy and the knowledge that's with the team, you add a new person into the mix. It's quite different than if everybody codes individually and you add a new person and nobody mentors that person or they have a whole new area they need to learn from scratch. That's going to take a lot longer. So it's facilitated by mobbing and pairing, I think. You know, one-on-ones. Managers can have one-on-ones with people to understand how they're doing. Is Joe excited to come to work every day? Does he need a change? Does Mary need a change? Really tapping into how we're doing as good teammates is important. I remember as a coach, I would do that. I would try to take people's temperatures, especially when we were a startup, because it was risky. We wanted to retain people. We wanted to build this software together. So we really cared about how the people were doing. Team coaching is another thing that helps. I'm not talking about just regular, agile rituals. I'm talking about things like from this book. This is an amazing book called Creating Intelligent Teams, Anne Rode and Marita Freijohn. They're from a company, Marita is co-founder of a wonderful company called CRR Global. And I did some coach training with them about coaching teams. We talk about teams as systems. That whole thing takes only one person to make a new team system. There's deliberate ways that you can coach people. And one of them is talking about how do we want to be together as a team? So when I have a team come together and form initially, or change later, we do some deliberate things. Chartering, modern agile, we talk about chartering, getting the teams and the work off to a good start. Here we talk about what do we want our team to be like? This team here is a real example. We want to trust each other. We want mutual respect. We want to feel optimistic. This is what this team wanted. When it gets difficult on our team, because it will get difficult, it's normal to have a disagreement. We don't want everybody agreeing with every design we come up with, because then we might not get the best design. But we also might irritate each other sometimes. So how do we want to be with each other when we get upset with each other? So that's a normal human thing, we normalize conflicts. We do stuff like this with teams. And then later we'll look at it again. Is this still valid? That kind of stuff. We talk about what do we want our team area to be like? Do's and don'ts, just what the preferences are for communication. We do this with remote teams too. When do we want to have our meetings? What communication tools are we going to use, etc.? We also facilitate activities where people get to know each other. So like in one hour we can learn about each other and raise respect. This is an activity I learned from Lisa Atkins. It's called Market of Skills. And it's an activity where everybody makes a poster about themselves. These are the skills I bring to the team. These are my hobbies and interests. This is what I want to learn in the next few months. And this is what I can teach my teammates. And it raises respect. I had a QI engineer join a team once with some software engineers. There was one software engineer in particular who was a tough crowd. He really had to earn his respect. We did this activity and when he learned that the new guy could take apart a motorcycle and put it back together, he couldn't do that himself. He was like, wow, you know, it really raised the respect. And it gives people things to talk about when they run into each other in the office later. This is another good thing to do, like if you have a merger with your company, you have people from one location visiting the other location. You can facilitate this in an hour. I can tell you how to do it. It's really one of my favorite things to do. This book has other great ideas, coaching for performance. It's a chapter on team coaching that inspired us a lot at Appfolio. Talking about things like doing social events together, having potlucks as a team, going on team excursions. You don't need funding to do this. You can do a lot of things for free. But, you know, the other thing, turn on the video. You know, if we're working with our remote teammates from location to location, let's turn the video on. Let's see each other. We'll get to know each other a lot better. Here's when video came. We have a stand-up here with some remote friends. We've got the video on. We get to know each other better if you have the video. I was with this team, like, three weeks ago. Okay? Here I am in Santa Barbara. You know, these are not the team members. I'm like, okay, I'll help you test this thing. They had me download this thing on my computer. I'm like, let's hang out and have the video and we'll just talk. Team member in San Francisco, team member in Santa Barbara. I was in Santa Barbara. Suddenly a dog barked. I'm like, oh, Joe, you have a dog. Hold up your dog. Let's see what your dog looks like. So he holds up his dog and it's a Pomeranian, right? Then the other guy who he's worked with for five years also had a Pomeranian. And so I'm like, oh, hold up your Pomeranian. These are rare dogs. But these guys worked together for like five years. They didn't know they had the same kind of special breed of dog. And I was like, that's really fascinating. Well, turn on that video. Who knows what else you'll learn about each other. The other thing, people will leave. So talk about it when they leave. Somebody leaves a company, maybe Fred. He leaves the company. Fred was the guy that brought the donuts on Tuesday. Nobody's going to bring the donuts because Fred left. Do you want somebody else to bring the donuts? Talk about it. There are certain things that we do in our roles that are beyond our job descriptions. Those leave when the people leave our team or leave the company. So we can have deliberate discussions about what do we want to retain. Going through layoffs, we talk about it. I was with another company. It's an elephant in the room. We need to talk about the elephant in the room. It's been very, very difficult. I was with a company and they laid off a lot of people. We can't just have the usual stand-up. What would you do yesterday? No. We have to talk about what's going on. We lost a bunch of team members in our office. We need to talk about this thing. This is a redeeming when people get laid off. It's not pleasant, but we need to talk about it as people because it's just a difficult situation. Encourage connection. When we visit each other's office locations across different locations, introduce yourself to people. If you merge with another company, I was involved in a company merger recently. I found the agile people at the different locations and sent them an email. Hey, let's have a phone call. Somebody else asked me, how did you get to know these people? I just sent them an email. We reach out and encourage the connection. It helps with the redeeming. Remote office gatherings. Here's a company called Meltwater. They bring coaches from all over the world. They brought them to Berlin and had an event together so they could know each other as people in person. Then they go to their remote locations. Some people do sports together. Re-teaming, it's going to happen. How do you respond to it? These guys decided to push the broken down VW van when it broke. They decided to do that. How will you respond? You get to choose. I hope this was helpful. My name is Heidi Hellfand. I'd love to hear from you. Here's my contact information. Thanks so much. I might have time for a couple questions. Anyone have a question? The question is what's the average time frame to change teams? I've heard maybe six months. Some teams nine months. But it really kind of depends. Some teams redeem quarterly. Some teams stay together for a very long time. I think you really have to look at the particular team. If the team is doing great, they're delivering things that the customers actually want that to delight the customers. You want to keep them together. That's a fast rule. Yeah. The question is if people change teams, maybe there's a hit to the productivity. How do we handle that? There are certain things that we can do to add redundancy to the situation, such as pairing, such as having tests when someone goes and works on a new area of code. They can leverage the tests there to get the feedback. It makes it easier for them to redeem. It's harder to redeem if you're switching programming languages. That'll be even more of a setback. I think if we have a tribe structure or communities of teams, and they get to know each other, it makes it easier to mix, because at least on a social level, the people don't need to break the ice, so then that makes it easier. At the end of the day, what is productivity? Are we building the right things and getting them out to the customers at the cadence that's acceptable for the customer and the business? We've got to watch that. We also read teaming around the edges. Breaking up a big team, having a lot of change at the same time will be a lot more of an impact than maybe having one team member move over here might not necessarily have that much of an impact. If it's a brand new team member coming into the company, they don't have any domain knowledge yet, it'll be a bigger hit. If they've been there for years, they know that people with the same programming language switch, it'll be less of an impact. Thank you very much.