On a Monday afternoon, a VP in my organization sent me a message on Slack. We wanted to acquire another company, and he wanted my help with the technical due diligence.
There was this tool we wanted to build and offer to our customers. Some guys created a product that was almost exactly what we wanted to make, and we were in talks with them about possible acquisition. My job was to assess the technical quality of their team and product. We had a pre-approved number, and we had to figure out if we should make an offer and how much it should be.
Being new in my role and overly excited with the opportunity, I obviously said yes, of course, I'll do it. A minute later, panic took over. I was in way over my head. I didn't have much more than a vague idea about what I had to do. I thought I should start doing my homework.
I headed to the Engineering Managers Slack group, described the situation and asked if someone had any thoughts or tips. I wanted to pick the brain of more experienced managers that had been through the process before.
Side note: If you're managing engineers and not in this group, you don't know what you're missing. To me, it feels like having a cheat code for management.
The other managers helped me come up with a bunch of questions to guide my reasoning. My answers to those questions gave me a clear picture of the situation and helped me reach a decision. I think other people in the same position could benefit from these questions, so I’m sharing them here.
The most important question
Why do we want to acquire this company? Is it because of their product, their people and expertise, or both?
Is your company interested in buying their product to repurpose or further develop it? Or is it the goal to bring their people and expertise on board (a.k.a. acquihire their talent)?
Take the time to ponder on the reasons your organization is moving towards the acquisition. This reflection sets the direction of all the work that follows. If you don't care that much about the product, you'll focus more on the people or vice-versa.
In my case, it would ideally be both. Our first goal was to acquire the product. If possible, we also wanted to bring the team onboard to maintain the codebase and add new features according to our needs.
Product-related questions
These questions help gauge the quality of their product from an engineering perspective and the feasibility of an integration, should one be needed.
If their team doesn't come on board, do we want to maintain their software?
You want to make sure their codebase is in good shape, but you also want to find out about choices that may be costly to change. An example would be, their product uses AWS’s DynamoDB, while your infrastructure is all on GCloud. Is it worth adding a new cloud provider and technology to the list of things your team supports? Would migrating the code to Firebase make financial sense?
Is it feasible (or wise) to integrate their software with ours? How much effort is required to have a first working version with the features we need?
Depending on how tightly their software will integrate with yours, the integration effort could be prohibitive. Reasons can vary from lack of modularity to incompatible technology and architectural choices.
Is the code maintainable enough for us to untangle it, get rid of cruft, and improve what we need?
You'll probably be acquiring a codebase that isn't exactly what you need, so the team (yours or theirs) will have to dig in the codebase, remove any cruft and add new features. In that case, you should look into the code's modularity and the amount of accumulated technical debt.
How would you rate their codebase health?
The state of their codebase is evidence of how well a team prioritizes their time. It also indicates the quality of the decisions they've made in the past. While it's expected that an early-stage startup has lots of accumulated tech debt, an established company shouldn't have as much.
If we were to maintain the code ourselves, what skillsets would we need?
Does your team have the required skills to keep their software running if their team doesn't come on board? If not, you should factor in how long it would take to train or hire people to work on it.
People-related questions
Are their people joining your team? Great! You should handle the team part as a ten (or twenty, or a hundred) people interview. You have to ensure the people you are hiring are technically sound and a good fit for your organization. However, depending on the company's size, the acquisition logistics won't allow you to talk to everyone. Use the following questions to make the best of the time you have available.
How is domain expertise distributed among the team? What about technical skills?
This question is useful to gauge where their team's expertise lies. Find out who are the developers, designers, and product managers that keep their machine oiled and running.
How is product direction currently decided?
Ask for details about their product decision-making process. Do they have a product management team? Ask about how they prioritize work and how long the current backlog is.
What about the technical direction?
It's useful to speak with their principal engineer, lead architect, or most senior developer and ask about their decision-making process. If you have the chance, talk to a couple of engineers and ask about their take on the architecture. Get their opinion on the current state of the codebase. Ask them if their architecture has scaled well to their user base, what are the current bottlenecks, and if there's a concentration of technical debt somewhere.
How did they choose their people? What does their interview process look like?
Small companies will usually hire from their founders and employees' networks. Larger companies should have a more reliable process in place. Look at how diverse their team is – diversity is a good proxy measure of quality for a hiring process. A consistent and unbiased selection method tends to produce higher quality hires.
Is everyone on the team currently indispensable? If they had to let everyone go and later had the opportunity to rehire some of them, who would they rehire?
If your boss is willing to rehire you, it says a lot about how important you are to them and the organization. Their answer is an opportunity to find out who are the top performers.
What do the state of the product and the codebase say about their decisions in the past? How well do they optimize spending their time?
The state of the product and codebase says a lot about the decisions they've made in the past. It also shows how well-staffed is their team, i.e., were they threading water, or had they enough slack to pay for technical debt?
Make sure they prioritize their tasks correctly and spend time on high impact changes. Check if they usually use the right tool for the job, or if they tend to cargo-cult (e.g., using a NoSQL database for relational data).
What does the development process look like? Is it a mature process?
This, again, depends on how large the company is. There's no need for a complex development process in a small, scrappy startup. Nonetheless, you want to make sure they have their basics covered: version control, code reviews, frequent deploys, some system to track and prioritize their work. Ensure the people you're hiring understand the importance of engineering practices.
Would they be comfortable having us dictate the product and technical direction of the project?
This depends on what your plans are for their team and product. If they'll have to use your tech stack (partially or entirely), adopt your development process, or have your product team dictate priorities, make that clear and ensure they are comfortable with it.
What are their team dynamics? How are they compatible with ours?
You probably won't ask this question directly, but, at this point, you'll be able to answer it based on their answers to your previous questions. Having compatible dynamics is highly relevant to the success of the merger. You want to have people that are at least flexible enough to adapt. Otherwise, the friction will make both teams unhappy.
If we eventually kill the project, would my team be happy to have their people on board?
How good a fit for your organization are their people? Do they share similar cultural values, and everyone can work together in harmony? Keep in mind the project could be a flop, and you'll have to disassemble their team and relocate them. Ensure you're not bringing in people who would kill the morale of your high performing teams.
--
I hope this article helps you with your due diligence. Unfortunately (or fortunately?), in my case, both organizations decided the acquisition wasn't right for any of the parties. We shook hands and went our separate ways. I walked out feeling glad for the experience and happy about what I learned in the process.
Have you found this useful, or do you have anything to add? Let me know by emailing me at andre@dre.is.