The simple version
When a tech company pays $100 million to acquire a startup, a surprising portion of that value can walk out the door if the founders or key engineers quit. The asset on paper and the asset in practice are not the same thing.
Why software is different from other assets
Buy a factory and the machines stay. Buy a patent and the document stays. Buy a software company and you own the code, the contracts, and the brand, but what you actually paid for was the judgment, context, and institutional memory inside specific people’s heads.
This is not a soft claim. It has hard financial consequences.
Consider what a high-value software product actually consists of. There is the code itself, which is usually readable by any competent engineer. Then there is everything that explains why the code is the way it is: the architectural decisions that seem arbitrary until someone explains the customer constraint that forced them, the known failure modes documented nowhere, the workarounds for vendor bugs that were never written down because the person who wrote them assumed they would always be there to explain them. That second category does not transfer in an acquisition. It lives in people.
This is sometimes called the “bus factor” inside engineering teams, a morbid shorthand for the question: how many people would need to be hit by a bus before this system becomes unmaintainable? Many acquired startups have a bus factor of two or three. Acquirers rarely measure it before signing.
The retention problem that contracts cannot fully solve
Acquirers know this risk exists. Standard deal structure tries to address it through retention packages, typically requiring founders and key engineers to stay for one to four years post-close or forfeit a portion of their acquisition payout. This is called an “earnout” or, more specifically when it applies to individuals, a retention vest.
The math behind these packages looks reasonable. If a $100 million deal includes $40 million in retention equity spread over three years, the logic is that the engineers are financially incentivized to stay and transfer knowledge before they leave.
The problem is that money solves the wrong part of the problem.
Retention packages keep people physically present. They do not ensure those people are engaged, communicative, or invested in the acquiring company’s success. Engineers who feel their product is being mismanaged, their technical decisions overruled, or their team dismantled by corporate restructuring will often stay until their shares vest and then leave the moment the cliff passes, regardless of what they were paid. The knowledge transfer that was supposed to happen over three years sometimes happens over three months and then stops.
Google’s 2014 acquisition of DeepMind included substantial retention arrangements. Many of the original team members did stay, and that investment paid off. But for every DeepMind, there are acquisitions where founders collected their retention packages while mentally checking out well before the formal departure date. The acquiring company got compliant attendance, not genuine collaboration.
What actually depreciates when engineers leave
Think about this in concrete terms. A two-person startup has spent three years building a real-time data pipeline that several enterprise clients depend on. The founding engineers did not document everything, partly because documentation takes time and partly because, when you build something yourself, it never occurs to you that someone else will need to understand it without you.
The acquirer sends in their own engineers to get familiar with the codebase. Those engineers read the code, but reading code tells you what a system does, not why it does it that way. Questions come up. Why does the ingestion layer have a 900-millisecond artificial delay? (Because one of the clients had a legacy system that crashed on faster inputs, and the delay was added as a temporary fix four years ago and never removed.) Why does the authentication module call the database twice on every login? (Because there was a race condition discovered in production that this ugly fix resolved.) Without the founders available and willing to explain, those questions either go unanswered or get answered wrong, and the new engineering team starts making changes that introduce bugs the original team had already learned not to make.
This is not hypothetical. It is the normal failure mode of software acquisitions where key personnel leave quickly. The codebase becomes increasingly fragile as the new team makes confident changes based on incomplete understanding, and within 12 to 18 months the acquirer is often looking at a partial or complete rewrite. The asset they paid nine figures for is now a liability requiring nine figures more to fix.
The structural reasons this keeps happening
If this risk is well understood, why do acquirers keep underpricing it?
Part of the answer is that due diligence is built around things that can be measured: revenue, contracts, code quality audits, intellectual property filings. The knowledge distribution inside a team is harder to assess in a six-week due diligence window. You can interview the founders. You cannot easily interview the codebase.
Part of it is optimism bias. Acquiring teams tend to believe that their culture and resources will retain talent where others have failed. Sometimes they are right. Often they are not, because the founders of a startup did not build a product to eventually work inside a large corporation, and no amount of generous compensation fully compensates for the loss of autonomy, speed, and creative control that comes with being absorbed into one.
The deepest structural problem is incentive misalignment at the deal level. The bankers, lawyers, and executives who negotiate acquisitions are compensated when deals close, not on whether the acquired team stays and the product succeeds. The people who will live with the consequences of a failed knowledge transfer are the engineers who were not in the room.
What the number on the press release actually represents
When a $100 million acquisition is announced, that number represents what the acquirer believed the startup was worth at a specific moment in time, with specific people attached to it. It is not a fixed value that persists regardless of what happens next.
The more useful frame is to think of the acquisition price as a bet. The acquirer is betting that the product, the customer relationships, and the team knowledge can be successfully integrated before the knowledge starts degrading. The retention package is an attempt to extend the time horizon of that bet.
Companies that consistently get this right, and there are some, tend to do a few things differently. They treat the acquired team as a separate unit with its own leadership rather than immediately folding them into existing org charts. They document aggressively in the first 90 days, not by having the founders write documents, but by having acquirer engineers pair with them on real work and write down what they learn. And they accept that some acquisitions are priced around a specific person’s vision, which means if that person leaves, the honest accounting is that a portion of the acquisition price left with them.
That last point is the one acquirers rarely say out loud. But it is the one that matters most.
