People Driven Development

Episode 18: MergeSort - M&As from an Engineering Standpoint
===

Morgan VanDerLeest: [00:00:00] Hey everyone, and welcome back to the PDD podcast. It's been a minute, Eddie and I have both been heads down with our respective work, but we're back and ready to keep going with our 2025 goal of covering some very specific and pressing questions in engineering leadership right now. The idea for today's episode didn't come directly from a listener question. It just felt like a natural continuation of the discussion we had with Robin Atwood a few months ago about the work required before a technology product organization can be considered attractive or in some cases even viable to potential buyers.

Today we're flipping the perspective and we're looking at the problem from the side of the company doing the integration through an acquisition or merger rather than the one being integrated. With the explosive growth of AI oriented products and companies over the past 24 months, there is a huge wave of technology organizations that are likely to either be acquired or merged.

In some cases there is a clear acquirer. In others, the merger is a little bit more mutual, but either way, someone ends up responsible for absorbing a new product and or team. So for engineering and product leaders [00:01:00] on the integrating side, this introduces a challenge they might not have had much experience with, which is bringing someone else's system into their own. And that's our focus for today.

Eddie Flaisler: What's the name of that book by Michael Lewis about climate apocalypse The coming storm.

Morgan VanDerLeest: Yeah, something like that.

Eddie Flaisler: Well, let's get our raincoats out 'cause it's about to start raining startups.

Morgan VanDerLeest: And I see the time off did very little to improve your dad jokes.

Eddie Flaisler: Nobody asked you Morgan.

Morgan VanDerLeest: I am Morgan.

Eddie Flaisler: And I am Eddie.

Morgan VanDerLeest: Eddie was my boss.

Eddie Flaisler: Yes.

Morgan VanDerLeest: And this is PDD: People Driven Development. So Eddie, M&A: mergers and acquisitions. I was looking forward to today's conversation, but I do wonder so many different situations fall into this bucket of M&A, that it does sound a little over ambitious to cover in one episode. I believe I saw a program of almost like a hundred hours on Coursera for just mergers and acquisitions.

Eddie Flaisler: Yeah, you are probably talking about your Urbana-Champaign one. It's a great series. It's taught by a Brazilian economist named Heitor Alameida, who I love, not only because I think he's an [00:02:00] excellent teacher, but also his name sounds like Hater Alameda, which coincidentally used to be my nickname on the Alameda County Nextdoor app.

Morgan VanDerLeest: Can you just not.

Eddie Flaisler: Whatever. To your point, the different M&A scenarios really are practically endless, but I think it becomes a lot more tangible if you group M&A by motivation. Doing that not only gives the conversation some structure, but it also helps us quickly filter out situations where optimizing how the product and team are absorbed probably isn't a priority for the acquiring side.

Morgan VanDerLeest: You mean like when acquiring a company to actually destroy its value?

Eddie Flaisler: That's exactly right. I usually put mergers and acquisitions into three buckets. Value creating, value destroying, and CYOA choose your own adventure. The value destroying ones are not really worth our time today. They are usually legitimate business scenarios, but their quote unquote, success is often measured by something other than whether they create sustainable long-term business value for the combined company. So trying to optimize R&D execution doesn't [00:03:00] actually promote the goal here. You might actually be completely disinterested in keeping the acquired company alive.

Morgan VanDerLeest: Do you have some examples?

Eddie Flaisler: Sure. Sometimes this happens when a company in distress is bought cheaply with no real plan to turn around. The goal is simply to break it apart, sell off the physical assets and intellectual property, and recover value that way, rather than build a stronger business. Sometimes it is pure tax arbitrage. That could mean moving headquarters to a country with a low corporate tax rate. Or merging with a company in a different industry that enjoys more favorable tax treatment. The combined company than gets reclassified under that industry's tax rules and pays less in taxes, even though nothing about how the business operates has changed.

Morgan VanDerLeest: And sometimes it's driven by fear, right? A company rushes in to buy a rival mainly because it worries a competitor might get there first, or because it believes new antitrust rules are coming, that will block that deal later. And then the result is a transaction being pushed through quickly without a clear way in mind for the two businesses to compliment each other or create lasting value [00:04:00] together.

Eddie Flaisler: That's right.

Morgan VanDerLeest: Now you mentioned a choose your own adventure bucket. Can you elaborate on that?

Eddie Flaisler: You know, it's funny, most M&A statistically falls into the value creating bucket, which we'll get to, but I find that the CYOA bucket is where execution really makes or breaks the outcome. This is where a great technology function can be the difference between exceeding expectations and a bitter disappointment. CYOA is when you buy a company, not because it is this perfect fit that obviously unlocks synergies, but because there is some other business reason to grab it and keep it alive. Maybe it is cheap with good ROI, maybe it can fill a gap you're not sure how to fill internally. Maybe it protects you from risk. The success or failure ends up being almost entirely about what you do with it once it's yours. An old but classic example is when Google bought Motorola Mobility . Google bought Motorola Mobility for its massive patent portfolio, which it needed to protect Android from lawsuits. That made the deal more of a defensive move than betting on a new vertical. The thing is, it could have also been [00:05:00] Google's springboard into building a vertically integrated smartphone business years ahead of Pixel. And you know, give Apple a run for its money. Instead, they kept Motorola separate. They released only a handful of phones eventually sold the handset business to Lenovo while keeping the patents. It did succeed in protecting Android. But by not committing to hardware early, Google ended up building the Pixel business from scratch years later, and still trails far behind Apple and Samsung today.

Morgan VanDerLeest: You know, that's a great example. I think that especially when we look at M&A from an organizational perspective. Another good example of a deal whose success depends almost entirely on execution is an acquisition done for the purpose of long-term restructuring. This can happen for private companies as well, but is mostly the case when a public company is taken private. So the new leadership can make difficult or long horizons strategic shifts without the pressure of those quarterly earnings.

Eddie Flaisler: Elon, if you're listening. Hi.

Morgan VanDerLeest: Ah, he just twitted "hi" back.

Eddie Flaisler: You see, I'm not the only one who makes dad jokes.

Morgan VanDerLeest: [00:06:00] Moving on. So, Eddie, I know we haven't gotten to the most common M&A type yet, but just in case I'm reassuming the role of being the one who keeps us on track. we spent the past few minutes talking broadly about what M&As are, what is out of scope for our conversation, and which type is particularly execution dependent for its success.

I think it's time we got a little more concrete and dove into what these events actually look like on the inside for the organization, absorbing the company.

Eddie Flaisler: Almost. First, we need to introduce the concept of synergy.

The word synergy might sound fluffy and very corporate, but in business it means something very specific. It means that the combined value of two emerging companies is greater than the sum of their individual values. This is typically achieved in one of four ways. Let's use some real world examples to cover all of them. The first one is economies of scale, meaning a company reduces per unit cost by producing at a larger scale, which increases profits. In 2022, just a few months before ChatGPT launched, Microsoft bought Nuance Communications for [00:07:00] almost $20 billion. Nuance specializes in speech recognition for clinical documentation, so basically capturing and processing patient information for doctors and hospitals. This was a textbook economies of scale play. Why? Because Microsoft spends heavily on training AI models and maintaining the GPU capacity to serve queries. The more paying customers it can add, especially new markets like healthcare, the more those fixed costs are spread out and the better the return on those investments. If you think about it, this is the same logic Microsoft applied when it partnered with Take the enormous fixed costs of building and running frontier models and spread it across Azure customers, GitHub, copilot users, office 365 subscribers, and even bing search traffic, right?

So that every additional use case makes the economics better.

Morgan VanDerLeest: Okay, I see what you're saying. And and Nuance got the flip side of the deal. It got instant access to Microsoft's global reach. It got enterprise sales teams, and of course massive cloud capacity, which meant its technology could show up in far more hospitals and health systems [00:08:00] than it ever could on its own.

Eddie Flaisler: Bingo. So the second way you achieve synergy is through industry consolidation. That basically means firms come together to build more market power. Sometimes it looks like the classic horizontal merger were two direct competitors combined forces. Other times it's about pulling together adjacent, but complimentary players. So instead of customers juggling a bunch of point solutions, they get one integrated platform that feels more valuable. A good example is Cisco's $28 billion acquisition of Splunk in 2024. Cisco already had a presence in networking and security while Splunk dominated observability and log analytics. What Cisco did was create a single platform that covers network data, security telemetry, and AI driven threat detection. Think about it. Who else can offer this end-to-end solution? That includes so many pieces that are complicated on their own. Companies are always prefer managing fewer vendors, and even if they were okay with managing more, there's no guarantee that the integration would be [00:09:00] straightforward. Cisco turned itself into the go-to provider for network visibility and security intelligence with the ability to sell bigger deals, right? They could charge premium prices and they could compete from a position of strength against rivals like Datadog and CrowdStrike.

Morgan VanDerLeest: And again, this also meant that Splunk got to play on a much bigger stage with more distribution and deeper integration opportunities.

Eddie Flaisler: And a lot of lunch money.

Morgan VanDerLeest: That too. Let's move on.

Eddie Flaisler: The third way is through economies of vertical integration. It sounds a little less familiar than economies of scale, but actually everyone knows what it means.

Morgan VanDerLeest: Right. So probably the idea is that you can achieve cost advantages by acquiring a major supplier of yours and producing everything in-house instead of procuring them from the market.

I can think of a good example here, the Nvidia Mellanox acquisition in 2020.

Eddie Flaisler: I love that so many of my former coworkers were acquired and are now millionaires while I'm literally recording this in a basement, but I'm not bitter. I'm happy for them.

Morgan VanDerLeest: Are you though?

Eddie Flaisler: No.

Morgan VanDerLeest: Anyhow, Mellanox made [00:10:00] the infinite band and high performance ethernet gear that ties servers and GPUs together inside a data center. So basically the plumbing that's lets giant AI clusters move data around fast enough to train huge models. By buying Mellanox, Nvidia locked down that critical part of its supply chain and could then fine tune InfiniBand specifically for, its A100 and H100 GPUs that made its systems faster, more efficient, and cheaper to run at scale.

Mellanox on the other side got access to NVIDIA's resources and customer base, which turned its technology into the standard for the world's fastest AI supercomputers. That is vertical integration at its best. Take control of an upstream piece. Make it work perfectly with your own products, lower costs, and build an advantage your competitors now have to work extra hard to catch.

Eddie Flaisler: I am still resentful, though

Morgan VanDerLeest: I can see why. How about the fourth way?

Eddie Flaisler: Eliminating inefficiencies. Well, this really is about unlocking value by running the acquired company better than it is being run today. And in many ways, that idea is already built into [00:11:00] most M&A rationales.

Whether it is economies of scale, industry consolidation, or vertical integration, there is usually an assumption that the acquirer will improve operations, cut waste, or just focus the business to get the most out of the deal.

Morgan VanDerLeest: But doesn't that also suggest something about the current management? They might be underperforming, running weak processes or working with the wrong incentives?

Eddie Flaisler: Yes and no. In many cases, it doesn't need to be framed this dramatically. As Netflix's chief HR Officer Patty McCord used to say, certain people are the right fit for certain stages in the company. This is not a euphemism. The typecast you need to get from zero to one isn't what you need from one to 100 different risk tolerance, different values regarding what is considered getting off to ship.

The list goes on.

Morgan VanDerLeest: Yeah, and you can even see that within a company itself. There are some people that can grow with that company over time, either 'cause they've been in all the phases before or they just adapt well. And then there are some folks who gravitate more towards various team and company compositions at various stages.

So they just fit better within those various [00:12:00] stages of company. Whether for a team size, velocity, legacy, code, debt, whatever.

Eddie Flaisler: Mm-hmm.

Morgan VanDerLeest: Do you have a good example of a move that was purely about eliminating inefficiencies?

Eddie Flaisler: Presumably, I think a very famous story is the Vista Equity Partners turnaround of Marketo. When Vista bought Marketo in 2016 for 1.8 billion, the company was struggling with rising costs and slowing growth. Vista did a lot there. they replaced key leadership. They streamlined operations, and they focus the product strategy. Just two years later, Marketo was sold to Adobe for 4.75 billion. More than doubling its value. That is exactly what eliminating inefficiency looks like. Take a business that is underperforming, fix the processes and leadership issues, holding it back and unlock the value that was already there.

Morgan VanDerLeest: You know what that reminds me of is people who flip houses for a living.

Eddie Flaisler: I couldn't think of a better analogy.

Morgan VanDerLeest: All right, Eddie, you got your full coverage of different M&A motivations. I have to insist that we dive now into what we promised this episode would actually be.

Eddie Flaisler: Let's do this. So [00:13:00] having surveyed all these different types, I want people to notice there is a strong common denominator to all non-value destroying M&As. And that common denominator is the fact that the assets you gain through the acquisitions are also constraints. One, you gain a customer base, but those customers come with expectations about SLAs, product quality, support, stability, all this you now have to meet. If their experience is already poor before the deal, You also inherited that baggage at the risk of churn if you do not turn it around quickly. Two, you'll gain a product or a set of products and with them come their own coding styles, architectural patterns, security posture, their existing third party vendor dependencies.

Not to mention quality and performance standards that may have been fine at a smaller scale, but could be a challenge to maintain now that you're bringing the product to broader audience. Three, you also inherit the existing build and deployment pipeline, which may or may not be close to how you do [00:14:00] things. And of course, four, there is the insane amount of operational know-how that you need to acquire. The operational know-how piece is actually pretty incredible. Personal example. For the past year, I've been focused on Mission Control as a solopreneur, usually with no more than one person working with me at a time. My guiding principle going into this was maintainability, simplicity and reuse. Even Even with all that context, I still ended up generating way more documentation than I ever expected just to keep the thing running. Production systems and especially enterprise grade software are very complex, man.

Morgan VanDerLeest: Very much so, and when you talk about operational know-how, it's a natural segue to the third Gained asset and constraint people. You inherit an entire team with its own perspectives on organizational norms and what good delivery looks like. And if the M&A spans multiple geographies, then you also have the cultural clash that can extend far beyond engineering principles into things like communication styles, decision making, speed, and even work life expectations.

Eddie Flaisler: Absolutely. Not to mention, you have [00:15:00] no idea what these people are thinking or feeling about this change. From your perspective. There are new, hopefully motivated employees, but some might be burnt out. Some Some might be disappointed if they did not like the terms of the deal. Some might be worried that the acquisition is just the first step towards their role being eliminated and some can simply be too protective of the system they built and now take identity in being the experts on to open to evolving it, to fit the new needs.

Right. This, by the way, ties right into our conversation about the expert archetype in our systemic imposter syndrome episode.

Morgan VanDerLeest: That's exactly what I was gonna point listeners to because we've definitely talked before about how to handle all these kind of people situations where folks are, not motivated, concerned about their expertise shifting, how do you deal with things like that?

Do you think there's any other constraints that we forgot to mention here?

Eddie Flaisler: Kind. We touched on this when we talked about customers, but it goes well beyond that. I'm talking about reputation, and market position. Inheriting that can be both a blessing and a constraint. If the company you just bought was known for [00:16:00] poor security or for buggy releases or for slow support, then your engineering and product teams now have to put in the work to fix those problems, right? You need to rebuild trust before new prospects will even give you a chance. But if the company was known for premium quality or this breakthrough innovation, then you now have to live up to those standards or else a narrative would be formed. A narrative that it's not what it used to be and you ended up damaging the brand you just paid for

Morgan VanDerLeest: Totally, and it's worth mentioning that it's not only the perception of prospective customers that can make or break things, but also that perspective of investors and partners. If your company just made a risky move by acquiring an AI startup with questionable strategy or moat, or the leadership just can't confidently speak to how this transaction aligns with practicing profitable growth, you might become very unattractive to those parties real quick.

Eddie Flaisler: a hundred percent. And we'll definitely touch on that today.

Morgan VanDerLeest: All right, so with the different constraints covered, where does that leave us?

Eddie Flaisler: Well look what we did here, Morgan. We created a four by four matrix. The [00:17:00] rows can be the different M&A motivations, economies of scale, industry consolidation, economies of vertical integrations, and eliminating efficiency. The columns are the constraints, customers, product and tech, team, and external perception. I actually have an monic device for remembering this as well.

Morgan VanDerLeest: Jesus, take the wheel.

Eddie Flaisler: No, no, it's not cringey. Hear me out. The vicious CPTO, like Chief Product and technology Officer.

Morgan VanDerLeest: Vicious CPTO so much for maintaining that neutral tone. All right, let's hear it.

Eddie Flaisler: Okay, vicious is vertical integration, consolidating industries, operational efficiency, and utilizing scale.

Morgan VanDerLeest: And CPTO is customer, product, team, and outside perception.

Eddie Flaisler: Yep. You see.

Morgan VanDerLeest: Okay, not bad. Vicious CPTO. Now we have four different motivations and four different constraint types for each. That's 16 scenarios to cover. Eddie, it feels like it's a bit [00:18:00] much.

Eddie Flaisler: I agree. That's why I think we should simplify. Instead of walking through all 16, let's focus on the two biggest constraints that really drive the outcome product and team. Many of the specific challenges around customers and reputation actually flow into those, Anyway. We can cover what M&A driven by different motivation means for these two, and along the way branch off to touch on customers and reputation when the scenario calls for it.

Morgan VanDerLeest: That sounds so much better. When you were talking about a four by four grid in an audio format. I was, I was sweating a bit, but that sounds much better.

Eddie Flaisler: Oh, totally. I do think it's important to always think about an M&A situation from this four by four matrix perspective and do the mental exercise of what idiosyncrasies, your specific combination of motivation and constraints has, which are worth focusing on.

Morgan VanDerLeest: It sounds good to me. So where should we start?

Eddie Flaisler: P - product and technology.

Morgan VanDerLeest: All right, go for it.

Eddie Flaisler: Okay. I'm going to ask this question. At the risk of sounding really, really old, have you ever heard of the Joel test?

Morgan VanDerLeest: It might sound really, really old to you, but [00:19:00] I actually work with a Joel right now and I still have no idea what you're talking about. So go ahead.

Eddie Flaisler: Oh wow. So Joel Spolsky founded and led for many years, two very famous tech companies, namely Stack Overflow and Trello. He's a software engineer by trade, and he came up around 25 years ago with a checklist named the Joel Test. It was meant to help developers vet prospective jobs, poster on Stack Overflow, and whether these employers would turn out to be places where they can grow and learn as engineers. When you posted a job on Stack Overflow, you had to answer questions like, do you have source control? Do you make daily builds? Do you have a bug database? Do you fix bugs before writing a new code? Do you use specs, et cetera, et cetera. Today, similar questions might be, do you have infrastructure as code? Like Terraform? Do you have a system for AI model lifecycle management? Are model training runs reproducible? Are your artifacts signed and verified before deployment? The reason I'm bringing up the Joel test is because it's a perfect example of something [00:20:00] that in today's "ship it" atmosphere feels like old world mentality. Especially with current market expectations around AI assisted development, where if you didn't deliver overnight, something must be wrong with you. But But here's the thing, these questions which focus more on how you're building rather than what you're building, are exactly where the attention should be. That shift in focus has to be the immediate next step once you've already decided the product is a good fitting concept and you validated that it actually does what it claims to do. Now, I know some might hear this and think, oh good, another OCD engineer who's going to kill our business while we wait for his perfect product. But I can tell you from a lot of experience, Morgan, that the spirit of Joel's test when assessing the technology you're buying, often called tech due diligence or tech dd, is not just important. It's all that matters. Why? Because the answers to those questions are the leading indicators for the two most interesting questions when acquiring existing tech. First, how [00:21:00] easy or difficult will it be to make changes so you can adapt it to your ecosystem and and to whatever requirements the rest of your company's software needs to meet, and you will make changes that much is guaranteed.

There is no such thing as truly turnkey. Second, and this one should make people's ears perk up, I hope. Can it actually help you build a defensible mo

Morgan VanDerLeest: You definitely said the magic words there, Eddie, "defensible moat". I feel like that phrase shows up in every other LinkedIn post I see these days. But before we get to that, I wanna double click on something you said earlier. I didn't like how casual and quick you were about, "once you validated that it actually does what it claims to do."

You said that and immediately moved on to the DevOps aspects. But hold on a minute. You of all people should know, this isn't that simple. It is super easy, especially these days to create a fake demo or even real software that does what the business you're signing a deal with claims it does. Just not in any sustainable way. You know, not scalable, not reliable, prohibitively expensive to operate due to design that was not at all cost conscious stuff [00:22:00] like that. With the exception of the eliminating inefficiencies motive, we mentioned when discussing reasons for M&A, where you already start from the assumption that besides a small scale solution and some patents and algorithms, they don't have much, All the other cases need this thing to actually work well before we even talk about making changes. it might not exactly match your ecosystem, But whether it's consolidation, vertical integration, or that economies of scale, You still need a mature, independent system as your starting point.

Eddie Flaisler: Not only do I think you're right, but actually it strengthens my point.

Morgan VanDerLeest: Say more.

Eddie Flaisler: Well, think of infrastructure as code, which I just mentioned. Solutions like Terraform have a lot of advantages like faster provisioning or rollback safety, and you can run a bunch of tests. But to me its biggest advantage by far, even if you're literally a one person company, and let alone if you're more than that, is trackability. The ability to have a single, organized, concise representation of everything that's going on in your system. Have you ever tried gaining that insight efficiently by looking at GCP console or [00:23:00] AWS console? I have. It's borderline impossible. You'll always miss stuff. That reserved ip, that bastion, this cluster, something. So when you're considering cloud technology that doesn't practice this type of hygiene, not only do you know it'll be so much more work when you do take over the infra to figure out the inventory. But you're also going to have a really hard time going deep under the time constraints you have and figuring out if you're not inheriting something, that in such and such use case will end up costing your company an arm and a leg because feature X was designed using this, I don't know, incredibly wasteful thread pool model, which is not easy to get out of.

You see what I mean? That sustainability you're talking about, or lack thereof, can only be properly assessed if your baseline is Joel style tests.

Morgan VanDerLeest: You know, I really like that a lot and the thing that it reminds me of is an ADR, like an architectural decision record. And, you know, maybe these are more small scale, but for any change that occurs to your system, you have a record of that thing and hopefully you [00:24:00] have some reasoning why or some context around that.

But having that built into your process feels way more valuable than deciding like, does this need a doc or context around it? What am I doing here? Then you end up not writing it, but having this built into the process for how your software and your company works. I like this a lot.

I'm gonna look into that more.

Eddie Flaisler: Absolutely.

Morgan VanDerLeest: so I'm also starting to see where you're going with this defensible moat argument. I think you know, in the world of AI native companies, the rules have changed completely. Technological progress is moving so fast that no matter how innovative your original idea was, it can quickly get swamped by competition or worse turned into a single feature inside someone else's platform. For a tech company to stay default alive, let alone grow at this point, it has to keep reinventing itself and what it offers.

It actually reminds me of our conversation in that "where's my innovation" episode?

Eddie Flaisler: I think you're spot on. Even if this M&A was in and of itself, that innovation lever you were hoping for, the company will need to keep going with reinventing what it does. Engineering is very much [00:25:00] responsible for the next big thing. That is why it is so important to make sure you're absorbing an adaptable technology.

And adaptable simply means two aspects. We've discussed a lot of this podcast, maintainability and extensibility.

Morgan VanDerLeest: Interesting. Eddie, I do remember from working with you that you were always clear with the leadership team about what engineering could and could not do and where it was or was not appropriate to hold us accountable. How does that align with what you're saying? With something like, " engineering is very much responsible for the next big thing".

Where's product in that picture? Where's the business leadership?

Eddie Flaisler: Well, I think that at the end of the day, this ties directly into designing the kind of engineering flexibility we talked about in the innovation episode. Engineering is ultimately a direct contributor to top level business metrics, like net dollar retention or year over year growth or gross margin. The quiet part is that we are also a contributor, not the sole contributor, but still a contributor, to the company's risk appetite. I mean, sure it is outside of our control if the CEO is risk averse, but regardless, we can operate or [00:26:00] not operate in ways that make leadership feel confident they can place bets and trust engineering to deliver. For example, a company might be willing to bet on expanding into a new product line or entering a new customer segment if they're not worried that asking engineering to do this will undermine net dollar retention. You cannot keep retention numbers high without quality, reliability, performance, and just as important a good system for acting on customer feedback. You see what I mean?

Morgan VanDerLeest: I do. So in a roundabout way, I think we've gotten to the point where engineers are really so valuable to the company, that it's not just about them producing lines of code anymore, and it's more about how they're orchestrating business changes within the code base, within the system. So if you're, utilizing, AI generation at its best, and you are more looking for business value than pure, I wrote this, I did this specific thing.

It really kind of turns on its head this whole idea that all you are is lines of code. No, it really is the impact that you're making and how you're integrated that impact into the business.

Eddie Flaisler: 100%.

Morgan VanDerLeest: Anyhow, this makes a [00:27:00] lot of sense. What about, year over year growth?

Eddie Flaisler: Well, this basically means customer acquisition. A company will be more motivated to think big and explore new ways to expand its total addressable market if it knows the engineering team ships fast and builds in a way that supports iteration quick experimentation. Now, it makes me cringe to even say this because both you and I have seen situations where engineering carried all the burden and faced unrealistic expectations, but was given none of the necessary support. Like the time or even bandwidth to invest in developer experience and infrastructure.

So I'm not saying this to hand a soundbite to anyone looking to absolve themself from responsibility and just point fingers at engineering. The idea is simply that engineering does contribute directly to how bold the company feels about chasing growth.

Morgan VanDerLeest: 100%. And I think to kind of go back to my comment a little earlier, it's not just. Oh, hey, engineering, we asked you to do the thing. Now do the thing and ship it. It's really more about ownership at this point. And not just owning the fact that the thing shipped, but how is [00:28:00] this affecting the broader picture here?

We need engineering to say, Hey, that's gonna break at some point or at this scale. If we don't think through it in this way. What are the ways that we can get ahead of scale, get ahead of potential new issues that other parts of the business may not think about, but that's engineering's job.

We need to be aware of how these moving pieces fit together, when they might break. I mean, at this point it's almost, you know, similar to a mechanical engineer looking at a machine. Okay, we've got X amount of life left. We need to start thinking about how we're gonna improve X, y, and Z parts of this machine before we're run into serious issues.

And if you don't say anything about that, that is on you, that is literally your job as the engineer is looking ahead to situations like that and figuring out what that tolerance is.

Eddie Flaisler: I cannot agree more.

Morgan VanDerLeest: Now, how about gross margin?

Eddie Flaisler: Well, that that is probably the most mundane yet one of the most important areas. Engineering does not control revenue, but it does control COGS, right? The cost of goods sold. The obvious example is infrastructure spent, compute, storage, logging, [00:29:00] observability. I spent many hours in my final year at LOB analyzing our AWS and Datadog usage, and it was well worth it. We saved a lot of money. If every incremental capability comes with a massive financial hit, then the business becomes demotivated to try new things.

Morgan VanDerLeest: Very much agree. I don't remember which episode it was. Maybe you do, we talked about building cost into how you think about your system. That is part of engineering. It's not just throw the thing over the wall and doesn't matter what the cost is. It's important.

Eddie Flaisler: And the episode is "unit economics is a thing".

Morgan VanDerLeest: I knew you would remember.

So Eddie, I think this is all very valuable and I'm realizing that we're focusing very much on what happens once it's been decided that a certain product or technology is a good fit for an I'm curious if engineering has a role at an earlier point as well, like in actually deciding whether this is even relevant to us at all.

Eddie Flaisler: Well, that's a great observation. It absolutely does. In fact, if you think about it, tech M&As in the value creating categories are more of a large scale [00:30:00] version of a build versus buy decision than anything.

Morgan VanDerLeest: Okay. I can see that. Go on.

Eddie Flaisler: So just to align on the definition, a build versus buy decision in software is choosing between building functionality in-house or adopting a third party product that already delivers the capability you need. It's a big decision to make, but it becomes more approachable when you break it down into three questions: relevance, cost, and risk. Relevance Relevance is about whether the technology is central to your mission and market differentiation. My time at Uber was a great example for that. For years, Uber relied on Google Maps, but over time it realized that maps are not just the background service, right? They directly drive ETA accuracy.

They drive routing efficiency and customer satisfaction, all all core Uber's business. That is why Uber started building its own mapping capabilities and ultimately acquired several mapping startups to support that. By contrast, we ultimately ended up using an external vendor for our customer support infrastructure. It's just not worth the investment. There are great products [00:31:00] out there and while support is very important, it's just not our core differentiator. When people call Uber, they don't call it because of our customer support. By the way, pop quiz, what type of M&A would buying a mapping startup be for Uber?

Morgan VanDerLeest: Come on, man. Value creating vertical integration.

Eddie Flaisler: Oh, I'm sorry. I forgot. You were too cool for school, Morgan.

Morgan VanDerLeest: You should be. Okay. I have a good cost example in mind. Netflix switching to AWS after years of running its own in-house data centers. Netflix used to do everything itself. It built parts of its own CDN. It staffed entire teams to manage servers. And even bought companies for video compression technology to reinvent streaming. But as its subscriber base exploded, the cost and complexity of scaling those data centers exploded too. What I find particularly interesting about the Netflix story is that the real issue is not just the money spent on infrastructure, but the opportunity cost.

Every dollar an hour poured into maintaining servers could have been invested into what truly differentiated Netflix: content delivery, personalization, and their user experience. It is a [00:32:00] bit like the cost of delay we talked about in an earlier episode, only at a much bigger scale. Thankfully, for them, they realized early on what the right thing to do was.

Eddie Flaisler: That's an amazing example. What about risk?

Morgan VanDerLeest: I think the example you gave earlier with Microsoft buying Nuance also fits perfectly here, even though we talked about it in the context of economies of scale. Microsoft could have tried to expand its own AI stack into that space, but building something that met HIPAA standards and earned trust from hospitals would've been enormously risky, right? By acquiring them, Microsoft got technology that was already proven in production with the regulatory compliance frameworks that customers trusted, and a team that understood the domain.

That's huge. The risk of failure or reputational damage from going at it alone was just too high. In this case, buying was the safer path.

Eddie Flaisler: That's a really good way of putting it. Risk is really just about uncertainty. Can you actually meet the industry standard for security, reliability, and trust if you try to do it yourself? Because if you can't, the fallout is brutal. Reputational hits regulatory travel, not good.

Morgan VanDerLeest: [00:33:00] Absolutely. So Eddie, we've spent quite a bit of time talking about product and technology, and I think it's time we switch to the T in CPTO, the team. But before we do, I think there was one last point worth touching on. Practically everything we've covered so far pertains to engineering assessing whether this M&A is going to work for the company or not.

But let's assume for a minute that the deal closed. It's here, we own it. Now what? Anything in particular we wanna highlight?

Eddie Flaisler: Well, I'm really glad you brought it up, Morgan, because I don't want it to sound like we're minimizing the complexity of what happens once the new technology is in the house. It's a huge amount of work and most of it isn't even about the shiny core functionality you just acquired. It's about stitching together everything around it: the data models, identity and access, infrastructure, observability. All of that has to be reconciled, and also you have to do it while staying mindful of the customer experience so they don't hit weird bugs or lose access or suffer downtime while you're migrating things. Now, we're not here to give engineers a migration playbook.

That's a whole book on its own. [00:34:00] The one thing I will say managers absolutely have to plan for is the two systems problem. If you If you ignore that, you've created a slow motion disaster before you even realize it. The two systems problem is when you end up running the same function in parallel in two different systems. Two CRMs or two identity stores, or two billing systems, and no one is sure which is the source of truth. It doubles operation costs. It multiplies failure points, and it confuses both employees and customers until you make a deliberate decision about consolidation or coexistence.

Morgan VanDerLeest: And going into any M&A, that is part of your process. At some point you know that there's gonna be doubles of these things, and which one do we pick? How are these things gonna work together? Does one do something the other doesn't? Or do we just pick one?

How do we make these functions work appropriately? You know, and at the best cost, there's gonna be some time of double spending, double effort, extra effort to get the thing to work. But the goal is that in the longer term, you've now made the best decision. Now you have this, these two broader systems going through one of these functions.

Eddie Flaisler: I cannot agree [00:35:00] more. It's an optimization problem.

Morgan VanDerLeest: All right, Eddie, I think it's time we switch to that team aspect. I remember the story you once told about one of your former employers acquiring a small startup. You mentioned that that team achieved virtually nothing in their first year, and that on the very day their acquisition RSUs vested. They all quit together. You inherited their product after the team left.

Eddie Flaisler: Yeah, I remember telling you that. As extreme as this story might sound, I think it's a very good story to guide our conversation around the people aspect of M&As. And you know, me, Morgan, I always try to withhold judgment.

Morgan VanDerLeest: Eddie, if you were any more judgemental, you would be nominated for the Supreme Court.

Eddie Flaisler: Okay, fine. Let's just get that out of the way. I think that team was horribly mismanaged. Okay. If I order a manager of Temu, I think whoever managed them at that time would be the one USPS delivers.

Morgan VanDerLeest: Oh, come on, Eddie.

Eddie Flaisler: So with that out of the way, we can get back to being professional. As you yourself pointed out, when we discuss technology, we spend the majority of our time on what engineering does before the deal is closed. For the team aspect, we should definitely [00:36:00] focus more on what happens when the team is already here. In my experience, there are three main pieces to this. One is avoiding an us versus them dynamic. Two is managing the expert archetype, we covered in the systemic imposter syndrome episode, and three is handling team members who arrived here already burnt out.

Morgan VanDerLeest: You know, when the situation comes up, it puts you in one of those really unique scenarios where obviously what we've talked about a lot here is you're going for eliminating inefficiencies, but again, working with people, there is some amount of inefficiency that's just built into being human and going through change.

So just an important thing to keep in mind. That said, let's go in that same order you mentioned starting with us versus them. We've talked about this pattern before. We mentioned that a classic wave managers accidentally create this is by saying something like, I wanna give you what you're asking for, but leadership won't allow it.

The problem with that framing is it paints leadership as the enemy, and that's a no-go. A manager's role is to be the team's proxy into leadership to help make those decisions and [00:37:00] trade-offs more understandable, not to fuel animosity and distance between the two sides.

Eddie Flaisler: That's exactly right Morgan, and I think it's pretty clear how important it is to avoid falling into the us versus them trap, especially when you've just inherited a team that feels like strangers to your company, but still has a strong sense of belonging with each other.

Morgan VanDerLeest: I feel like I instinctively understand why it's particularly important, but I'm not sure it's as obvious as you make it sound, so let's break it down.

Eddie Flaisler: Well, for that, we need to meet Rice University's very own Professor Daan van Knippenberg. Daan van Knippenberg is a professor of management at the Jones Graduate School of Business at Rice University. He does a lot of interesting research around leadership, but what I find particularly engaging about his approach is that he applies social identity theory to organizational context. Or in simpler terms, he reminds us that, be it in a corporate environment or not, we're all still human. In 2002, he published a paper called "Organizational Identification after a merger". It became a cornerstone in M&A research. What he and [00:38:00] his team found seems initially quite expected. When two companies come together, people from the higher status side, usually the acquirer tend to double down on their pride and attachment to the new organization.

They're doing great, right? They just bought a company. But for people on the lower status side, it often feels the other way. Their identity feels diminished, their sense of belonging drops and their willingness to bind to the merger weakens. But here's the kicker. what they found was that it's not how the new org is performing, or even the differences in culture that drive this feeling of alienation. It is a simple prestige gap between the two groups, which is inherent to the situation that is enough to spark an us versus them dynamic and can derail integration long before anyone even talks about strategy or process or how you treat people. That is why it's so common to hear acquirer employees say "Nothing really changed for us" while the acquired side feels like their entire world has been turned upside down. And that Morgan is where our problem begins.

Morgan VanDerLeest: Because [00:39:00] how is a manager supposed to fix alienation that has nothing to do with how they run the team.

Eddie Flaisler: That is exactly right, and it's also one of the strongest examples for why smart organizational design is so important.

Morgan VanDerLeest: Because if the problem isn't a manager failing to promote psychological safety or belonging within the team, then the solution probably isn't that either. I remember this, the researcher around it basically showed, and it's been validated over and over in the industry, that belonging relies heavily on structural design.

You have to engineer equal status from day one. Level the acquired people as peers with existing team members and structure their work so they're pairing with incumbents to solve problems together, not stuck on separate "acquired" team projects. Make a point to adopt some of their processes too, so you don't send the signal that your way is just automatically better, and most importantly, give them shared objectives with existing teams.

The legacy team does X while you do Y set up almost always backfires because it just reinforces the divide. And be very deliberate with incentives. If you're measuring the legacy team on system uptime while the acquired team [00:40:00] gets judged on feature velocity, or you're tracking separate revenue targets for each group, you've essentially just built silos into your system.

Those competing metrics discourage collaboration and encourage each side to optimize for their own success at the other's expense. At the end of the day, it's about designing conditions where belonging can happen naturally.

Eddie Flaisler: Absolutely. And speaking of organizational design, this is exactly where matrix models like the Spotify one shine because people keep rotating what they work on. You may have brought the acquired team in for their expertise on a specific thing, but that doesn't mean they should be the only ones touching it. You can use their expertise to teach, mentor and set up others for success so the whole team can work on the technology over time instead of it staying siloed.

Morgan VanDerLeest: And we've talked about the benefits of that, but just as a manager or leader within your company, it's not just the job to make sure that the software and the product works with the team that you have, it's that it continues to work regardless of the team that you have. It's this thing that's greater than any individual person.

So you can't let one or even a handful of people solely own the thing. 'cause at some point that is going [00:41:00] to change and it's gonna hurt.

Eddie Flaisler: Succession management, 100%.

Morgan VanDerLeest: Exactly. Now, speaking of expertise, this is probably a good segue to the expert archetype we mentioned earlier. Now that can be a real issue because the person you just brought in may have spent years building, maybe even from scratch. The very system that put their company on the map, their deep knowledge of that is their claim to fame, and that can help make them feel less willing to share knowledge or collaborate on initiatives that would change how that very system works.

Eddie Flaisler: It really is an issue, Morgan. And you know this podcast is called People Driven Development and one of the things I have to keep reminding myself. As someone who has experienced his share of mistreatment from ill-equipped managers over my many years in the industry is that while I do want everyone on my team to feel respected and seen, the people in people driven development is plural, not singular. It's not person driven development. We serve our team, not individual. The unfortunate truth when it comes to the expert persona is this, we should definitely try our [00:42:00] hardest to help them reinvent their identity as leaders in this new environment, to offer them interesting growth opportunities and give them lots of positive attention when they teach others and show flexibility. But ultimately, this is exactly why that Joel test style due diligence of the technology before merger is so important. You need to make sure you're acquiring a system where your ability to learn it and improve it doesn't depend on the goodwill of any specific individual. And I know people do today are like, oh, we have Claude. We'll just feed it the repo. But understanding a system end to end is a lot more than that. We must not underestimate the importance of getting a system where discovery and extensibility is reasonably straightforward because that's what unlocks our ability to tell expert personas once we've exhausted our attempts to make them collaborate, That with all due respect and there is a lot of respect. They need to get their act together or this is not gonna work. Managing inherited expert personas is definitely about a lot of reverence for what they bring [00:43:00] and doing everything you can to give them psychological safety and growth opportunities they deserve. But it's also our job to have a plan B.

Morgan VanDerLeest: It is a tricky situation to be in, but that Plan B is so significant. Now about the third piece you mentioned, supporting those who came into our org already burnt out. I feel this one is really nuanced because burnout can be induced by so many factors and manifest itself very differently. You can have someone who just finished working nights and weekends for the acquired company, so their mind and body are just worn out.

But you can also have someone whose energy and drive aren't depleted per se. It's just that everything that happened before and around the merger just really got them demotivated and disengaged, and those are two very different types of situations to handle.

Eddie Flaisler: Yeah. Well, I don't think supporting someone who joined to a merger acquisition and is burnt out is any different from helping an incumbent employee who is burnt out. That That said, people who come in via an M&A often face extra stressors, which is why I mentioned burnout as one of the three pieces for handling M&A teams transition. They [00:44:00] may have role uncertainty, like not knowing where they fit or what their exact responsibilities are, or what their new career path looks like. They may also experience what is referred to as cultural dislocation, where you know, suddenly there are different norms around meetings, feedback and decision making. And all of that just makes the day-to-day work feel hostile or alien. And of course as we touched on earlier, it can simply be that the terms of the deal for that specific individual left them feeling so undervalued that this trumps everything else. By the way, I know from very personal experience that a silent spirit killer in an M&A situation, or frankly any transition in life, is the weight and the lack of clarity as you wait people. Hate being in a limbo. It's draining. And because M&As can take so much time to complete, the team ends up sitting with that uncertainty for a very long time. That is why it's so important for a leadership team to find the right time to communicate changes like this. I'm not saying it's easy, the balance between saying something too early and then people just sit with it and [00:45:00] wait and are confused and worried 'cause you don't have all the answers yet. Or saying it too late and then people wonder if something is going on and why are you hiding things from them? It's not easy. There's no formula. All I can recommend is mindfulness about when and how changes like this are communicated.

Morgan VanDerLeest: Yeah, absolutely Eddie. And I see what you're saying. I agree that ultimately addressing burnout might look the same regardless of M&A, but it's definitely important to keep those specific stressors in mind. 'cause that helps us as managers focus on what's most helpful as opposed to just blindly following some playbook.

I really like Sharon Parker's SMART Work Design model. It's a very crisply defined framework for increasing engagement and reducing burnout. It isn't specific for M&A, but it's so comprehensive that I like to treat it as a pool of things to keep tabs on. And from that, I can decide what I focus on with a specific person or group of people, just depending on that situation.

So SMART stands for: stimulating work, mastery, which basically means clarity, useful feedback, and opportunities to develop competence and skill. [00:46:00] Autonomous, which means you have meaningful decision latitude about how, when and what to do. Relational, which is social support, task significance, and contact with beneficiaries of their work so people can see the impact of their work. And lastly, T tolerable demands basically reasonable workload, minimizing tasks that aren't clearly scoped or competing priorities and manageable work home boundaries.

So stimulating mastery, autonomous, relational, and tolerable demands.

Eddie Flaisler: I really like that. I like the fact it's so crisp that it's easy to keep in mind. And from that you pick and choose what's appropriate, like a toolkit.

Morgan VanDerLeest: I love a good toolkit. So Eddie, we're nearing the end of today's episode. Similar to how we flip sides when discussing inherited technology and move from what happens before to what happens after the deal is closed. Let's do the opposite here now. So we've talked a lot about what happens once the team is here.

Now let's talk about vetting the people that you're bringing in. I know some companies simply interview the employees of the organizations they acquire or merge with and make individual decisions as if they were hired externally.

What do you think about [00:47:00] that?

Eddie Flaisler: So I'm not particularly opinionated about interviewing versus trusting the judgment of the engineering organization you're acquiring. It really depends on the situation. Remember we mentioned M&As where the starting assumption is that the current leadership isn't very strong, but you could also be buying them precisely because they're a powerhouse. If the people are already there and the organization is performing well, there's a good case for assuming they probably should be there, but there can be exceptions. What I am opinionated about is how you vet these people, especially in a situation like this. You know what my motto is, right?

Morgan VanDerLeest: Eddie, you have too many mottos.

Eddie Flaisler: Sure, but one of them is, "it's a job, not a circus", and the idea behind it is simple. If I give you a problem to solve, I need to trust you'll get it done. I don't care how many Unix commands you can rattle out from memory, or if you're the first one to try this latest AR framework. What matters to me is that you thoughtfully choose the right tool for the job and that you keep yourself moving even when some Unix command doesn't behave the way you [00:48:00] expect. When I was at Uber, we ran an apprenticeship program for coding bootcamp graduates with no professional software experience. Because no experience was required, we ended up with an incredibly diverse group. Some were self-taught computer wizards with no work history, while others were former dancers and line cooks who had barely used the computer before the bootcamp. I'll give you one guess who not only survived, but thrived a year into the program.

Morgan VanDerLeest: The dancers and the line cooks.

Eddie Flaisler: Yes, and I know it sounds a little fairytale like Morgan, but this is exactly what happened. In hindsight, it's not surprising. The dancers and line cooks already understood the commitment and discipline needed to climb such a steep learning curve. Why does this matter for M&A? The point is not that you should acquire Wendy's. It's that when you acquire a company, you also buy its team dynamic, and that's a really valuable asset. It easily takes a year to get people who have never worked together to move smoothly as a unit. If you have the option to acquire a group that already knows how to work together from day one, do not dismiss it [00:49:00] because one candidate failed your random recursion question. Who even uses unbounded recursion in production these days?

Anyhow. The only thing that actually matters is whether those people can succeed in your engineering organization, with it's cultural norms, it's quality and security standards, and CI/CD philosophy. And the best indicator for that is whether they have done this or something equivalent to this before. Which you can vet with proper behavioral interviews that go deeper than "Tell me about a time you had a conflict." And if you really want to with an assignment where instead of freaking out about them using ChatGPT and banning outside help, you'll let them use whatever tools and people they need, but leave the non-functional requirements open-ended and see what they consider production ready Enterprise grade code. That is the kind of judgment no AI agent will give you for free. You have to be specific about what you're asking.

Morgan VanDerLeest: Those are some of my favorite questions in behavioral interviews are not necessarily the ones you already have in your question bank. But the follow ups and the why [00:50:00] and getting people to think, even if you were part of a project, you can talk through roughly what happened there, but if you really need to get a detail about why did we pick a specific technology, did it have something to do with the way the system was built, the way that leadership pushed it down, who knows?

I feel like behavioral interviews for ICs are really underappreciated in the industry.

Eddie Flaisler: Oh, absolutely. Again, this is like a full episode in and of itself, but the lack of standardization around interviews that are not purely technical is very problematic, and it has led to some pretty shocking stories. There have been several famous instances in the past year with people and even hostile organizations from non-English speaking countries, securing offers from tech companies using Deepfake to either get on the payroll or gain access to proprietary information of a certain company without actually doing the job. What I found most astonishing about these instances wasn't that these fake candidates pass the technical interviews, but that the VP of engineering who conducted a purely behavioral interview, described them as a quote, [00:51:00] great fit. This makes you wonder what is and isn't being asked.

Morgan VanDerLeest: I feel like we're getting into just horror territory. It's gonna be an interesting couple of years,

Eddie Flaisler: Totally.

Morgan VanDerLeest: But I think we can stop here. We covered a lot today. Thank you for the conversation, Eddie. I hope people found this as useful as I did.

Eddie Flaisler: Thank you Morgan. 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.

That's one word, peopledrivendevelopment@gmail.com, or you can find us on X/Twitter @PDDpod. Bye everyone.

Morgan VanDerLeest: See ya.

​