Engineering’s role in Mergers & Acquisitions.

I managed the engineering team at Digg as we ran out of money, and were eventually acquired. It was an eye opening experience, and I learned a great deal about the reality and the optics of selling a company, particularly one with no money and a shrinking user base. Humbling was just the beginning.

Since then, I’ve had the opportunity to evaluate a number of companies from the other side of the Mergers and Acquisitions (M&A) table. Most of those discussions didn’t move forward, but a handful have, and every discussion was an education in engineering’s role in these messy processes. Acquisitions are filled with risk, with early discussions creating a great deal of anxiety for finance, legal, and people teams. Engineering has an interesting risk profile as well, needing to evaluate the potential product value and integration cost of a potential acquisition.

However, and unlike many other functions, engineering will be intimately involved after the acquisition closes, typically leading the integration and operation of the acquired offering. This incentivizes engineering to be particularly careful in their assessment. While there are no prizes for diligently vetting acquisitions, often just a trail of annoyed colleagues, it’s critical work. Thoughtfully integrating a trajectory-changing acquisition is one of the most impactful things you can do as an engineering executive, and stopping a poorly thought acquisition from moving forward is similarly guaranteed to have an understated but massive impact your company’s trajectory.

We will work through:

• The complex, often misaligned, incentives of acquiring another company
• The roles of your business strategy, acquisition thesis, and the engineering evaluation in an acquisition
• Topics you should cover in your engineering evaluation
• Integration decisions you should make while considering an acquisition
• Handling the flipside, being acquired

By the end, you’ll have a structure for running the overall M&A process and a template for conducting engineering’s portion of that process. Further, I hope you’ll agree with me that evaluating acquisitions is some of the most interesting work that engineering executives do, and that managing engineering’s “no” in the M&A process is uniquely impactful work.

Complex incentives

After one acquisition closed, I was responsible for integrating the team and product offering into our company. When the deal team stepped away–mission accomplished!–I quickly learned that the M&A deal team had handed off a bit of a mess for me. The engineers at the acquired company were told that they were being brought in to salvage our failing technology stack. Our engineers had been told that the acquired team knew they’d need to rewrite their stack into our standard stack, and that they were totally excited for it. This setup didn’t create the smoothest start to our integration process.

This kind of miscommunication, some might call it a mild deceit, happens all the time in acquisitions. An important underlying truth of mergers and acquisitions is that the incentives can get very warped. Your M&A team may be evaluated by their ability to complete a certain number of acquisitions that contribute a certain amount of revenue to the business. That goal would align them towards moving forward with almost any revenue contributing acquisition, even if it’s an exceptionally painful integration. You as an engineering executive might be very proud of your current technology stack and team culture, and consequently somewhat resistant to potential acquisition. Your company’s founders or CEO will skew heavily towards acquisition-loving or acquisition-hating, mostly based on their previous experiences, which complicates the process as well. Similarly, the other company’s founders or CEO will either be desperate for an acquisition or totally resistant to it, and sometimes both over the course of one day: it’s hard to give up a business you’ve built, even when it’s quickly running out of cash.

Finally, there’s the allure of the sunk cost fallacy after you’ve spent the better part of a year evaluating six or seven potential acquisitions without moving forward on any of them. At some point, the amount of effort the deal team has expended becomes hard to overlook, and you’ll start biasing towards moving forward even if the full math doesn’t check out.

Keeping these messy incentives in mind is fundamental to navigating acquisitions successfully.

Strategy, thesis, and evaluation

Every acquisition, much like every new company, has a hundred reasons why it won’t work. If you only look for reasons why an acquisition is a bad idea, you will always find quite a few. Conversely, if you only look at the potential good, every acquisition will look irrationally rosy. To navigate the tension between those two extremes, your company needs to develop three tools:

1. Business strategy: what is the desired role of M&A in your business?
2. Acquisition thesis: what are the assumptions that need to be true for this particular acquisition to fit into your business strategy?
3. Engineering evaluation: are you able to disprove any of those assumptions, or uncover other significant risks?

A surprising number of M&A processes skip the first two steps, but you can see why that makes the third step an awkward formality: how do you disprove the unstated assumptions driving the potential acquisition? Your best option in those cases is to write the missing strategy and thesis yourself. Evaluating an acquisition without each of these tools–strategy, thesis, and evaluation–will end in tears.

As an aside, if you want a detailed look into one company’s approach, Gitlab’s acquisition process is documented online, and is quite good.

Business strategy

From an M&A perspective, your business strategy needs to answer a number of question:

1. What are your business lines?
2. What are your revenue and cash-flow expectations for each business line?
3. How do you expect M&A to fit into that?
4. Are you pursuing acquihires (team only), product acquisitions (emphasis on product capabilities; less focus on revenue and distribution), or business acquisitions (entire business line with product, revenue, and distribution)?
5. What kinds and sizes of M&A would you consider?

Ideally your CEO or the combined executive team is writing this, rather than you writing it alone from the engineering perspective, but sometimes you’ll end up writing the first draft out of necessity. If you do find yourself attempting to write this document, just write anything reasonable and share it with the executive team. To a certain extent, the worse your first draft is, the more likely someone will get annoyed and take it over; in either case, this approach will almost always end with a coherent business strategy getting written.

The simplest business M&A strategy is building everything in-house and doing no acquisitions. Generally, I believe that should be the default strategy for most small companies, but the possibilities expand as your business grows. For example, common strategies include:

• Acquire revenue or users for your core business. For example, Match Group’s acquisition of Hinge

• Enter new business lines via acquisition. For example, Stripe acquired Index to power point-of-sale devices

• Drive innovation by acquiring startups in similar spaces. For example, Facebook’s acquisition of Instagram

• Finally, you will absolutely never see this in writing, because no one wants to show up in court documents, but many acquisitions are motivated by reducing future competition, such as Google’s acquisition 2013 of Waze, which prevented potential future competition on mapping.

  It can be difficult to figure out when the strategy is really about reducing competition, because folks will resist writing that down. If you simply cannot figure out what the real M&A strategy is, maybe it’s about reducing competition

Essentially any strategy is reasonable as long as it gets written down, and the executive team is aligned around it. Conversely, if it’s not written down or the executive team isn’t aligned, it’s very difficult to move forward to the next step: applying that business strategy to a particular acquisition.

Acquisition thesis

Your business strategy is how you’re generally thinking about acquisitions. Your acquisition thesis is how you specifically think about one particular acquisition. Every acquisition you consider should have a clear, documented thesis, which should answer one complex question: what, specifically, needs to be true for this acquisition to fit into our business strategy?

Your answer needs to cover product capabilities, intellectual property, their book of business, revenue, cash flow, whether it’s a business acquisition (purchasing the entire business for revenue and product), product acquisition (purchasing for product, generally to increase your existing revenue through your existing distribution), or team acquihire (purchasing for the team members themselves), and every other aspect. The goal is to identify the assumptions that need to be true for the acquisition to be worthwhile.

This thesis will greatly shape how you value a given acquisition. Consider how differently you’d evaluate these two scenarios for a potential acquisition:

• You run a code hosting business. A competitor is capturing market share with their integrated CI/CD offering. You’re building a competing CI/CD, but are 18 months away from delivering it. You decide to evaluate acquiring a startup with CI/CD offerings. The product works, but you’re skeptical of their ability to scale long-term
• Same scenario, but you haven’t started building an offering, and think it would take 36 months to take to market

In the first scenario, the advantage is exclusively in time-to-market. You’d be evaluating reducing revenue impact from the competitive threat until you delivered your internal offering. You don’t even need to worry too much about the product’s quality: it doesn’t need to scale forever, just for 18 months. In the second scenario, the thesis’ validity depends on a product that can scale without replacement. This means you’ll want to dig much deeper into the implementation, infrastructure, and underlying costs.

Documenting your acquisition thesis is extremely valuable. It serves as an input to the next stage, the engineering evaluation, and prevents significant misalignment among the deal team. The messy incentives often lead to scenarios where part of the team views the acquisition as an interim solution, and another part is valuing it as a permanent business or product pillar. It’s exceptionally hard to come to the same conclusion when reasoning about value from different perspectives.

As you articulate the acquisition’s value, you also have to think about valuation. One challenge here is identifying an appropriate valuation without getting caught up in the valuations driven by venture capital during booms. Venture’s risk model allows it to miss nine times as long as it gets the tenth one right, but as an acquiring company you can’t simply write down an acquisition, you’re also on the hook for the costly integration necessary for it to have a chance to succeed.

Engineering evaluation

Once you have an acquisition thesis that identifies the necessary assumptions to justify your acquisition, the next step is the deal team splitting off to validate those assumptions. Your finance team will focus on revenue forecasts, your legal team on intellectual property, and within engineering you’ll need to focus on validating assumptions around implementation complexity, integration plan, scalability, security, compliance, engineering costs, and engineering culture.

The general approach here is:

1. Create a default template of topics and questions to cover in every acquisition

2. For each acquisition, fork that template and add specific questions necessary to validate this specific acquisition’s thesis

3. For each question or topic, ask the engineering contact for supporting materials that you can review before meeting, such as a SOC2 certification, API documentation, current team structure, and so on. They likely won’t give you everything you ask for, but whatever they do give you will allow you to narrow your focus

4. After reviewing those materials, schedule a one to two hour engineering discussion with their engineering contact, with the aim of either addressing or scheduling a follow up for all yet-to-be-validated assumptions.

   You will have limited opportunities to meet with the other team, so cram as much as possible into each of these meetings. Don’t assume you’ll have six meetings, plan for having two

5. Run the follow up actions, validating or invalidating assumptions along the way

6. Sync with deal team on whether it makes sense to move forward

7. Potentially interview a few select members of the company to be acquired. Very common if it’s an acquihire, relatively less common if it’s a business acquisition.

   I mostly recommend this for individuals who you expect to fill a senior role in the combined organization. This is to protect them as much as it is to protect you as the acquirer: you don’t want to put yourself or the new leader in the position where you tell their new direct reports that you never interviewed them! Outside of an acquihire, I don’t recommend interviewing most of the folks, it’s time consuming and a worse signal than reviewing their existing work

There will be some other steps that involve engineering, but they generally skew towards the superficial. For example, most acquisition processes will include a product demo, but for whatever reason these demos are almost always painfully generic, and you can learn more by using it for a few minutes (which I highly recommend doing). Certainly go along with the steps to be polite, but don’t expect the default steps to be very informative.

Throughout this process, you’ll have to decide how many people to involve from within the engineering team. This depends on the size of your team, the size of the company being evaluated and so on, but generally you want to involve as few people as possible. Acquisition discussions are, inevitably, very distracting and rarely end in an actual acquisition, so involving more folks is usually painful without much of a return. However, sometimes there are areas where you simply don’t have enough detail to evaluate the company effectively, and that’s where it pays to pull a few more people in (especially when it comes to compliance and security questions).

Recommended engineering evaluation topics

Many of the questions you want to answer about a given acquisition target will tie into your acquisition thesis, but often the acquisition thesis will miss obvious sources of risk. Sure, JPMorgan made sure to model out the potential value of Frank’s acquired data, but they didn’t verify that data came from a real production database. To avoid missing the obvious, you should create a base evaluation template, and run each particular evaluation from a forked copy of that templated with acquisition thesis-specific topics added on top.

Topics I would recommend including in your base template are:

• Product implementation: particularly, you want to verify that the implementation is real, and that it is a first-party implementation rather than powered by a third party capability. For example, Open AI has spawned a flurry of AI-driven startups whose implementation is primarily calling OpenAI’s APIs, rather than intellectual property held by the startups themselves.

  It’s particularly valuable to have an engineer, potentially you, read the actual source code of the to-be-acquired company. So companies will be very reluctant to share their source code itself, but will be open to an engineer showing the code over a video call. Even reluctant companies will rarely block an acquisition from moving forward solely by refusing to share some amount of their code

• Intellectual property: similar to the above point on product implementation, while your legal team will generally dig into any patent portfolio, on the engineering side you should dig in to uncover if intellectual property valued in the acquisition actually exists.

  Once again, reading the actual source code is particularly valuable

• Security: who’s responsible for security at the company, and what are they doing? Are they doing routine penetration tests, and where are their latest results? Are they doing periodic security training for their employees, and what do they cover? Do they know of any breaches? If they were breached, how would they know?

  It can be difficult to get answers to these questions in many early stage startups, but any sizable company should have a team who can answer these questions directly. If they don’t, and they have highly valuable data (health data, financial data, etc), then you should keep in mind that they may have already been breached and simply not know it

• Compliance: what compliance certifications does the company have? SOC2 type 2? HITRUST? Nothing? To the extent that they claim a given certification, have they kept up with the audits? What did their last audit report show?

  It’s common for companies to say they have some certification, say SOC2 type 2, but to have no audited reports to share from the past two to three years, which merits investigation. Particularly within a small deal team, you might be the only person with context on compliance, and it can cause a great deal of pain if not caught until after completion (or at minimum can be a factor in changing the relative valuations of the two companies if caught early)

• Integration mismatches: what are the vendors, particularly their primary cloud vendor (AWS, GCP, Azure, on prem, etc), and core technology stack (programming languages, storage tiers, and any vendors used in their production stack)? You are looking for the extent of the overlap, such that you can answer whether integrating their stack with yours will be relatively painful (best case) or nearly impossible (worst case).

  Particularly look for multi-year contracts that might inhibit rapid consolidation, or at least increase the costs of doing so

• Costs & scalability: to the extent that you plan to continue running the current stack, how scalable and operable is it? How much does it cost to run relative to each dollar it generates? It’s possible to separate costs and scalability, but they tend to be most interesting when evaluated together.

  Ideally, you want to see a spreadsheet of all engineering costs over time, along with revenue and a key user engagement metric. This will make it clear whether there are economies or dysfunctions of scale, which will help you understand the product’s long-term revenue and cash-flow contributions. If this spreadsheet doesn’t already exist, you should be able to sit down with the finance team working on the deal to estimate what these numbers look like

• Engineering culture: the acquired company’s engineers will become your team mates, and you’ll want to understand how it will feel to work together. How does the company make technology decisions? How do they structure teams? Does the engineering contact mention other people, or primarily speak of themselves as the decision maker? There’s no right or wrong here, but you do want to understand how they’re operating model differs from yours, and whether you’re willing to deal with that friction

Whatever list of topics you start with, keep extending it after each acquisition evaluation. Over time this will become a source of significant value to your company. Keep in mind, you can indeed go a bit too far in these investigations: at one point I was silently dropped from Stripe’s acquisition process for asking a few too many questions.

Integration decisions

As you work through the evaluation process, you’ll also need to develop a point of view on a number of integration choices. These choices are focused on identifying the most successful approach to integrating the acquired team, product, or business into your existing business and function. The three most important questions to work through are how will you integrate the technology, teams, and leadership.

Because there are so many factors involved in integrating a real business into another real business, my general advice on your concrete integration plan is to take this tact:

• Commit to running the acquired stack “as is” for the first six months. Let the acquired company know that you will aim to consolidate technologies wherever feasible
• Bring the acquired engineering team over, with their head of engineering reporting into your head of engineering (or the appropriate business unit’s engineering lead if they are a small acquisition contained within a single business unit). Let the acquired engineering leader know that you will aim to combine vertical teams (developer productivity, infrastructure, and so on) as feasible
• Be direct and transparent with any senior leaders about roles where they could step in, and how you would make that decision to maximize their success along with the existing team’s. Even if someone is deeply qualified, you’ll set them up for success better by letting folks get to know them a bit before inserting them as a new boss

The reason I prefer this above plan is that any other details you decide upon will almost certainly be specifically wrong, and will be remade along the way.

However, even if you use an loose plan like the one above, you’ll learn a tremendous amount about the opportunity and opportunity cost by planning a few steps deeper into how acquired company would integrated into yours, and I highly recommend pushing on the ideas until you identify the biggest risks.

With that in mind, I’ll talk through how I generally think about these decsisoins, starting on technology. The details of technical integration will depend on the value you hope to create. The two extremes are a full rewrite on one end, and running in full separation on the other. Many of Google’s smaller acquisitions lead to full rewrites, such as the Metaweb acquisition in 2010, which spent years reimplementing their working technology into the Google stack. On the other hand, Google’s largest acquisitions like Waze or Youtube ran, at least initially, on their own stacks, and facilitated integrations through APIs.

Your technical integration should be guided by your engineering strategy. In the strategies that I’ve operated in, we knew we would always eventually converge on a single cloud environment (e.g. AWS vs Google Cloud), and generally tried to converge tech stacks as early as possibe. Even in cases where it was technically feasible to operate separate stacks, you’ll end up with two distinct engineering sub-cultures, with different modes of technical decision making. Most companies won’t tolerate multiple sub-cultures until the company grows quite large (e.g. 1,000+ engineers) and work on very different problem spaces. After that point, they usually are initially tolerant, for example, Uber’s Autonomous Technologies Group ran separate stacks successfully for a period of time, given they focused on significantly different problems than the company’s core product.

The second integration question to dig into is structuring teams. This will depend heavily on the relative size of the two companies, but generally you’ll either have the acquired company’s head of engineering reporting into you or into the engineering lead for the business unit they’re joining. You may also wish to separate infrastructure, data, or security teams to report into your existing, centralized teams. None of these approaches are obviously right, it will depend heavily on the details and experience of the leaders involved.

Deciding what to do with the acquired company’s leadership is always tricky. Often you’ll find that the engineering leader at an acquired company has been struggling in their role, or struggles to imagine themselves reporting to someone else running engineering. The opposite happens too, with excellent leaders who are energized by partnering well with you, who are glad to teach you, and would have been difficult for you to hire directly. Most importantly, think about balancing doing the right thing for the acquired company with doing the right thing for your existing team. Success depends on both groups working together effectively, and it’s easy to dig a deep hole if your existing team feels the acquired team is underqualified for their new roles.

Once you’ve figured out these, document them and validate them with your deal team. Until you socialize your plan, it’s likely that entirely different plans have been communicated, and this will allow you to pull folks onto the best plan to move forward post-acquisition.

Dissent now or forever hold your peace

When you consider only what could go right, acquisitions are irresistable. Some of the industry’s defining products blossomed through acquisition, like Meta’s acquisition of Instagram and WhatsApp, or Google’s acquisition of Waze. There’s also Match Group’s dating rollup strategy, acquiring Tinder, Hinge, and many others. Acquisitions can be transformative.

However, even ignoring opportunity cost, most acquisitions don’t deliver on their intended impact. Think of Google’s acquisition of Motorola, eBay’s of Skype, or Amazon’s of Goodreads. Further, the engineering team will absorb most of those opportunity costs, and it’s your responsibility as an engineering executive to inject realism into the process.

Sometimes this is pretty difficult, and won’t make you friends. My best advice is to anchor your feedback in the company’s goals, rather than engineering’s, and to make sure your concerns truly are from the company perspective. Ignoring the philosophical question of whether it’s fair, engineering will incur much of any acquisition’s operating cost and complexity, and owes the company (and itself) a strong, clear point of view.

Engineering will often have one vote out of many, rather than an outright veto over the acquisition, and the wider group won’t always agree with you. Sometimes, being an executive is doing something painful for your function that may be impactful for the broader business. I will say, that I’ve rarely regretted being overruled on these things, usually I was missing an important consideration, and these things have a surprising way of working out for the best, even when it seems like they shouldn’t.

Being acquired

I want to end with a few words on the inverse challenge: getting acquired by another company. There’s a lot to be said about how to get acquired, which I think Touraj Parang’s Exit Path covers nicely, so I’ll focus on navigating the process from an engineering perspective.

The key thing to understand is how the acquirer views the acquisition. Do they view it as a business acquisition, product acquisition, or an acquihire? If it’s a business acquisition, then changes are likely to happen slowly. If you talk to folks at Slack post Salesforce acquisition or LinkedIn post Microsoft acquisition, changes have definitely happened, but for most people their lives didn’t change much overnight.

In the other two cases, things are likely to change very quickly. An acquihire is essentially starting a brand new job where you already know a few folks. A product acquisition will start with an integration to prove out the acquisition thesis, often followed by reworking the implementation to follow the acquiring company’s standard development process.

The best thing you can do for the team is fight for their compensation packages before the acquisition finalizes, and then push them to acclimatize to the new world. Fighting the new world will only cause chaos, but won’t accomplish anything valuable. There’s no question that the changes will happen either way, but they have an opportunity to be perceived either as a collaborative member of the team or someone anchored in the past.

Finally, you have to decide for yourself if it makes sense to move forward. Even if you have an equity acceleration trigger in your contract, you may find yourself personally obligated to move forward with the acquisition. This usually happens when you’re identified as a key person in the negotiation, who must move forward for the acquisition to complete. If that happens, I’d encourage you to look for the opportunity for you in the acquisition. Acquisitions often accelerate careers and open up unique roles that wouldn’t be available to you otherwise. For every horror story about a bad acquisition, you’ll find another, quieter story about a transformed career.