Heidi Helfand: preference

Transcript context

…igner. We just have one person who helps us anticipate quality challenges. So it's a lot of problem trading when you do a lot of this stuff. Like anything, you have a challenge, how might we solve it? Well, there's option A, option B and option C. So that's grow and split and it's very common I think when your company is growing and changing, kind of like that. Merging is the opposite of grow and split. Two or more teams combine together. Or at a higher level, a company acquires another company and then there's a merging that happens. So merging I think is related to when companies downsize or shrink, things consolidate, come together, or again, when at the company level companies combine, one acquires another, gets acquired. How that goes down varies, but there's this concept called panarchy that I write about in my book that a lot of these changes is changes at the individual level, the team level, the team of teams level, department level, the company level. So yeah, merging. So there's a business decision that the companies merge together and then changes might ensue. So maybe the company wants to get ahead on building and having another vertical in their SaaS company. We acquired a company at AppFolio to bring us faster into workflow software for law firms. So we acquired a company based in San Diego, and that got us a couple of years ahead. I remember one of the leaders saying that. So again, we weren't involved... I wasn't involved in this decision as an IC at the time. So it could be a business decision for merging at that level. It could be that people leave, there are departures and teams and responsibilities consolidate together. That's merging. So it could be that kind of shrinking that we're seeing. It could be that the company is having one leader instead of three and there's a consolidation and the teams kind of merge together. So it's the opposite of grow and split. One activity I do like to do with teams that merge is called story of our team. That's in chapter 13 of the second edition. So with story of our team, each team makes a timeline of... They stand in order of when they joined their team and they make a timeline with milestones of when they joined their team, when people left, and significant events and things they created that they're excited about and that they're proud of. And that they branch together with their newly merged team, and then it's good to get a shared sense of history. So you have these teams or companies that come together, they make shared timelines, they share their milestones and things that they built that they're proud of. They tell each other about it and then they have a sense of like, "Wow, we didn't know that. Oh, I didn't know that you had built a system like that. We did too." Or, "We've never built anything like that. That is so cool. What did you learn from that?" We get to learn about each other and then we're together. We're like, "All right, we're this merged entity now. What's next?" Looking out to the future so we have the same shared vision. So I love doing that. There's different tactics you can do before, during, and after each of these patterns. Yeah, that's merging. s next?" Looking out to the future so we have the same shared vision. So I love doing that. There's different tactics you can do before, during, and after each of these patterns. Yeah, that's merging. Isolation we talked about before. Put the team up to the side, give them process freedom, have them report up to a decision maker, tell the other teams not to bother them. Let them work at the cadence that they want to work at. That makes it easier. If you are doing a short-term thing, you got to work it out with the larger entity so you don't create something in isolation that other people have to maintain. There's ways that this can be messed up. And then switching. Switching pattern is really tied to learning and development and fulfillment. It could be that you want to work with other people. Like forming, storming, norming, performing, Tuckman's model, he forgot the phase called stagnating. Sometimes it feels like we're in a team for too long. We're tired of working with these people. We want a little variety. We want to work with that person over there. Or maybe we want to work on a new system. We don't have the opportunity to do that in our current team, but what if we could work on that system over there with those people? It could totally refresh us. It could be like having a new job within our same company. It could extend the lifespan of the amazing employee in your company. So switching is tied to that kind of fulfillment, which is one of the reasons why I made it separate from one by one and tied that to the company. The other thing with switching is that you could create safety nets in your company through switching. I just wrote a newsletter post about this yesterday because maybe we're going to have some more changes this year. Maybe companies are going to be hiring less. I don't like the thought of companies downsizing or having layoffs or anything like that, but I think to myself, well, have multiple owners of a system. So not only one person is that tower of knowledge that owns that one system. There's some stories in my book where I interviewed Richard Sheridan, who is the chief storyteller and co-founder of a wonderful company called Menlo Innovations in Ann Arbor, Michigan. They built their company Menlo to have people work in pairs. Not just the software engineers; team members work in pairs and they switch pairs at a regular cadence. And you know that when you're joining the company because you're involved in some kind of pairing. So there's parity from when you're interviewing to when you're at the company. But switching also helps build that knowledge redundancy in your company. A little more about tolerance. So if someone leaves, they don't leave with all the information in their head. We had that. At that first startup Expertcity, we had some single owners of systems and when they left, it just becomes a challenge and a setback. And at AppFolio we shared a founder between the first startup and the second startup. Many of their early engineers from that first startup went to the second startup. I was 10th at AppFolio. I was 15th at Expertcity. So we wanted to work together. first startup and the second startup. Many of their early engineers from that first startup went to the second startup. I was 10th at AppFolio. I was 15th at Expertcity. So we wanted to work together. So it was that global idea of switching one by one or similar. But anyway, at the second startup we had the chance to do things differently. So we had pairing and switching pairs and test-driven development. We had help to do that, but this kind of redundancy built safety into our systems, especially when AppFolio is processing a lot of rent payments. There's a lot of money. There's ACH going through. Those are critical systems and it's very important that things are safe and secure. You don't want to haphazardly switch people around. You can screw this up, again, that balconies and basements concept. You don't want somebody over here, they will switch every two weeks and have no say in their team. There's ways to screw all of this up, but there's other ways to do it well. I remember when we were at our first team at AppFolio and we did a grow and split. It grew and it split into two or three teams. I remember there was a loss for some of the engineers who wanted to pair program with some of the other engineers, and they started a regular rotation themselves from one team to the next, and that brought fulfillment. It brought joy. I mean they would see each other in the workspace every day, but they wanted to work together. It brought them learning joy and fulfillment, and I love that. For those who are like keep the team stable and the same forever, I'm like, "Well, what about that?" It brings me satisfaction and joy when I see my colleagues. It's like autonomy, mastery, purpose, like Dan Pink's book Drive, when people are really given some agency and the opportunity to work a little bit differently than maybe that traditional boxed version you might see on my bookshelf. You can really create not only products that people love, but companies that people love and want to be at.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.