People Driven Development

Episode 13: ReOrg
===

Eddie Flaisler: [00:00:00] Hello, everyone, and welcome to the 2025 edition of the PDD podcast. We are incredibly excited about the problem statements we will dive into this year.

Eddie Flaisler: Today's episode is a little bit unique. Rather than responding to a single question, it gives an overview that we hope will help answer a lot of different questions about one of the most anxiety provoking situations in our professional lives. A reorganization, or in short, a reorg.

Morgan VanDerLeest: Now reorgs can and do happen in every organization from global technology conglomerates to the family owned grocery store, and they can be simply defined as a deliberate restructuring of an organization's roles, responsibilities, and or workflows. And do note, this definition does not include the words "for the purpose of" because reorgs can happen for a surprisingly large variety of reasons.

Morgan VanDerLeest: And we'll touch on a few of those today.

Eddie Flaisler: Are you thrilled, Morgan? Because I am.

Morgan VanDerLeest: Absolutely, you know it. Cue the intro, let's do this.

Morgan VanDerLeest: I am Morgan.

Eddie Flaisler: And I am Eddie.

Morgan VanDerLeest: Eddie was my boss.

Eddie Flaisler: [00:01:00] Yes.

Morgan VanDerLeest: And this is PDD: People Driven Development.

Morgan VanDerLeest: Alright, Eddie. We set out today to demystify reorgs for folks and provide a little more context about the whys and the hows of these events. But before we do any of that, I think it's worth talking through what makes reorgs so scary. So, as you mentioned, your average reorg kind of evokes this very strong emotional reaction in most people, and that's obviously not happening in a vacuum. We can resort to like the typical argument that most people just don't like change, but I feel like that's just way too simplistic.

Eddie Flaisler: You know, my first encounter with the idea that employees are first and foremost people was when I read Dale Carnegie's book, How to Win Friends and Influence People. You can imagine how desperate I was to make sense of my own situation at work that I picked up a book whose title sounds like human beings for dummies.

Eddie Flaisler: It's actually a masterpiece. And at least to me, the key idea in that book is that to some extent, all people are hungry for the [00:02:00] feeling of importance. We need things to also be about us. It doesn't make us narcissistic. It doesn't mean we don't care about others, but it's part of the human experience to balance selflessness with knowing that we matter. Now, this existential monologue is relevant to the point you're making, because reorgs are probably the most blatant form of an organization telling most of its team members, it's not about you.

Eddie Flaisler: Your individual experience does not matter here. Well, guess what? We hate that. And what's worse is that whether we acknowledge it or not, every reorg has its winners and losers. Every reorg. And if it ends up neutral, that's purely incidental. No leader knows what's going on inside the heads of everyone on their team.

Eddie Flaisler: So that context can never be fully incorporated into decision making. And the thing is that unlike tolerance to change, which can be more of a spectrum, I think it's pretty safe to say most people don't like to lose.

Morgan VanDerLeest: That is so [00:03:00] true. I think there's so much one can lose in a reorganization. You can lose your manager, who was the person most familiar with your work and was the best position to advocate for you and for your performance. And now you need to build all that rapport from scratch. You can lose a system that you might have built, which has become not only a comfort zone for you, But also that thing which gives you a sense of purpose and identity at work, because you're the expert on it. And then you can lose your day to day interaction with your friends because they're moved somewhere else or worse laid off. A manager can lose their scope, they can lose team members, they can get pushed down in the leadership hierarchy and made to feel stuck or unappreciated. And that's rough.

Eddie Flaisler: Totally rough. And the scariest thing of all, you can lose faith in your employer's ability to succeed, and by extension support your success, by witnessing changes you don't understand and you might interpret as acts of panic.

Morgan VanDerLeest: Word. Eddie, you hit on something that seems important there. You said changes you don't understand. I know we haven't gotten into the mechanics [00:04:00] of all this yet, but would you say insufficient transparency is a big factor in people's, you know, dramatic experience of reorgs and a potential area of improvement?

Eddie Flaisler: I would say yes and. I don't think there's a question that the more you bring people along in the chain journey, there's less fear and catastrophizing because, you know, they understand better what's going on, so their brain has fewer gaps to fill with horror stories. I do think we need to remember that organizational decisions in general are often ones of trade offs, right?

Eddie Flaisler: We talked about in the past, it's not about the perfect answer, it's about the optimal answer given a set of constraints. Now the thing is, Morgan, that there is no algorithm for trade offs When people and their experiences are part of what you're considering in the decision, it's not an exact science and that makes articulating the consideration behind the trade off very difficult.

Morgan VanDerLeest: Okay. Yeah, it's difficult. I mean, that is kind of what we're paid to deal with, right? That's part of the experience that we as managers and leaders are bringing to the table.

Eddie Flaisler: Well, I'm not [00:05:00] sure it works like that. I don't think avoiding overcommunication of complex decisions is necessarily a cop out. It's sometimes the right thing to do for two reasons. One, some of the context for reorgs decision can be confidential, such as a specific leader's performance evaluation. Two, you know, you mentioned being paid for experience with delivering a challenging message.

Eddie Flaisler: While I agree, I also think the issue with experience is that it creates good instincts that can't always translate into crisp verbal arguments. You can be super informed and have the best intentions, and still end up saying something inadvertently controversial that will create unnecessary turmoil in the team.

Eddie Flaisler: So, while I think all of us have encountered situations in which the authority to withhold context from the team has been abused to make decisions that are not necessarily professional, I still don't see communicate more as one of the key takeaways from today. As leaders, we should definitely explain well what's going on.

Eddie Flaisler: But in the context of reorganizing well, [00:06:00] I think there are lower hanging fruit to pick first.

Morgan VanDerLeest: That's an interesting point, Eddie. And I think the shift I would make is instead of needing to communicate more, we need to communicate well. And I think there's a couple of things that go into that that are important, but we'll get there. Eddie, do you think you can give an example of a situation where you believe that kind of transparency regarding the circumstances of a reorg can actually be a net negative, even though the change itself makes sense?

Eddie Flaisler: Yes. I think the obvious example is that of a reorg, which is done purely to grow and retain high performing leaders in the organization. It's not very interesting from a strategy point of view, so we should probably spend most of our time today on other reorg use cases, but it's still worth talking through.

Eddie Flaisler: You know, in most organizations that are both financially sustainable and try to maintain a generative culture, you will find that promotions in the management ladder are less based in individual merit and more on business need. You obviously need to be good at what you do, but if there's no scope to justify moving you up to a certain level, where, you know, not only are you paid more, but [00:07:00] also you are farther away from the manufacturing floor, so to speak, it's not happening.

Eddie Flaisler: You are not becoming a leader of nothing. Now, albeit very efficient, this model breaks when you want to grow or even just retain strong performers who are driven by new opportunities and increased responsibility.

Morgan VanDerLeest: So something important you mentioned there is who are driven by new opportunities and increased responsibility. That's not everyone, you know, there's some people that just like stability and predictability and can really deliver remarkable results doing the same or similar things for a number of years.

Eddie Flaisler: That's correct. And that's actually a major reason why this model of scope based leadership actually survives in practice. If everyone needed to move all the time, we would have a problem. In any case, what do you do when you have a leader whose work has been invaluable to your organization, is a pillar of your team's positive culture.

Eddie Flaisler: They have a lot of domain knowledge, which a new person would take a long time to acquire. And in general, whose quantifiable contribution [00:08:00] exceeds the penalty of a needlessly manager heavy design. You make scope. You make scope so you can move them up. You unnecessarily break a team into smaller chunks to make room for more managers.

Eddie Flaisler: You add layers that shouldn't be there. You do what it takes and just try to make sure you don't negatively impact existing business goals.

Morgan VanDerLeest: I see where you're going with this. So you're saying that's an example of something that you as a leader can believe is the right thing to do, but chances are slim that an argument around you guys are all changing managers and what you work on just so we can retain this one person would land well with people. So instead you resort to some, you know, generic language around alignment with business goals when communicating a change. I do have to say, Eddie, that while this example makes sense, just based on personal experience, it smells a bit like unprofessional decision making. Is one person truly worth the wellbeing of so many?

Eddie Flaisler: You know, I don't disagree. I myself have not been the easiest person to convince in these situations. I will [00:09:00] say this example falls squarely in the realm of decisions you have to make with only partial context. As I said, no leader knows what's going on inside the heads of everyone on their team. So I personally can't tell what people would be more bothered by at a given time, having to rebuild rapport with a new manager, or wondering if the ship is sinking because a well respected senior executive just left.

Eddie Flaisler: You see what I mean?

Morgan VanDerLeest: Yes. And that reminds me of a recent example of transparency that backfired. I was at an engineering all hands and the engineering leadership was sharing some context around some performance evaluation improvements. This topic had caused some rumblings so we wanted to address some points and just put people's minds at ease. And in the process of doing that, we ended up sharing some off the cuff details that we needed more context that we hadn't put thought into yet. And that ended up just derailing the entire conversation for the rest of the meeting. So we ended up spending another week or two on damage control, even though nothing bad was happening. So TLDR, even the best [00:10:00] intentioned transparency isn't a silver bullet. There's just more to it.

Eddie Flaisler: Absolutely.

Morgan VanDerLeest: Okay, Eddie, I've enjoyed this discussion a lot, but I want to make sure we don't spend too much time today, just staying high level and justifying edge cases and organizational change. This is a managerial science show. So let's managerial science it. Your typical reorg. Why and how let's give people some techniques.

Eddie Flaisler: I'm going to blow you away. Are you ready?

Morgan VanDerLeest: Eddie, I live in Texas. Please do not use "blow you away" lightly.

Eddie Flaisler: Apologies. Here goes. So, when considering and executing a reorganization, the most important thing isn't any particular technique. It's staying mindful of the countervailing metrics for the reorg, both in terms of guesstimating from experience what they would look like once the reorg is executed, and actually tracking them after to understand if we need to reverse course.

Morgan VanDerLeest: I love the idea of countervailing metrics. Can you say more?

Eddie Flaisler: Yeah, so as yourself defined it at the [00:11:00] beginning of this episode, a reorg is, at least in concept, a very straightforward idea. You restructure roles, responsibilities, and workflows to better align with the current goals of the organization.

Eddie Flaisler: It can mean changing your investment allocation, existing areas of the product, you know, like we discussed in the previous episode. It can mean spinning up new teams. It can mean winding down teams. It can mean restructuring to break silos, so something along the lines of changing what functions are part of what teams for better collaboration.

Eddie Flaisler: Like bringing a designer into a scrum team as opposed to design working as a separate organization unit. It can mean a bunch of stuff, but ultimately, the action itself is mostly moving people around to achieve a business goal.

Morgan VanDerLeest: Agreed. Go on.

Eddie Flaisler: So because that's all it is, it's very easy to thoughtlessly execute changes. If we need to invest more in X, let's move people to X.

Eddie Flaisler: If we need to spend less doing Y, let's lay off people from Y. If A and B have trouble communicating, let's force them to work together. Now, it might sound almost cartoonish when I'm [00:12:00] describing such blunt action without a thoughtful discussion to base them off, you. But you'd be surprised. Interestingly enough, even if we aspire to be the most invested, data driven leader, we can still find ourselves using blunt action to address a problem that required surgical accuracy.

Eddie Flaisler: And if we look into the metric we're trying to influence, still congratulate ourselves for a brilliant move. The layoffs will reduce people costs. The increased investment in a specific area will see more results, assuming the issue was indeed not enough people. The engineering manager and product manager reporting the same dotted line person now?

Eddie Flaisler: Well, they'll be spending most of their time together, so they will for sure be more aligned, either on the work or on the fact they can't stand each other.

Morgan VanDerLeest: But it doesn't end there, does it? Because the question is, what else is happening once you reorganize? And is it worth what the reorganization was able to achieve? I think that's where those countervailing metrics are needed, which makes sense. You know, not so [00:13:00] much in the realm of reorgs, but I think customer support is a great example of why countervailing metrics are important. The movement to automate the job of support agents started way before AI became a thing. And the typical metric used to measure success in deploying those automated systems was change in resolution rate. The hypothesis was that the resolution rate would increase. That obviously happened because the system would give people some random answer to their problem and just close the case. But then if you looked at the actual customer satisfaction scores, those would have plummeted. Same with reorgs. The question is what else happened when you moved people around or out?

Eddie Flaisler: That's right. I find that countervailing metrics matter at least as much as those measuring the specific business outcome, especially when it comes to internal decision making like a reorg. You know, decisions that don't directly or immediately affect customers or partners often feel less scary to make, so it's easier to be careless.

Eddie Flaisler: The countervailing metric is your guardrail.

Morgan VanDerLeest: Let's [00:14:00] get down to the details. What are some typical countervailing metrics for engineering reorgs?

Eddie Flaisler: I think the best way to list those would be in buckets, depending on the type of reorganization. I see it as four buckets. First bucket, the right sizing reorg, which is corporate speak for we're taking people away from a particular domain they were working on. That's normally done by either moving some or all people working on that domain somewhere else, or by laying them off. When you add people, you don't say you're rightsizing.

Morgan VanDerLeest: Ain't that the truth?

Eddie Flaisler: For rightsizing reorgs or in general, whenever you change your investment, you have to measure what happens to the technology left behind, and you do that with metrics like performance degradation or downtime and subsequently what happens to the customers left behind with metrics like net promoter score to measure customer satisfaction.

Eddie Flaisler: And also what happens to the engineers now tasked with supporting the defunded software area. We're not going to spend more time [00:15:00] here talking about burnout because we've covered that in depth in a previous episode. But suffice it to again state the axiom that if your people suffer, so does your business.

Morgan VanDerLeest: Very true. Now, Eddie, I hate playing the devil's advocate here, but let's assume for a moment that all these metrics indeed look terrible and lowering the investment was bad. These changes are typically made when funding is limited. Isn't all this tracking kind of a waste of time if we didn't have a choice anyway?

Eddie Flaisler: I would argue that there's almost always a choice.

Morgan VanDerLeest: Then argue.

Eddie Flaisler: Well, if I cannot afford my current investment in an area of the software, I do one of three things. One. If not already done, I explore moving its development to a lower cost center. There are plenty of offshore options with well oiled administrative layers around it, so you don't actually have to create a business entity in the respective country and deal with all the headaches.

Eddie Flaisler: Two, I make a build versus buy decision. If that thing I can no [00:16:00] longer afford is core to my own intellectual property, there's a severe business model problem that this reorg is not going to solve anyhow. But if it's not core, then someone else probably built it already and can offer it to me for less.

Eddie Flaisler: Three, nobody likes that, I sunset. There is nothing wrong with making a well communicated plan to sunset functionality. The sunk cost fallacy is a form of cognitive dissonance we should always be mindful of, so we don't end up investing time, money, and effort in something, even when the current costs outweigh the benefits, just because we already spent a bunch on it.

Morgan VanDerLeest: Sunk costs is just such a hard thing to overcome. It's one of the reasons why I find it helpful to account for more than just pure code output on things. For example, at a previous company, one of my teams had an outage due to a bottleneck in our Elasticsearch set up. We mediated the issue, but needed to spend a few months working on a backfill for the mountains of data that we processed. During that time, we ended up upgrading our [00:17:00] Elasticsearch setup so the backfill wasn't needed. And since it wasn't quote unquote finished, the main engineer initially felt like they just wasted a ton of time on something that just never actually came out. But instead of looking at just code output, we kind of shifted our perspective a bit and looked at it as a learning exercise. This person had almost no Elasticsearch experience prior to the project. And then it became one of the most experienced people at the company, which helped solve a significant silo problem that we had before. And that was huge for us, even if there was no defined output or shift, or we didn't click the run button. I will say that in some cases, over investment is as bad as under investment. If you throw more people at a situation where you've already hit maximum parallelization in terms of how many people can actually work on this thing at the same time, all you get is too many cooks in the kitchen. And that's a lot of painful overhead in managing performance and growth. In a team that doesn't have enough work or is even burning out despite being overly staffed. Because we still refuse to focus on technical foundations so we keep fighting fires.

Eddie Flaisler: So, so [00:18:00] true.

Morgan VanDerLeest: Next bucket.

Eddie Flaisler: Next bucket is the Rethinking Reorg. In this one, you don't make changes to your investment in the domain as much as you make changes to the domain itself. To give a Lob example we're both familiar with, when the company first started, off the shelf technologies to generate PDFs at scale were less prevalent, so it made sense to have a dedicated group working on PDF generation.

Eddie Flaisler: Once that became something you could get out of the box by using certain external products, it became clear that while we still need to make sure we generate high quality PDFs, that should definitely be just one part of what a team is doing, and not the sole focus, complete with, you know, dedicated EM, PM, etc.

Eddie Flaisler: Note that this is different from right sizing because it's not just about having less or no engineers work on it. It's about changing how we think of this functionality while still caring about good outcomes.

Morgan VanDerLeest: That's a situation I went through a couple of years ago where the team I was working with went [00:19:00] from owning the email sending pipeline for an email marketing platform to owning the overall platform infrastructure of the engineering team and previously email sending, very important, still important core to a email marketing platform, but it was somewhat done. There weren't regular changes to it. It was in maintenance mode when we needed to do updates to Ruby, Rails, et cetera. We went through that process, but in general, we weren't making updates to email sending. So we had to kind of rethink, all right, what does this group of people who has very extensive knowledge of how the system works, where are they better allocated? While understanding how we can shift that thinking to, improving engineering as a whole when these people had really spent a lot of time optimizing and fine tuning this very elaborate and important pipeline for the company. Kind of a platform mindset was a better application of their expertise there. So limited to a single team, but still, I think an important example of just because something has happened in a certain way previously doesn't mean you can't shift and even use that same group of [00:20:00] people to rethink how they are looking at the work that they do or the value that they can bring to the company.

Eddie Flaisler: Very, very true. And it's not just about financial benefit to the company. It's about keeping these people energized, entertained, fulfilled. You know, they get bored doing the same thing all the time.

Eddie Flaisler: They went into this job to do much more than just maintenance. So totally on board with that. To get back to the rethinking reorg, the rethinking reorg is quite surprising in terms of countervailing metrics. On the one hand, you don't take people away, so that's one less concern.

Eddie Flaisler: But on the other, it is still a directional change. You change what people are working on. Now, directional changes and pivots can be very helpful. We talked about that in the last episode. The problem starts when you overdo it. Unreasonably frequent directional changes, which force teams to repeatedly abandon work in progress, you know, in favor of new initiatives, do a lot of damage.

Eddie Flaisler: These excessive changes are often [00:21:00] executed under the guise of agility, experimentation, or fail fast, but sometimes the truth is, Morgan, that the underlying reason for the swift change is under researched strategy. Is uninformed decisions and is lack of discipline to balance technical business results with team health.

Eddie Flaisler: It's part of our job to sustain our human resources sense of achievement by repeatedly driving their work to production. And it's also part of our job to build their confidence in the thoughtfulness that goes into our directional changes. And that is why survey based data, particularly around trust in the direction of the company, is a very good countervailing metric here, and of course a leading indicator for retention.

Morgan VanDerLeest: I love that mindset. And I think that's something that I been going through recently, where we're trying to figure out how to break up a team's domain. It's just too big. It doesn't make sense.

Morgan VanDerLeest: There's likely two teams that live within this. And we could just say, boom, here's the domain, split it up and go. But it just [00:22:00] really makes sense. Doesn't align as well with what the business actually needs. And so we're essentially going to run some kind of internal experiments and focus on a couple of work streams. See if the domains kind of shake out from doing this. And once it's more solidified, then we can say, okay, cool. Now we have two teams that do these two separate things. And then people will kind of naturally have shifted in those directions anyway, versus just like, ah, let's just make the call and have it be done. So making it again, kind of more of that people first approach of let's let things settle first. It's really not going to change our day to day much anyway. So how do we do this in a way that actually makes sense? Doesn't disrupt a lot and can make sure that we're still delivering good value for the business.

Eddie Flaisler: That's such a great idea to start from the work.

Morgan VanDerLeest: What's the next bucket?

Eddie Flaisler: So I want to bundle the third and fourth one together because frankly, they're both less dramatic than the first two. So the third bucket is the relocation reorg, and the fourth bucket is the mix and match reorg. By the way, copyright on both these names, I have not read them anywhere. [00:23:00] In the relocation reorg, you keep the team associated with a particular domain intact, but reposition where they are in the org chart.

Eddie Flaisler: So you either move them to a different area completely, or you add slash remove layers of leadership in the org chart subtree where they currently live. The fourth one is the mix and match one. That's normally the least painful, and at least in my mind, when it's done, it's typically done more thoughtfully.

Eddie Flaisler: A mix and match reorg is when you take certain functions, like application developer, SRE, security, QA, product manager, product marketing, and you decide that they should start or stop working together in an organic team. It's just like a product manager who can be a product owner, fully embedded in an engineering team, or work completely separately and just drop product specs for the team to work on.

Eddie Flaisler: Now, for these two, since the work and resourcing aren't changing, The main potential losses in a reorg [00:24:00] tend to be more targeted, you know, so not affect everyone equally. This is not something to underestimate, but we also need to be realistic and remember that those who are making these decisions have to prioritize what constraints they account for when solving the problem they're reorganizing to address.

Morgan VanDerLeest: Can you expand on what you mean by targeted?

Eddie Flaisler: Yeah, well, let's think through it. I can think of a few very specific challenges in this situation.

Eddie Flaisler: One, your leadership chain changed. And now, like you mentioned earlier, you need to start building rapport and credibility all over, which sucks. Two, you are now working more or less closely with people you typically partner with for your work. So for example, your security person is suddenly on a different team with priorities that aren't just yours, or your PM is now in your face nagging you about the release in every stand up.

Eddie Flaisler: Three, you are neurodivergent. and social change is hard. That [00:25:00] one is very, very difficult and it's a whole separate conversation.

Morgan VanDerLeest: Oh, uh, so there's a lot to unpack there. First you mentioned the security person moving to a specialized team where your priorities are just part of what they do. It feels to me like the whole delivery pipeline would suffer in that case. Not just an individual. That feels like less of a targeted consequence.

Eddie Flaisler: Well, that's a very keen observation. I am making here a hidden assumption. I'm assuming that in the case where I chose to move the function from a cross functional team to its own specialty team, I either have a plan for how to quickly unblock the team who no longer has a dedicated security person, or I am fine with potential reduction in the pace of delivery for the full stack team left behind, to accommodate whatever it is I wanted to achieve by moving the security person out. If neither is true, I can't speak to that because the decision was not thought out at all. So [00:26:00] under this assumption, I'm looking at the friction created by this change as more of a cause of personal frustration for those who used to benefit from a dedicated person working closely with them.

Eddie Flaisler: Does that make sense?

Morgan VanDerLeest: Yes. Now, the second thing I want to double click on is that neurodivergent situation. Eddie, you talked yourself in the past about the prevalence of ND individuals in the industry. That trait can be a trait of a whole team that is now in distress. And that's not just an individual.

Eddie Flaisler: You know, I was hoping you're not going to ask that. Not because I don't think it's interesting, but because now I need to go on a rant, so buckle up, everyone. You know, I'm definitely not a DEI expert, but as an ND individual myself, I've learned one thing over the years about inclusion. And that is that selective inclusion, so reserving accommodations for just specific situations or individuals, isn't nearly as effective as building your entire how for the organization from an inclusive place.

Eddie Flaisler: Now, being inclusive doesn't mean not setting proper [00:27:00] boundaries or not prioritizing what's right for the business. If I need to reorganize, I will reorganize. However, in an inclusive organization, you do a few things around change in general, regardless of who is and isn't ND. I will confess that as a manager, I myself wasn't always as good about them.

Eddie Flaisler: Being mindful is always a growth opportunity, but these things felt great when I experienced them as an employee. So here goes. One, you communicate what is going to happen, why, and what the future looks like as soon as you have a fully formalized plan and are ready to answer questions to minimize panic. I know this point is a little bit controversial because some schools of thought talk about communicating as early as possible. It's always a balance. The question is, like in the example yourself provided, how ready you are to talk, right?

Eddie Flaisler: That's, that's always the most important thing. The second thing you do is when you encounter resistance or [00:28:00] skepticism and, you know, naysayers, you have to distinguish between two types of behaviors. Behavior one, I'm in distress, so I'm asking questions and looking to my leadership team for support and possibly venting to my teammates, but still distinguishing between personal fears and actual facts.

Eddie Flaisler: That one should be met with a lot of empathy. Making time for one on ones, making time for listening sessions across all leadership levels to give and to get more context, whatever is needed. Behavior two, I poison my environment by catastrophizing in public and sharing backstories I made up in my head to air my personal frustrations at the expense of other people's sense of safety.

Eddie Flaisler: That one, Morgan, I've even fired for when feedback didn't help. That pattern needs to be nipped in the bud. For everyone's well being. As for the third thing, I know we don't have any therapeutic responsibility towards our employees, but the fact remains some people need their pain witnessed [00:29:00] more than others. So to the extent feasible, I always recommend more frequent check ins with people whom we know have had concerns, regardless of whether or not their diagnosis is ND.

Morgan VanDerLeest: Yes. You know, I mentioned that story earlier about the derailed Eng All Hands. One of the first things I did after that meeting was just creating a private channel for all my reports where they could comment, have a place to voice their thoughts in a safe place and since the topic of that conversation was performance evaluations, I wanted to make sure Hey, y'all get to hold me and leadership and management responsible also, and hold us to a high bar, just like we were expecting a high bar of the engineers on our team. So in combination of that Slack channel, checking with folks on one on one, just making sure what clarity can I provide? What are you unsure about? And then making sure that the little strings of thoughts that you receive within those, tying them back together into a cohesive thread that then everyone can understand and be aware of. Very important again, communicate well, not necessarily more.

Eddie Flaisler: Absolutely.

Morgan VanDerLeest: So Eddie, we talked about types of transitions [00:30:00] and how to measure their effectiveness. I wonder if we can spend the rest of our time today talking a little more strategy. So let's say a reorg needs to happen. Whatever we have right now is not working as well as it should. What do we do?

Eddie Flaisler: Okay, so first, let's get specific on a reorg needs to happen. To make this discussion interesting, we should probably focus on the first two reorg use cases. Right sizing and rethinking. Why? Because those represent a situation where three things can happen. Live software is potentially left orphaned or under supported.

Eddie Flaisler: Established team dynamic, which was potentially conducive to strong delivery, is now broken because the team got broken up. And people can lose their professional identity and mission drive, which was tied to what they were doing previously. And you know, that's a big risk to individual performance.

Morgan VanDerLeest: Do we want to include layoffs in this?

Eddie Flaisler: You know, let's touch on that at the end if we have time, because the etiquette [00:31:00] around reduction in force is a whole thing. I prefer we start with a hopefully more common use case, where we just move people around.

Morgan VanDerLeest: All right. That works for me. Where do we begin?

Eddie Flaisler: With the holy grail of organizational design, the Spotify model.

Eddie Flaisler: So the Spotify model, which to be honest, I'm not sure is what they still use today, but it was apparently successful 13 years ago when the white paper was published, is the most famous example of transitioning into a matrix organization, or as I like to call it, a reorg proof reorg. It is a work structure where team members are part of two teams at a time.

Eddie Flaisler: A team of people sharing their professional expertise, which is called a chapter. And a cross functional team of people working on a specific area of the software, which is called a squad. In this model, your people manager is your chapter lead, and your project manager is your squad lead. The idea is that since your assignment to a people manager and your home team is [00:32:00] about your technical expertise and not about what you currently work on, product can change focus areas and pivot as much as they want without having to reorganize the entire team every time to realign with the new goals.

Eddie Flaisler: You just change squads.

Morgan VanDerLeest: That sounds great, but I don't think that addresses all or even most of the problem statements that we're trying to account for when considering a reorganization. First, if people build something, and then they switch, who's left to manage that orphan software? Second, this does solve the sense of identity issue because now your story is that you're a machine learning engineer for the company and not for a specific team that can be dismantled. But if squads keep forming and disbanding, you still lose that team dynamic with the people that you work with.

Eddie Flaisler: You're not wrong, and this model has its share of issues, and quite frankly I don't know how Spotify in particular overcame them. I will say, it's been my experience that the Spotify model works like magic For domains that are both long lived in nature and are inherently about supporting other teams, or in plain [00:33:00] English, Platform, Data and Data Science, Infra, Security, SRE, Developer Experience, QA, if your engineering is into that.

Eddie Flaisler: The needs from these functions change, but they rarely go away entirely once you as a company are beyond the MVP stage. And also, the people in these functions are used to deriving their motivation from supporting changing initiatives and typically enjoy nerding out on the shared technical challenges as opposed to attaching their satisfaction to some customer facing feature they will inevitably move on from.

Eddie Flaisler: With these teams being embedded in changing squads has the potential of working really well. There's always someone to support what they built because, you know, the home team remains and they are anyhow most effective when they work closely with their internal customers as opposed to developing something great together in a vacuum and then being shocked they're seeing adoption challenges as we discussed in the previous episode.

Morgan VanDerLeest: Take a listen. If you haven't. Anyhow, it sounds great, but what about [00:34:00] product facing teams? I think that's where the most pivoting tends to happen.

Eddie Flaisler: That's true. And I personally find the matrix model less ideal for, let's call it product engineering, where you build stuff for customers who are not other engineers in your company.

Eddie Flaisler: I do think that when it comes to product engineering, you need to augment your org design with some extra stuff, because there's a limit to how much clever organizational designs will help.

Morgan VanDerLeest: Say more about that.

Eddie Flaisler: Well, as we said, the only thing certain about the product or service your company is offering is that it will change. So while I discourage overly frequent directional changes, the reality of technology businesses, especially in high growth stages, is that teams will rarely stay together long enough to build that magical rhythm, you know, that dynamic where people collaborate effectively and with very little friction.

Eddie Flaisler: This also means that customer facing functionality will end up frequently changing hands, no matter how you design.

Morgan VanDerLeest: So what are you saying here? Should they just give up?

Eddie Flaisler: No, no, not at all. What I'm saying is that this is exactly where [00:35:00] everything we've talked about in the past comes to play. A culture of documentation with runbooks, ease of onboarding to a system and its stack, clear and consistent expectations and work norms. All these things translate into a much easier life when we're building team dynamic and inheriting someone else's software.

Eddie Flaisler: That's why the balance we always talk about between shipping frequently and shipping a net negative to the business is so important.

Morgan VanDerLeest: I'm not saying I disagree, but admittedly I would not want us to leave people with inheriting software nobody wants and losing your teammates is just part of life. Especially since you and I have discussed mitigation techniques in the past. Not to mention that without an agreed upon system for making these organizational changes, considerations that aren't entirely professional might slip into these transitions.

Morgan VanDerLeest: Do you know what I mean?

Eddie Flaisler: Oh, I definitely do. I would be lying if I told you I've never seen people force borrowed to another team or a system no one wants to own suddenly dropped on an [00:36:00] unsuspecting group which has no logical connection to that functionality simply because the leader who needs the person or doesn't want the system has a lot of social capital and not because the transition actually reflects the business need.

Eddie Flaisler: These things do happen. But the fact of the matter is that when an organization's culture allows them to happen, then no process would get in the way. So this goes back to something we talk about a lot, which is, what kind of organization do you want? One that does its best to minimize politics and focus on what's right for the business and the people, or one that's riddled with it. Having said that, there might still be a system for this.

Eddie Flaisler: So, over the years, I started believing more and more in tiger teams or swarming as a way for product engineers to help address ad hoc business opportunities without breaking the entire org structure.

Morgan VanDerLeest: Wait a minute, Tiger Team. As in, grabbing people from each group and making a task force? [00:37:00] I'm pretty sure that you used to hate that. You were always saying how this leaves teams starved for resources, but because on paper it's only temporary, you never have a handle to justify more headcount.

Eddie Flaisler: I did, and I still think that. So, to those unfamiliar, the idea behind swarming or creating a tiger team is, just like Morgan said, to create a task force, often cross functional, around this thing that needs to be built. The model has two main advantages. One is that the assignment to the tiger team is time bound, so the team isn't losing an engineer indefinitely, And you don't need to go through the motions of spinning up a fully fledged, HR recognized team for something you're not actually sure will be needed long or even medium term. Two, because this group of people isn't actually part of an existing team, They're not constrained by any of the limitations these teams currently have, which can stem from things like, you know, their stack or their ways of working.

Eddie Flaisler: It truly [00:38:00] is like a micro startup. The problem, and I believe we touched on that in the past, is that if you don't put proper guardrails to this practice, it can be a disaster.

Morgan VanDerLeest: Now those I definitely remember. One is it cannot be standardized as a solution every time product has a new idea. It has to be reserved for opportunities where there is consensus between product Engineering and the rest of the business unit leadership on pursuing the opportunity and taking that risk.

Eddie Flaisler: Because otherwise, it's even worse than defunding a team. On paper, you have all the headcount you need, but in practice, you don't have enough people to do your job because they keep being borrowed. That's right.

Morgan VanDerLeest: Another is there needs to be a rotation. You can't keep picking the same people for those tiger teams, no matter how good you think they are. Because you're burning them out and you're making it clear to the rest of the team that they're all second class.

Eddie Flaisler: Which is why the senior leader doesn't tell the engineering manager which people to give. They ask them which one this time.

Morgan VanDerLeest: [00:39:00] Yes. Now a third is the time limit is sacred. And the scope and the definition of done are agreed upon between the lead or the sponsor of that Tiger team and the lead whose resource you are taking. And if that commitment is not kept, it needs to be a big deal to minimize those instances going forward.

Eddie Flaisler: Because if we're going to hold the leader of the team we borrowed from accountable to their own deliverables, they need to be able to plan.

Morgan VanDerLeest: Yes. And then of course the fourth, there's clarity on who's going to maintain the thing once it's out and the Tiger team is disbanded. Because if, for example, it ends up being the person who built it and their manager did not account for that. It's again, as if we took away head count from a team without actually acknowledging that.

Eddie Flaisler: Ain't that the truth?

Morgan VanDerLeest: So Eddie, I definitely think the two patterns we covered today with matrix organizations and tiger teams that they compliment each other well. And if used correctly, it can be a good sustainable solution in many cases where directional change is so frequent [00:40:00] that you need repeated restructuring to catch up. And that could just be the reality of your business. Now, I know we said we were not necessarily going to touch layoffs, but I do feel like the past two years have been so full of that in the industry that we can't truly give an overview of reorgs without at least addressing that. Do you want to get into that a bit?

Eddie Flaisler: Look, here's what I don't want to do. I don't want to discuss layoffs in this episode as a form of strategy. It is indeed sometimes necessary, but I think that when we get to a point where we have to let go of people and have no choice but to reduce every individual to the dollar amount we spend on them per year, The pressure from stakeholders is typically so high that there's very little room for strategy, so I don't think it's a good use of our time for today's episode.

Eddie Flaisler: Here's what I will say. No matter what the purpose of the reorg is, it is always a good practice to take the opportunity and make your org structure more defensible. It will not guarantee surviving a layoff, but it certainly won't hurt. To me, [00:41:00] defensibility means two things. One, Value stream management.

Eddie Flaisler: That thing we said in the last episode that we will touch on briefly today. At its core, value stream management means repeatedly reviewing your value streams to make sure your team's time allocation justifies its existence in its current form. The first time you do it cannot be when a layoff decision needs to be made very soon.

Morgan VanDerLeest: So you just said your team's time allocation justifies its existence in its current form. Was that a euphemism for make sure they are contributing?

Eddie Flaisler: No, no, I'll give as usual an extreme example to clarify my point. So I inherited a team once that about a month before being reassigned to me experienced an outage where many important records from a data store they owned were lost. There was a way to restore these records automatically, but it entailed using a very expensive vendor.

Eddie Flaisler: A decision was apparently made that in order to avoid paying that vendor, the team would be recreating the datastore entries manually based on some legacy files they had access to. These files could not be imported with [00:42:00] existing tooling, so by the time I inherited the team, six very competent and hardworking engineers at a total employer cost of 1 million per year, have been copying and pasting records eight hours a day, five days a week for the past month, and with the prospect of doing so for four more months.

Eddie Flaisler: This is a true story. Now, Morgan, this team actually had some very important stuff to do for the business. It was obviously not mission critical enough for someone before me to refuse having the entire team spend five months on work that would be considered a waste of time even for an intern, but they should definitely not have been the first pick if some, but not all, non mission critical teams needed to be cut.

Eddie Flaisler: But let me tell you, had I not put an end to that and resurfaced the work they should have been doing, they would have been let go in the first reduction of force. And honestly, understandably. Why are we paying them so much money?

Morgan VanDerLeest: That's a really interesting story. And I think. That's one of those cases where it can be so [00:43:00] useful to take some chunk of time with your team to take a step back Look at the work that you're doing Is what we're doing the most valuable thing that we could be and if not, let's have a conversation about that. Just because at some point in time a decision was made to do something doesn't mean that that didn't change since then, or that the value of what we're doing is more or less valuable than something else that we could be doing. And if you're just in the weeds, which that sounds like you very much were just like chunking away at getting things done eight hours a day for a long period of time, you're not taking the time to think about, hang on, is this really what I need to be doing with my time? Is this what this team should be doing with their time? Obviously helpful when the manager can do that, but there's no reason why you can't involve a team in that process as well. Because again, and I firmly believe this, there's a reason why engineers are some of the most well paid people at the company. And it's not because they're code monkeys. It's because engineers are smart, capable, passionate people who bring a lot of external knowledge and a lot of other things [00:44:00] that if you just look at them as code producers, you're missing out on.

Eddie Flaisler: Hence, exactly why it's always a good thing to review the work again and again and again. If done effectively, it is not a waste of time, quite the contrary.

Morgan VanDerLeest: Absolutely. So what else on defensibility?

Eddie Flaisler: Well, this one we actually talked about in our unit economics episode, span of control. I again cannot overstate how important it is to have a healthy ratio of managers to engineers, designers, and otherwise individual contributors.

Eddie Flaisler: You know, Morgan, you and I created this podcast to help remind people how important and impactful good people leadership can be. It doesn't change the fact that at times of financial distress, All that managers are, across all levels, is someone we're paying instead of getting another pair of working hands.

Eddie Flaisler: You want a ratio of managers to non managers that makes sense. The benchmark for that is pretty consistent across research functions like those of McKinsey or Iconic. It's about [00:45:00] six to eight individual contributors to a manager minimum. And the calculation usually also takes into account everyone up to the director, group manager, tribe lead level. Tribe lead is what they use in the Spotify model. So, for example, if you have two teams, each with eight people, Each team has a manager and both managers report to a director. Your ratio isn't 8 to 1, it's 5.3 to 1. Because you have 16 engineers and 3 non engineers. By the way, not telling anyone with less than 6 reports to freak out. Just something to think about long term when looking at your total contribution to the organization.

Morgan VanDerLeest: An interesting flip there too, is just like you want to make sure that you have the domains to support the engineers that you have, you want to make sure that your managers are getting reps with enough engineers. Obviously, there are many situations, but likely if you're putting managers with [00:46:00] only a handful of reports, and that is like the main focus of their job, you're not giving them enough reps, flexibility, understanding processes to get through with folks so that they can continue becoming a better manager. Something that I've noticed is lacking in a lot of organizations is the craftsmanship of being a manager. You don't spend the time in enough one on ones and reviews and performance situations and just things that come up over time if you don't have a large enough team. Now mind you, again, there's various situations.

Morgan VanDerLeest: Maybe you had a bigger team before and now you don't, but you have the experience that you can bring from that larger team in the past to do well. That'll make sense. But it does kind of go both ways. It's not just being able to support the ICs, but also making sure that you're building up that expertise and that craftsmanship within the managers that you do have by keeping that ratio well balanced.

Eddie Flaisler: That is very, very true. More people, more practice.

Morgan VanDerLeest: So on the topic of a reorg that includes layoff, are there any particular do's and don'ts?

Eddie Flaisler: So, I have my own etiquette. Not sure if that's the [00:47:00] gold standard, but I found it helpful. One, no matter what I do, I don't make it the fault of the people leaving when communicating to others about the departure. I've seen situations where leaders assumed that if they would tell the remaining people, those we let go sucked anyhow, it would somehow make people feel better.

Eddie Flaisler: In practice, what it tells the remaining team is not only that we're - pardon my English - dicks, but also that our performance management process is broken. People need to know that performance management is working so they can assume their source of income is safe unless they are told in a very structured manner that they need to improve.

Eddie Flaisler: If there's no safety, there's no reason to stay and wait for the shoe to drop. A layoff is about the business not being where it needs to be, not the people. The second thing is that, if applicable, I own my part in our inability to retain these employees. As a personal example, you know, I still wonder today if I could have done more preemptively to further minimize the layoff we [00:48:00] experienced at Lob.

Eddie Flaisler: I was heavily focused on us executing to move a specific metric I was asked to look into, but it doesn't change the fact that I was hired into a position Senior enough to influence what product and engineering we're working on. And, you know, there were areas of opportunity to make things better that I might have missed.

Eddie Flaisler: So when the time came, I shared that at a high level with the team, including what I'm changing. The third thing is owning the decision. So one of the cheapest tricks in the bad management book is creating an us versus them situation. I think we've said that in the past. I want to give you all these things, but leadership, whoever that might be, doesn't want to. This might make the conversation a little more comfortable for the person delivering the news, but what the team is left with is, "oh, this person does not have a seat at the table. Our interest is not represented in any way."

Eddie Flaisler: So when I announce something like this, I am very clear that I was part of this unfortunate decision. It surprisingly [00:49:00] helps.

Morgan VanDerLeest: That is so, so important, and it's one of the reasons why it's important to make sure that your leadership and managers are themselves a first team to each other because that is the group that you need to be responsible for and understanding of and you work together and figuring out cool. How are we aligned on this? Even if we have dissent and disagreement, that's fine, but align and figure out how to bring this message back to your folks so that it's coming from a unified place and there's not these various conversations popping up about differences in how folks talked about things.

Eddie Flaisler: Absolutely.

Morgan VanDerLeest: All right, Eddie, it's time we start wrapping up for the day.

Morgan VanDerLeest: But before we do, I thought we could share some insights about organizational design in the AI era, it's all very new. So our guess, it's probably as good as anyone's, but looking into that would still be interesting.

Eddie Flaisler: Well, chances are that as we speak, someone is writing a book about AI era org design, and I definitely look forward to reading that. In the meantime, one thing is already noticeable, and that's the fact that the AI based [00:50:00] employee is already here, whether or not they are qualified enough to do the job just yet. You know, if you look at your average pitch deck these days for the up and coming startups, the narrative is no longer we're going to employ half the planet.

Eddie Flaisler: It's, we're going to be 30 humans at most. So we'll probably start seeing more and more smaller organizations that are not entirely human based. When that's the case, what I think happens is that you need less managers, but you need more people managing.

Morgan VanDerLeest: You mean in the sense that you have less people to manage, but since AI won't be entirely independent anytime soon, you need people to guide and verify its work.

Eddie Flaisler: That's right. And to me, that implies a change of the work of both individual contributors and managers that goes beyond, you know, including prompt engineering in the job definition. So, with managers, there will be less room for those who are not hands on, simply because the org is smaller and more quote unquote employees require closer [00:51:00] supervision.

Eddie Flaisler: But I think the most interesting and unexpected change, the one which will force reimagining what org charts look like, will actually be with the individual contributors.

Morgan VanDerLeest: Ooh, I think I see where you're going with this. Engineers are used to growing their career by expanding their tech stack and sharpening those architectural chops. But the growth needed here isn't necessarily technological. If your assigned AI buddy brings a lot of the coding, you need to know how to break a problem into smaller pieces that can be directly translated to code changes. You need to coordinate with your dependencies. You need to negotiate with stakeholders. You need to get clarity on those requirements. So I'll be at a smaller scale because it's just about your work and not the entire team ICs might have to acquire skills that are typically associated with engineering leadership, even as a baseline for an entry level job.

Eddie Flaisler: That's exactly right. And that is exactly why I cringe whenever I see on LinkedIn some clickbait like "product management is dead". It's the exact opposite. We are [00:52:00] now all product managers. Now, you brought this up in the context of work design. So, let's think about it. We're saying cycle time for feature development will inevitably reduce.

Eddie Flaisler: And that the nature of work for ICs will be more vertical. So not just coding, more end to end stuff. Sounds familiar? It's the extreme version of the problem we tried solving today with the matrix model. Frequent changes and coordination with multiple dependencies slowing you down. So, if I were to prepare an org for that right now, My main assumption would be that changes in our scope are going to be a lot more frequent and that the work which individuals own will be more end to end than a piece in a team's puzzle.

Eddie Flaisler: So, definitely group people based on something much more high level than the product or feature they're currently working on. That's what my instinct tells me.

Morgan VanDerLeest: I love that you brought up click bait. There's so much misinformation going on right now, like that soundbyte of Satya Nadella saying SaaS is dead because now people just want [00:53:00] agentic AI.

Eddie Flaisler: That's like level 1000 bullshit and totally not what he meant. It's not an apples to apples comparison. Agentic AI represents the business logic you're offering.

Eddie Flaisler: SaaS represents the delivery methods. How are people thinking of exposing the agentic AIs to the public? With a pizza delivery guy bringing the agent to your doorstep? This is so ridiculous. The actual idea is that customers will now be expecting more from their software, which can be SaaS or anything else, including the reasoning capabilities an agent can offer.

Morgan VanDerLeest: Now that you've mentioned pizza, I'm hungry. And this is actually very relevant to system design. It's like Conway's Law, right? Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. So to create something as autonomous and adaptable as agentic AI, you don't have a choice, but to have cross functional teams that can change scope quickly because otherwise autonomy is not what you'll end up with.

Eddie Flaisler: [00:54:00] Bingo.

Morgan VanDerLeest: And that's actually super related to what we talked about in the last episode about that adaptability of your teams.

Morgan VanDerLeest: It's not just going for efficiency. It's how well does individuals and teams able to adapt and work together.

Eddie Flaisler: 100%. And to the listeners, if you enjoy this, don't forget to share and subscribe on your podcast player of choice. We'd love to hear your feedback. Did anything resonate with you? More importantly, did we get anything completely wrong? Let us know. Share your thoughts on today's conversation to people driven development.

Eddie Flaisler: That's one word peopledrivendevelopment@gmail.com or you can find us on X or Twitter @pddpod. Bye everyone.