The art and wisdom of changing teams | Heidi Helfand (author of Dynamic Reteaming)
18 Jan 2024 · 70 min
This is a podcast titled "The art and wisdom of changing teams | Heidi Helfand (author of Dynamic Reteaming)" recorded in January 2024. It features a conversation between Lenny Rachitsky and Heidi Helfand, an expert on team organization and reorganization. The discussion covers the challenges and opportunities of team changes, including reorgs and reteaming, with Heidi sharing insights from her book "Dynamic Re-teaming". They explore five types of team changes, the importance of transparency in reorgs, and practical advice for managing team transitions effectively.
Retaining is hard. Reorgs are hard. You can't lump them all into one thing with, you know, oh, it's all great all the time. No, it's not. If we could just build the software, deliver to the customer, get the product market fit. Hey, have we delighted them or not? If only it could be that easy. No, we have the people layer. So let's focus there too.
Today, my guest is Heidi Heffand. After two decades in the tech industry, Heidi became fascinated with how teams are organized, how org structures change, and how to set teams up for success through that change. She now teaches workshops and runs courses and consults on how to effectively reorganize your teams. And in her book, Dynamic Re-Teaming, Heidi delves deep into why change is actually good for your teams, why you're better off not having super stable teams, how to effectively execute reorgs, and through that how to reduce attrition, stagnation, and knowledge silos. In our conversation, Heidi shares the five types of re-teaming, anti-patterns to avoid when making org changes, what sort of team structure is most conducive to creating totally new products, why being transparent about your reorg plans is definitely worth considering, also how Heidi became such a great listener with a lot of really interesting insights and advice there, and so much more. Huge thank you to John Cutler for introducing me to Heidi. With that, I bring you Heidi Halfand after a short word from our sponsors. this episode is brought to you by product roadmap.ai and ignition. Product roadmap.ai is the first AI road mapping Suite. It helps ensure roadmaps Drive Revenue by instantly aligning product with your sales and marketing teams to capture upsell opportunities. Built by early leaders from Rippling and craft, it automatically identifies feature gaps from your CRM data and your customer conversations, adds them to shareable roadmaps easily prioritized by revenue impact, and then seamlessly closes the loop with sales reps via targeted notifications when feature gaps are closed. As part of Ignition's broader go-to-market operating system, productroadmap.ai can also help create better handoffs and collaboration with product marketing teams by giving both teams the tools to research, plan, orchestrate, and measure the process of building products and going to market. Packed with integrations, AI automation, and communication tools. It's truly a one-stop shop for product and marketing to bring things from concept to launch. To sign up, go to productroadmap.ai and use promo code Lenny to get 75% off your first year. This episode is brought to you by Hex. If you're a data person, you probably have to jump between different tools to run queries, build visualizations, write Python, and send around a lot of screenshots and CSV files. Hex, brings everything together. Its powerful notebook UI lets you analyze data in SQL, Python, or no code in any combination and work together with live multiplayer and version control. And now Hex's AI tools can generate queries and code, create visualizations, and even kickstart a whole analysis for you, all from natural language prompts. It's like having an analytics copilot built right into where you're already doing your work. Then when you're ready to share, you can use Hex's drag and drop app builder to configure beautiful reports or dashboards that anyone can use. Join the hundreds of data to teams like Notion, All Trails, Lume, Mixpanel, and Algolia using Hex every day to make their work more impactful. Sign up today at hex.tech/lenny to get a 60-day free trial of the Hex team plan. That's hex.tech/lenny. Heidi, thank you so much for being here and welcome to the podcast.
Thanks, Lenny. Great to be here.
It's great to have you here. So I had this colleague at Airbnb, her name was Jana, and she always had this joke that she shared that if it's been six months and she hasn't switched teams or hasn't moved desks, she knew there was this reorg coming. There's something happening, something was coming to change everything. And you wrote a whole book about this general idea of teams changing reorgs. You call it reteaming. I have the book right here. It's called Dynamic Re-teaming: the Art and Wisdom of Changing Teams. I feel like just people underestimate the opportunities and benefits of change, and I think that we see it as a scary thing. So I'm really excited to spend time with you and chat about this topic. Before we get into the meat of it, I'm just curious why you decided to spend so much of your time researching this area of team change, reorgs, reteaming?
Yeah, that's a good question. It wasn't necessarily planned. I had been working in a variety of different fast growing startups for most of my career in like 20 years in software as a service companies in particular. And I read a lot of books to try to get better at my work and what we're doing in our teams. Yeah, I have a lot right over there, as you can see. And a lot of the books I would read on teams and the advice that I would get from people would be, you know, you really want to keep your teams the same. You want to go for that. forming, storming, norming, performing kind of thing. And I had thought about that and I was like, wait, well, it wasn't really possible for us when I was at a startup and I was the 10th employee and we grew to 900 people and now thousands of people, our teams kind of morphed and changed. So I feel like if you're in a fast growing company or a shrinking company, look there. Don't look at trying to fight the natural Evolution. So I, I was just trying to prove a point and to illustrate that teams change. And I was also curious to see, well, was, was that just my experience and the experience of my colleagues in Southern California? What is it like for other people? So I was just curious.
You have this code in your book where you say something like, sure, we deliver software on time. We make products people love and want to buy. But there's this people layer that happens that people may not be thinking enough about. Is there anything more you can say to that?
Yeah, I think a lot of the things that I would read about teams, you know, just are naturally focused on, well, you want to build things that customers love. You want it to be an enjoyable experience. You want to deliver on time. You know, there's this, there's a reason we're there as a business, but there's also a lot of company building that happens in building the people structures and and just kind of, you know, when you go from one to many to a multitude, there's a lot of work that goes into it. This is enablement type work, and it's where I focused a lot of my time in my career, helping make teams and organizations successful. So there is this people layer. However, you know, I've thought about this a lot over the years, and I think it would be highly convenient. if we could just focus on building products that people love and getting product market fit, talking to customers, it would be great if it could only be that. But the reality is we're humans together and there's a lot of opportunity to build companies that delight people where they're excited to be included in decision making about how the organization grows and changes or shrinks. So, yeah, there's this whole kind of other area of work that I think just doesn't get enough attention. And I guess that's where I live and breathe.
Awesome. Okay, so I definitely want to get into the five types of reteaming as you described. But before we get there, what I find with reorgs and change is that it often leads to the biggest career opportunities because there's new roles to be filled. If things aren't changing, there's not going to be all of a sudden, hey, we have this new role that we want for you. And a lot of the, I don't know, a lot of the leaders that move out quickly are the ones that seem to take advantage of change and think ahead and get involved and position themselves in a way where like, okay, cool, there's a new position. Oh, clearly it's going to be Heidi. Is there anything you can share there or any advice for people that maybe see reorgs coming and what they can do to help themselves? in that pending change?
I really like it when there's transparency in reorgs. There's a story in my book from Christian Linwall at Spotify about how they reorged a large infrastructure team and they visualized it on whiteboards and brought people over to the whiteboards to see the future team structure that the leaders wanted. And they got input into the design. And We did this at Procore as well, inspired by Christian and his story. And we had, I think there were like 80 people involved in this platform organization that was splitting from two large kind of clusters of teams into three. And we, I remember when we rolled out the whiteboards from a back office where we were talking about this change for a few weeks. And it was scary to roll these whiteboards out because it impacts people's day to day. It's like when somebody is suggesting that maybe you do something different or that something different happens, sometimes it can be kind of triggering. You want to know what's going on. So anyway, we had courage together. So we rolled these whiteboards out and it had the team structure with everyone's names on it. It had the name of the team, the mission of the team, how many open slots for hiring across all of these different teams, and then people's names in their existing team positions. And people were invited to look, give feedback, they identified mistakes that we had in the design, oh, this team might be better over here, and here's why. And people had the opportunity to opportunities within their own company that they might say, Hey, I'm interested in this. Might I be considered for this? And then they could have their discussion. So I really like that the opportunities were shared and presented. So it wasn't some sort of thing that happened in some kind of back room for the whole time. We unearthed the beginning of a plan. I think sometimes you, you know, when you convene people for a meeting to talk about anything, it's good to have like a starting point. So we had this starting point. We had a variety of different things and I call it whiteboard reteaming in my book and I write about that. And, you know, there's even structures that are more open than that. Redgate Software in Cambridge, UK, Chris Smith is a colleague of mine and they do, regular open self-selection re-teaming activities when they're changing their strategic priorities. He talks about this globally, very interesting space. And it's even more open than putting the names on the whiteboards. They have teams give pitches and this is what they're looking for. And they have a whole method for enabling people to say, Hey, I'm interested in this. and I think that really helps because sometimes you might think, oh, no one's going to want to work on this, but people can be delighted by working on things that another person doesn't think are particularly interesting. So giving choice is important. And there are, you know, again, there are different grades of transparency. We weren't up for doing this kind of open, open, reteaming self-selection event. But we were open to the whiteboard variant.
I imagine individual employees hearing this of just like being involved in the reorg strategy sounds amazing. Executives and leaders hearing this are probably really afraid and feel like there's no way this can work well. And so what I want to understand is how do you actually set this up for success? What I'm imagining when you do this is, Many people disagree. There's teams people want to join, there's teams people don't want to join. It seems like there's a consensus challenge, or do you wait for everyone to agree? Does someone end up making a decision? Does it distract everyone from the work they're doing when you're kind of involving everyone in the reorg? Versus what typically happens. It secretly is planned amongst executives. No one knows it's coming. And I think the reason they do that is Because they don't want to distract anyone and they don't want anyone to start freaking out until it's like, here's the final plan. Here's what we're doing. So what other advice do you have for people that want to practice this way of reteaming and reorganizing where they.
Involve the actual team in the plan? There's a book by William Bridges called Transitions: Managing Life's Changes. I have it right here. Making Sense of Life's Changes. He talks about endings, neutral zone, and new beginning. you know, ending, you're going through a change, your team is changing, neutral zone, the period of kind of liminality where you're like, gosh, I don't know how this is going to go. You're not quite comfortable. You're not quite in that new reality yet. You're still thinking about what it was like before. And, you know, once you're in that new reality, you know, and leaders can, you know, paint the vision and picture about the benefits of the new reality and the purpose and why we're here and anchored at that to try to raise positivity. But once I learned about that transition framework, going through any subsequent changes myself became a lot easier to grasp. And, you know, it really kind of changes in any part of your life. I mean, his book is not written about software development or product development. You know, sometimes we're going to have a say, we're going to be able to participate. Sometimes we're not. And being clear on who the decision maker is in a change is really important. There's another framework that I really like. I don't think it's in my book, but I've written about it in my new book, but it's called RIDE. And we had a chief people officer at Procore, and she's now at UKG, Pat Waters. She taught us the RIDE framework. for decision making clarity and it's who's requesting the change, who can give input to the change, who's the decider on the change, and who's going to execute on the change. So it's like RIDE. And I Googled this for a while. I couldn't find anything on it and encouraged her to write about it. And I credit her to that Pat Waters. She's awesome. And you know, so a lot of the times it's kind of like, you know, what are you dealing? What What's the problem you're going to solve? You have a current state and a future state. Okay. And that future state might be up to discussion, but maybe it's not depending on what it is.
Right.
You're going to you're you're getting acquired. Like you're probably not going to have a standup meeting and talk about should we get acquired or not. No, you're not part of that decision.
Right.
So and then how is a change going to going to get rolled out or how are we going to do it? you know, in other cases at the team level, maybe you have a retrospective and you determine, hey, I think we'd be a bit more effective and we'd be able to deliver, you know, at a better cadence if we were two teams instead of one team. And if teams have the ability to talk about that and impact and have some agency into how their, their part of the org evolves and changes, I think that could be really cool. I think that could be really empowering. I think that could help us feel more ownership. in that company that we're in. It doesn't always have to be like, you know, decision making equals hierarchy or the person at the top. It doesn't have to be like that. But again, like, retraining is hard, reorgs are hard. You can't lump them all into one thing with, you know, oh, it's all great all the time. No, it's not. It's not. But, but anyway, We need to focus there. We got to focus on this people layer because, you know, reteaming is inevitable. We might as well get better at it because we're going to have to deal with it. If we could just build the software, deliver to the customer, get the product market fit. Hey, or have we delighted them or not? If only it could be that easy. No, we have the people layer. So let's focus there too.
On this transparent, collaborative reteaming, the final question here is just, would you recommend time boxing this so that it doesn't suck up everyone's brain power for weeks and weeks and weeks? Or is it very dependent?
Yeah, yeah, yeah. You have a time budget.
Is there advice you have on how long?
Make a schedule. I bias towards shorter as opposed to longer. You don't want to deliberate on this forever, 'cause especially as you include more people, you know, it can be distracting. So you want to like proceed as expediently as you can.
Let's talk about the types of reteaming. This is the core of your book, and we haven't even gotten there yet. So you've identified there's five ways teams change. Can you just walk through them, help people understand what they are? And then I also, we use this term reorg a lot in this conversation. I think that's the way most people think about change after we go through this list. So what does reorg refer to when it's maybe from the perspective of these.
Five ways of teams changing? Sure. Okay. So the five patterns of reteaming. One by one, someone joins your company or someone leaves your company. Grow and split, it's a growth pattern. Teams grow bigger and then they split into two or more teams. Opposite of grow and split is merging. Sometimes two or more teams merge together. It's more of a shrinking pattern. We might be seeing more of this these days as companies downsize. Things merge together and consolidate. Isolation is, or innovation by isolation, start a new team off to the side, a beneficial silo, give that team process freedom. Great for catalyzing new product lines within your existing company. Also great for emergencies, and they just happen anyway if we have incidents and people have to come together to solve an incident and then go back to their teams. And switching. So switching is moving from one team to another team. You can do this at a variety of cadences, short term, long term. And then difference between a reteaming and a reorg. I think reorg is a word that has very traditional baggage and connotations. And when I was writing dynamic reteaming, it just didn't feel like an appropriate word to use for well, you know, Sue is looking to learn a little bit about how our web operations work. She's going to move to that team. It doesn't, it didn't feel appropriate to call that a reorg because Sue's moving and switching from one team to the next. I think reorg, you know, again, it's reorganization is a traditional word. It implies on the large, it implies top-down changes that you have no saying. It's just It's, it's something different than what I consider reteaming, which is these five patterns that happen at different levels.
Awesome. So let me just repeat back these five. So one, one by one, basically people joining your team, leaving your team, something very natural people do all the time.
Your company. Mm-.
Or your, or your company. Mm-.
Yep.
Uh, growing, splitting a team gets really large. And then it's like, okay, let's just split this into two, focus them on specific things. instead of this one team trying to cover too much, merging teams, the opposite of that. Isolation, I want to chat about that one a little more, where you just have a team off to the side and they're just dedicated to something that you find really important. So with isolation, you have this awesome story of your time at a company called Expert City, which turned into something people know most likely and ended up being a great outcome because of this reteaming into an isolation team. Could you talk about that?
Yeah, so I've been at different startups that have grown bigger. And one of them, I was the 15th employee. I started as a web editor and became an interaction designer. And we were going to change the world. And it was very exciting. We were in Santa Barbara, California. So the company is called Expert City. And we were working on our first product, which was a marketplace for tech support. So imagine you have a problem on your computer, you can go to our website and then you can select an expert to see and control your screen to help you solve your tech support challenge. And so we had the screen sharing technology that we were inventing in the company. We had the web-based software to manage the interaction between the customer and the expert. We had the experts, we had in-house experts, and then the vision was global worldwide experts. we were going to be like this marketplace, this like eBay of services is what we talked about in the early days. And I was like really into this. This is my first job in tech and I became an interaction designer working on kind of front end UI flows with engineers. It's actually before the word interaction designer, I was like my title was like navigation designer. We made this up. So I was very into like It was before the words like UX and other things people were talking about information architecture and other sub genres of design. And we had individual offices. I had all the interaction flows on my walls. I was, you know, really into the words. And one day I was like in there and we were working on a new flow. We had all these hopes and dreams for this product. And the CEO came into my office and he said, Heidi, we are, stop working on the marketplace. We're not gonna do that product anymore. We're killing it because nobody's buying it. And like made six bucks or something last month. And he said, go to the beach. You know, we were by Santa Barbara, I'm like, what do you mean go to the beach? He's like, well, I don't want you to start any work that you're gonna have to maintain later as we figure out our next step. And I was like, okay. So I remember that day and I'm looking around my office at all these flows on the walls. So like really like, you know, these were domains like kind of like domain driven design. It was like all these like web domains and which in our custom, you know, which user interactions were going to happen and all these hopes and dreams. And it was the first time in my career where something was, you know, we were told not to work on something and it was it wasn't paused. You know, some people say, oh, we're going to pause this and then they never get back to it. this thing was, like, gone. And I didn't get it. I I just didn't get it. I cried. I was like, I, like, acted out. I, like, sent this email, like, how can we kill the marketplace? It must live. You know, I was like, like, it was, it was, it was quite an experience. But then, and I don't know what the timing was, I was invited to be on this team off to the side, and there was Market validation going on. We became, like, the that our founders and product and others became students of market validation, four steps to the epiphany. So we had built this thing. We spent all this time on this marketplace, but nobody would buy it. And so it was like do or die. I mean, we had to shift. This was like before Lean Startup. So four steps to the epiphany was that was the book. It was the manual. It was like the guiding the way. And so there were people that had a ton of conversations with potential customers about this new thing that we were going to build.
Right.
And it, so I was invited to be at this team off to the side and there was a small team and we didn't have to do waterfall software development. We were freed from that. We were like liberated from that. We got to work in other ways. And I remember, you know, working with an engineer and like we were figuring out how to like create a forgot password flow because like none of these patterns existed, you know, back then and like we got to do this stuff. We got to deploy like, you know, more frequently. And the product was called Go To My PC, where you could see and operate someone's computer from a distance. And that, you know, was essentially the pivot that I feel like saved the company. Later we went on, we got folded back into the teams and we built Go To Meeting and Go To Webinar. I was a technical project manager at that time. And yeah, so taking a team off to the side, giving that team process freedom, They didn't want us distracted from the drag, from the, you know, when you're working on an existing product line, you get this cadence and it can become a mature cadence. You know, maybe people work in two weeks or one week now, but when you're working on something new, you need faster iteration loops. And our founders knew that, Nate, you know, so it was a privilege and I was like delighted to be part of this other team and And yeah, it was really, really exciting. So then looking back over the years, I was like, yeah, you know, isolated teams, beneficial silos, you know, again, it's going against the grain of what some of these books say, oh, you want to decsilO everything. No, sometimes there's a reason why you have a problem, you want to solve the problem. This was like, like, were we gonna, I mean, was this company gonna go under? Like, I didn't think of those kind of things at the time because I was just super into the work and, and, very passionate and motivated about what we were building. But, yeah, isolation pattern came up and, and we used it at another startup as well. And, you know, ever since. So, so, yeah, that's the story of, of expert City. And from my perspective, you know, ask different people, have different vantage points. But, you know, this, that if we would have stayed within our teams and we would have had to develop with pixel perfect mockups done in Photoshop. Like, here you go. I don't think we would have been fast enough. I don't like that was not good for the innovation that we needed. So it's like also like innovation by isolation. Like it's good for emergencies. You know, I was at another startup. We had performance issues with our first product. People went into left teams, went to, we brought a consultant in, went into a conference room for a couple of weeks, figured out some major changes that needed to happen, solved them, went back to the teams. This is not a new concept. The Chicken McNugget was saved by an isolated team, SWAT team. There's a book called Teamwork. It's an old book from, I think, the 70s. I have it in my bookshelf here, and there's a story of the Chicken McNugget that you can read about where they brought in consultant and had a very small team and worked in a different, didn't work in their same, like, plant where they were developing the product. They worked in a different plant. They reported straight up to one of the executives at McDonald's. And, yeah, the chicken McNugget lived on because it was, like, having challenges in the, in the test Marketplace in Indianapolis. So, you know, we didn't make this up. It's just like some of these things are kind of like, oh, it's like a noticing and then you're like, oh, that's a pattern.
So it's a collection. There's this idea of a startup within a big company. Everyone's like, oh, it's just like the startup within a big company. It's all the, we have all the resources that we need. There's no less risk, but we can innovate and try new things. Rarely does it feel like it worked out. You're sharing stories where it does. Is there anything you found or any advice for how to actually be successful in this idea of having a team.
Off to the side doing something innovative and different? at AppFolio, we did this. So there's a company called SecureDocs. It branched off into its own company and it was just acquired, I believe, in 2022. When SecureDocs was happening, I was not on that team. I was like, I was on the other teams and I was watching. And again, same pattern. A team was created off to the side and they were given process freedom. They worked in more of a of a daily Sprint style as opposed to the two-week Sprint style that our other teams were doing at the time at AppFolio, early AppFolio. And so one, isolate the team or put them in a different area. We could still see them. We were in this big open room, but they were, it was their team area. I mean, we had these like impermanent walls between some of the teams, like, It was their region and they claimed it and they named themselves. And so one, you know, separate location. There's another story in the book about a team that incubated a product idea within Citrix, and they were in a garage of all places. So they were like really isolated, but just put the team in a different region, make it that area. That's number one. Number two, tell other people not to disturb this team. that's key. And hearing it from a leader is really, really important. No, you're not going to pull them into something else. They're working on this other thing. So, you know, people need to shed their skin of the other things that they're working on. If you take a bigger picture, kind of forest through the trees picture, you want people pairing and switching pairs so they're not single owners of the system. So when they have an opportunity to do something that could be really important to the company, like be on one of these isolated teams, They can kind of fade out and not be the only owner that has to transfer knowledge and then field questions for two years on how that system works. You want to build this redundancy in your teams, right? So that's like, if you really want to plan ahead, do that first. You know, have that as part of how you operate, building this team redundancy and switching. Because then it frees people to not be the only owner of a system and chain to a system. and yeah, so isolate them, tell people not to bother them, do pairing and have shared ownership so it's easier for somebody to switch into something like this. Process freedom, again, they can do things differently. Ideally they report up to someone that has, that really has decision making authority and decisions won't get reversed or they have to go through some complex like web of like, is it okay if we do this? No, like you need kind of like a clear decision making structure. They saw that at the McDonald's case study as well, which is not in my book, but it's in this other book called teamwork. And then, you know, that group having that, you know, senior leader that they report into, you know, getting the clear lines of communication there is, is also really important. So not having this, you know, like heavyweight, like bureaucracy of, I don't know, quarterly business updates where everybody's making a slide deck for two years before they go to that meeting. Trying to relieve the team of things like that and kind of make it lighter. And yeah, some of these teams, like SecureDocs, became another product at AppFolio. It was very, very successful at one point. I think it was before we went public. It branched off. into its own separate entity. I think maybe they shared a, like a board member or something. I don't know how that worked, but it became its own entity, secure docs, it became separate, and then it grew from there. And then it became this, like, you know, wonderful, successful product that that was recently acquired. You have people come and go at companies and companies grow and change and morph. And, you know, that was like one case of. Departures, you know, that, you know, it's like that are sweet, right? You're happy for your friends and colleagues. Say, oh, he's going to be a CTO. It's going to be the CTO. Like, there's a sad to see. I remember visiting their office in Santa Barbara. You know, it's great to see your friends succeed and thrive. And, and, you know, we, we developed other companies in that way.
So. Awesome. I think it's really nice to hear there's many success stories of this idea of a mini little startup within a company. And these are really good tips. This episode is brought to you by Ahrefs. Many of you already know Ahrefs as one of the top tools for search engine optimization. It's used by thousands of SEOs and companies like IBM, Adidas, and eBay. What you may not know is that there's a free version that was made with small website owners in mind. It's called Ahrefs Webmaster Tools. It's free, and it can help you bring more traffic to your website. Ahrefs' Webmaster Tools will show you keywords that you rank for and backlinks that you can get. It also performs automated site audits to find what issues prevent your website from ranking higher on Google. Every detected issue comes with a detailed explanation and advice on how to fix it. Visit ahrefs.com/awt, set up a free account, connect your website, and start improving it. h r e f s.com slash a w t. I feel like to me, one of the most important ones you've talked on this is having an executive essentially sponsoring this team and it's supporting and protecting it versus, you know, some managers just like, now we're gonna go do this off to the side, because otherwise no one's gonna really take that seriously.
Yeah, I, I think that's really, really important. You know, and I will also say that, you know, things don't always succeed a hundred percent. I, I, I've seen isolated teams. within companies where someone has the opportunity to sell something and they talk to their friends who are the engineers who build the feature for them, but then it leaves something for other people to maintain later and they weren't involved in the decisions and it can be a big mess. You know, for all of these patterns, there are, it's like kind of like balconies and basements. There's, you know, you can screw it up too. You know, it's not all, you know, stuff is hard. You know, that's why I like to lean into it and have written about it. you know, things take effort. You gotta, the tree is gonna drop the leaves and you gotta sweep them up. You know, it's, everything takes work and effort.
So we've talked about the isolation pattern. I thought it'd be good to talk through the rest of the patterns real quick and share maybe one or two tips for how to be successful or make it work well or better.
Sure.
Before you start, I actually, I think I missed a nuance and you corrected me, but I think I missed it, which is for the one-on-one pattern, It's actually describing joining the company specifically, not joining a team. Is that right? Yeah.
And in the book, it might be a little blurred because this is like some of the switching in one by one sound very similar and they do have some like kind of Venn diagram overlaps, but I'll distinguish them as I talk about them.
Cool.
So yeah, so one by one, someone joins your company or they leave your company, right? So the tip with one by one is when someone joins, help them build a sense, feel a sense of belonging. And you can do that through not having their first day be them sitting over there alone, right? You could have someone have a first pair. There's a chapter in my book about onboarding. This is in the space of onboarding. Also with one by one, when people join, you also need to pay attention to the people who are already there. And it's good for them to know when someone is joining the company that it shouldn't be a surprise. So visualizing the hiring and the opportunities is something that I think is a really good idea. It could be challenging for someone if somebody joins and they become their manager. But what if that person wanted to be the manager and then they brought in someone from the outside to become the manager, right? So you need to pay attention to the new hires that are joining, help them feel a sense of belonging, get them to talk about themselves, which is said to increase their sense of connection and retention. There's some research in the book, the Culture Code by Daniel Coyle, which talks about that. But then it's also important to coach the people for change that are already at the company, right? Especially if they weren't involved in the particular decision of bringing on this new leader that comes in and brings in all their people, right? So you got to pay attention to to different people. Grow and split is a natural thing that happens when you're like startup, scale up, and growing bigger and bigger. The first team probably grows bigger and then splits into two or three. So when the team gets bigger, facilitation and communication tends to break down. So some signals that teams might bring up when they feel like a change might be helpful is the meetings are taking longer. You're in that case where it's harder to make decisions. It was easier when there were like five of us, but now there are 13. The work becomes divergent. They're working on this one thing. They're working on something else. No one's paying attention in the standups so much anymore because this work has diverged. and those are a few of the signals. And then someone typically brings it up. If you normalize the idea that it's okay for teams to have input into their future structures, maybe they'll bring it up and decide that, hey, it might be better if we split. Sometimes splitting, though, can create dependencies that weren't there when you were together as one team. So you inherit other problems, or you might inherit challenges like, All right, the team decides it's more effective if they split into two or three, but we just have one product manager. We just have one designer. We just have one person who helps us anticipate quality challenges. So, you know, it's a lot of problem trading when you do a lot of this stuff. Like anything, you know, you have a challenge, how might we solve it? Well, there's option A, option B, and option C. Okay, so this grow and split. So then, 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 like 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, you know, companies combine, you know, 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, there's changes, you know, at the individual level, the team level, the team of teams level, department level, the company level. So, yeah, so merging. So there's a business decision. 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 the leader saying that. So, you know, again, we weren't involved. I wasn't involved in this decision as, 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, like we didn't know that. Oh, I didn't know that you have built a system like that. We did too, or we've never built anything like that. That is so cool. Like, you know, what did you learn from that? You know, we get to learn about each other and then we're together and we're like, all right, you know, we're this merged entity now. Like what's next? Like looking out to the future so we have the same shared vision. So I love doing that. So there's different tactics you can do before, during, and after each of these patterns. Yeah, so that's merging. Isolation, we talked about before, put the team off 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. like, you know, there's ways that this can be messed up. And then switching. So switching pattern is really tied to learning and development and fulfillment. It could be that you want to work with other people. Like you, you know, 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.
Right?
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. And 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, you know, 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 fault tolerance. So if someone leaves, they don't leave with that, all the information in their head. We had that. We had at that first startup, Expert City, we had that some single owners of systems. And when they left, it just becomes a challenge and a setback. And at the second, you know, at Eppfolio, we share a founder between the first startup and the second startup. Many of the early engineers from that first Startup went to the second startup, right? So I was 10th at AppFolio, I was 15th at Expert City. So we wanted to work together, right? So it was that, you know, global idea of, you know, switching them 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 you know, Appfolio is processing a lot of rent payments. There's a lot of money. There's ACH going through. You know, those are critical systems. It's very important that things are safe and secure. You know, you don't want to haphazardly switch people around. You can screw this up. You know, again, that balconies and basements concept. You don't want, you know, somebody over here, they will switch every two weeks and have no say in their team. Like, you can like, 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, right? Like 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.
Right?
And that brought fulfillment. It brought joy. I mean, they would see each other in the, 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, well, what about that? Like, it, it, 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.
All these stories of team changes and reorg, it made me think about a quote that one of my managers always used to say about reorging and changing teams, is that there's no perfect org structure. There's only the best idea you have at the time for what the org could be. And then there's the issues with that org that you identify as you're putting in place and then set up processes and systems around to try to catch that, like dependencies. as you said, or overlap of ownership? Is there anything along those lines that comes up of just things you found of just like, there's never going to be the perfect way to do it. This is just our best idea at the time. And here's how we deal with the downsides of this approach.
Yeah, I think there's a lot of wisdom to what your manager said and your colleague there. Because, yeah, I mean, as time goes on, conditions change. We evolve and change. We're subject to different influences. COVID happens, we weren't dealing with that 10 years ago. We grow and adapt and morph. We try to get together and make the best decisions that we can when we're faced with challenges. And yeah, a lot of it is problem trading. We have this challenge today. We decide, oh, there's a few ways we could handle this, pros and cons of each solution. and let's, you know, it's like the, it's like the kata. It's like the Toyota kata, you know, like grasp the current condition. You will experience, you know, you have challenges. What's the next evolution or the next target condition? How might you get there? And then you're there and you're like, okay, grasp the current target condition. What's it like? What, you know, what are you experiencing? Oh, we might try this. You get to, you know, it's always, we're always transforming from the current state to the future state. So, you know, to that, I would ask people, well, how do you want that to be? And how do you want to show up and be as a leader? Right. You want to just be like, all right, you know, got to get this done. The reorg is done by an email, and we're just sending it out, you know, or this small team change. And here it is. It's done. Goodbye. You know, or is it a little bit? where you get people's input, you know, it. And that in itself, you gotta weigh, you know, what you're dealing with, you know, again.
But.
But I like to. I think about that. Like, what kind of leader do you want to be? Leaders need patience. It's hard to be a leader. It's challenging, you know, but what. What kind of environment or Vibe do you want to cultivate in your teams? And what do you want the people to be like? I have a degree in teaching English and applied linguistics, and I remember studying like Paulo Freire and other educational problem posing methods of education. We have these teams that solve these complex problems and challenges and build these really cool things for customers. Let's involve them in some of the org decisions that are going to be part of their daily life. I really like that idea. Again, it's not perfect. You can't involve people in everything, especially if there's wide scale changes that you just can't.
Along these lines of doing things badly sometimes, you have this whole section on anti-patterns of reteaming. I think there's about five of them. I don't know if you have these all top of mind, but if you do, I'd love to hear some anti-patterns.
Yeah, well, one of them is people always think that reteaming is you have a pool of people and you're assigning them to a bunch of different projects like, okay, you'll work 10% on this one, 5% on this one, 20% on this one. We are going to allocate the resources from our component-based teams into these different projects. I live that, that we did that in Waterfall like many years ago, you know, but that doesn't really work. A lot of the times the percentages don't add up. It's very hard for people to multitask and be involved in like multiple efforts at once. It's hard for, for the brain with all the, all the context switching that, that needs to happen in that case. So I call that the percentage anti-pattern. There's also, I probably wrote about it like poof, poof, they're gone or like suddenly they're here. Like, you know, reteaming or having people suddenly show up and you weren't expecting them or suddenly they're gone and there's no communication around it. What soever, that's another anti-pattern one of.
The ones I love is this idea spreading high performers, this idea of we're going to spread the high performers across other teams.
That's an app folio story. John Walker was telling me back in the day that, yeah, he, he had this thought. I mean, he did this experiment. He had this thought that, you know, many of, like, we had this one team that was like, I guess they were delivering at this Cadence that they loved, and they were building this stuff, and there's this. energy and you can almost feel it. Like, let's just spread the people from that team across the other ones and then we'll have that. And it didn't work. Like, he didn't have that. Like, it didn't happen. And that was a visceral learning for him that it doesn't essentially work, you know? And, and, you know, people are like, like, you know, what does it take to be a high performing team, right? Like, what, what does it take to have that magical team experience where there's that chemistry and, and the people are together. And there's stories in the book Damon Valenza was telling me one about how it's like it's a band and we're riffing off each other. And like, there's we're creating this music together. So, you know, John felt like he essentially destroyed that when he split up that team. So that's, you know, the story that inspired that anti-pattern.
The reason people are worried about reteams and reorgs is this A lot of times this exact reason that you just shared, which is our team is amazing. Why would we, I don't want it to change. I don't wanna split. I don't wanna add anyone. I don't wanna remove anyone. I guess, is there anything else along this line to help people make feel better about, no, this is actually gonna be okay and/or it's inevitable.
You're not gonna, it's not gonna last. I think sometimes you have that awesome team situation. It's an enjoyable experience. People are learning. You're looking forward to it every day. You're delivering the stuff that people love. you're telling people what's going on. You're, you know, you have that matched expectation where people aren't, like, breathing down your neck because it's late or something. You know, sometimes you want to keep that team together. You don't want to destroy that Dynamic. But the thing is, you know, maybe that's a small startup that grows, and you need to grow because you have a bigger Vision, and it needs to be more than these 10 people, and so. You know, there is sometimes this feeling of loss like this is our company. This is my experience at this company of 10 people, but suddenly we're 20 people. It doesn't feel the same like it did anymore. And it feels different. And people always ask the question, how do we maintain our culture? It feels different than it was before. And the thing is it is different. And Our companies go through stages. The company of today is not the company it was a year ago. The people turn over and change, what we work on turns over and change, the whole kind of world and industry and global events change and put different pressures on us. And we got to live in this global context. So nothing lasts. And so Sometimes I have like a picture of myself with an, or like holding an ice cream cone that's melting, you know, not to be a total downer, but you know, it, appreciate it when you're on a team and you love it. And it's amazing because, you know, it, these are our lives and, you know, we, we have to have gratitude and, and appreciate what we have. Cause naturally things evolve and change. It's, it's just inevitable. So we appreciate what we have. A lot of us can look back on our careers and remember those times when we were, in my case, skipping through the halls, because I was so happy. And I, and it was like, I couldn't even tell you, like, well, why was I skipping through the halls at that moment? What was it? Well, it was the people and the conditions and what we were doing and like the time, the era almost. Because, because yeah, it does change. There's a book by Itzhak Adizes called Managing Corporate Life Cycles. It's one that many of us read for years at Folio, maybe the previous company as well. The Adeezas Institute influenced some of our leaders and they influenced us with this and it talks about the different stages of companies from birth and there's go-go stage, maturity, death of companies. These are like life cycles. The company grows and changes and morphs and changes. The people in the teams do that as well. I have an eco cycle in my book where I talk about that kind of aging and changing. Then there's a disruption and you have a new beginning. You know, we're part of these stories that are in progress. This is not an unchanging, unmoving kind of entity that we work in. So just be kind, be kind to each other, enjoy your experiences and learn as much as you can.
It reminds me of a advice Sheryl Sandberg shared when she came to the Airbnb offices. Someone asked her, what advice do you have to deal with all this constant change? Like the quote I shared at the top of the episode of like every six months there's a massive reorg, our culture's changing, teams keep changing, it's constant flux. What is your advice to deal with that? And her advice was like, that is good. The fact that you're growing so fast and having to change is the best case scenario because the alternative is you are not growing. And it's much harder and much more painful because the changes are much harder. People get let go. Your business may go away. So her advice is just, this is good. Change means things are, and growth leads to change, especially hypergrowth, and that you should appreciate this time versus be afraid of it and think that it's a negative. Yeah.
And it seems like she had such a wide vantage point and could kind of see the forest through the trees. of the fact that, oh, this company is doing well.
Right.
And this is why we're growing and changing. And I remember one of my leaders, CTO John Walker, you know, at Folio, he told me that once too. He was like, you know, I'd be like having a problem or something and I'd come to him and he'd always say to me, it's always great to be at a successful company, Heidi. And, you know, it's like, well, yeah, like sometimes you don't think about the finances. when you're in your day to day and you have a problem with another person or they come to you and they have a problem with this other person, you know, but in the grand scheme of it, like, how is the company doing? Like, it's really like a critical vantage point that we need to remind ourselves of. But yeah, you know, I wouldn't say all change is always good. Your mileage may vary there, but the general idea that the company is doing well, you're growing and changing, you're trying to make things happen. I think it's definitely the space I'd rather be in than the opposite.
Yeah. And I think it's especially true for people that haven't worked at a company that didn't work out where they think this is sucks when really this is like pretty good compared to all the things that could be happening.
Yeah, yeah, definitely. So we, you know, we coach and help each other as we go along.
Final question before we get to our very exciting lightning round. used to work with John Cutler, who was a previous guest on this podcast, and he had a question that he wanted me to ask you. He said that Heidi is one of the best listeners I've ever worked with. And so the question is, what's your secret to being a good listener?
Well, listening is a muscle to build and to always work on. You got to put your attention out, focus on the other person. Sometimes, if I'm looking down, maybe I reconnect and look at them. You got to read body language and other things. I'm trained as a coactive coach, which involves different levels of listening. So you have level one, which is internal listening. Like if you and I are talking, but I'm thinking about like, what am I going to have for lunch? I'm in level one. I've got to redirect it out to you and focus on you. So when I focus on you as I'm in level two listening, I'm like putting my attention out and I'm like really anchoring towards you. It's a coaching skill, right? And then level three is like global listening, environmental listening. If a marching band suddenly walked behind you, I'm going to point that out because it's in my field. I'm not going to ignore that. I'm going to bring that up, right? So we pay attention to kind of the vibe and the feel in the room and where we're at. But then also if you're talking about something and suddenly you go like this, or you have this kind of sudden pain in your neck when you're talking about this one thing. I might notice that you're doing this and like touching your neck because that's information. That's a kind of listening. And so I might ask you about that. Or if the face turns red or you look down or away, it's another kind of listening. So, coactive. Training Institute, Coactive.com is my Coactive Coaching training. So I learned it from them, Henry Kinsey House. Wow, that is an awesome answer.
There's like real, a lot of depth there. So coactive.com, I'm gonna check that out. So you actually got trained in this skill. Okay, that's great. That'll make people feel better. They're like, okay, okay, amazing. I'm gonna, I'm gonna check this out. I'm gonna try to be a better listener through the rest of this podcast episode. from these tips.
I will say that sometimes I am not a good listener though.
Yep, so it goes. Heidi, is there anything else you wanted to touch on or share before we get to our very exciting lightning round?
I don't think so. I really appreciate your questions and talking with you.
Well, we've reached our very exciting lightning round. Are you ready? Yeah. All right, first question. What are two or three books that you've recommended most to other people?
Leading Intelligent Teams is one. Liberating Structures is another one. And of course, Transitions by William Bridges. I also like the Leader's Guide to Participatory Decision Making.
Is there a favorite recent movie or TV show that you've really enjoyed?
I did like the Bear. the cooking related show, the restaurant related show, and talks about the hospital, gets into the hospitality industry. I really like that. I was, you know, movies, there isn't really one that stands out. I always look forward to being on an airplane to see what movies are playing, but no movie for you.
What is a favorite interview question that you like to ask people that you are interviewing?
I always like to ask people, well, why do you want to join our company? What is it about working with us that would be exciting for you? Like, why our company as opposed to another one?
What do you look for in their answer that is a good sign?
You know, they have some knowledge about what we do, what we build. Maybe they bring up that they've noticed something on one of the websites or a product launch that we just announced, just that maybe it's part of their story and their career. They're going in this direction and they heard about us and they thought, wow, I would love to work on that.
Is there a favorite product you've recently discovered that you really love?
I'm very into vintage clothing and specifically, like, real wool cashmere, not synthetic blends. I also like vintage blazers. A lot of the times where I'm giving a talk, I'm wearing a vintage blazer. I really like the clothing and design and I kind of, you know, really, really love unusual vintage pieces that I could find. But they do need to, you know, a lot of the fast fashion that's out there today is a lot of these blends with these materials that you've never heard of, but there's like something special about like, you know, vintage cashmere, for example.
Do you have a source for some good stuff? Is it like eBay? Is it stores locally? Is there a site? Is there something you find, finding some good stuff?
I travel around the world and I give talks on reteaming, I do workshops, and usually I go to vintage and antique stores. I was just in Berlin. I was doing that. I was doing it in London. And yeah, I, you know, I love thrifting. Salvation Army Goodwill, any of these places that we have in many of the US cities, the Humana line of stores that I've been to in Europe and other places. I try to find the small, unusual antique places as well. My aunt's an antique dealer in Michigan, and she doesn't specialize in vintage clothing, but I just love that. Idea of discovering unique and unusual things that maybe they remind you of times in the past, like maybe you find that, oh my gosh, we had that mug, you know, back in the 80s or whatever, or in the 90s, you know, things, things, you know, can kind of remind people of, of other times. So I like that. I think there's information stored and, and unique items.
Yeah, beautiful. I bet Berlin has some really cool vintage stuff, really wacky stuff.
Yeah, there's a lot of really interesting places to explore. And I think it's just so much more interesting than some of the brand new kind of.
Stuff. Agreed. Two more questions. Do you have a favorite life motto that you often find yourself coming back to or sharing with friends or family, either in work or in life?
I like asking people, how can you be kind to yourself?
Say more.
I ask myself that too. I used to run a lot in Santa Barbara at Elwood, which is a beautiful trail that you can go down to the ocean. You come back up. It's like a mesa, more mesa in Santa Barbara. And I would run I'd be like, God, this is so hard. And then I would walk for a little while and I'd think to myself, well, how can I be kind to myself? I mean, like, what am I doing here? Does it have to be fast? No. Like, I'm here to like decompress and like enjoy. So how can I be kind to myself? Like, I think sometimes I get hard on myself or have very high expectations, kind of achiever mentality. And it's, I've learned through the years that like, It's okay to slow down. It's okay to like, you know, not go, go, go the whole time, you know? So I, you know, would ask other people that as well. Like, especially if they're, they're going through a challenge or burning midnight oil or whatever it is, it's like, well, you know, what about self-care? How do you, how can you be kind to yourself?
Beautiful. Final question. I was scouring your LinkedIn and I saw a quote from the CTO of AppFolio. in his endorsement of you said that you were the unofficial director of fun at AppFolio. Is there a story that comes to mind of something that you did at AppFolio that created a lot of joy and fun for the team?
We had these hack days, and I think they do that to this day. So like twice a year, we'd bring people together and we copied and learned from Atlassian. I remember we had calls with some coaches from Atlassian for how did they do their Ship It Day, or they originally called it FedEx Day, changed it to Ship It Day. We followed their model and we'd had this, you know, two o'clock on Thursday, two o'clock on Friday, where we'd build whatever we wanted and we'd have a theme and then we'd have goofy prizes at the end that were like traveling trophies. Like one of them was like a clickety-clack keyboard that we spray painted gold by the railroad tracks, you know, but people could work on anything. There were teams that formed. We did it with a self-selection marketplace, right? People formed their topics and teams, and one team hid geocaches throughout Santa Barbara. They're there to this day because we registered them with the geocaching website. Another team built a vintage video game machine, and it was in the dev room. you know, another one, like they catapulted, they built this like trebuchet, is it a trebuchet that like catapult this fruit in the parking lot? I don't know how we got away with that. But we were in the early days, we did a lot of fun stuff like that. You could work with different people, build these larger relationships, which, you know, later makes it easier for reteaming because then later, if you reteam, you're not strangers with people. So you want to cultivate the community. So we had this department of fun. We would plan the fun in a variety of other ways as well.
So fun. Heidi, you're awesome. I think we've helped a lot of people feel better about the endless change that they're probably going through right now. Two final questions. Where can folks find your book, find you online if they want to reach out? And how can listeners be useful to you?
You can go to heidihealthfan.com or Google my name and I come up. Heidi@dynamicretaining.com Heidi.healthland@gmail.com you can find me. I'm out there and yeah, I love to work with companies and teams going through change and I do that in a variety of ways, teach workshops, do talks. So if any of this is interesting, reach out.
And then do you also consult and work with individual companies or not?
I do, yeah. I do that now. I like to work on a retainer basis or I'll even join a team. So looking for the next one.
Amazing. And we'll link to all the stuff in the show notes. Heidi, thank you again so much for being here.
Yeah, thanks so much, Lenny.
Bye, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lenniespodcast.com. see you in the next episode.
More from Lenny


How Meta designed Muse: an AI agent people actually want to talk to | Alex Cornell (Design Director)


Why every company now needs to think and operate like a lab team | Josh Woodward (Google Labs, Gemini, AI Studio)


Jev: 8 real use cases for the fastest, cheapest model I’ve ever used | John Lindquist


The grief, loneliness, and burnout sweeping through the tech industry right now | Molly Graham






