July 13, 2019
There was this one Monday afternoon when an exec at my organization pinged me on Slack asking to speak with me. There was a tool we planned to build and offer to our customers, and some guys had created a product that did almost exactly what we had in mind. We wanted to acquire their company, and I was tasked with the due diligence of the acquisition. I was supposed to assess the quality of their team and their product. We had a pre-approved number, and we had to figure out how much we would be willing to offer.
Being new in my role and overly excited about 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. So I started doing my homework, went on the Internet trying to figure out how to assess a company pre-acquisition. Best thing I did was to ask on the Engineering Manager group on Slack and pick the brain of more experienced managers that have been through the process.
The others helped me come up with a bunch of questions to guide my reasoning. The answers gave me a pretty clear picture of the situation and tremendously helped me reach a decision. I thought these questions could be useful to other people in the same position, so I’m sharing them here.
Why do we want to acquire this company? Is it because of their product, their people and expertise, or both?
Take the time to ponder on the reasons your organization is moving towards the acquisition. Are the goals of the merger clear to you? 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 part and vice-versa.
If the people decide not to come on board, do we want to maintain their software?
This question ended up being decisive for us. It’s not only about code quality, but also permanent technology (e.g., it requires a database the team can’t support) or infrastructure choices (e.g., it can only run on GCloud, the team only supports AWS), and the cost of migration would be prohibitive.
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 closely their software will integrate with yours, you might have different questions to this answer. Integrating the codebases might require such an effort that would make it prohibitive. Reasons can vary from lack of modularity to incompatible technology and architectural choices.
Is the maintainable enough for us to untangle it, get rid of cruft and improve on 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 modularity of the code and the amount of accumulated tech debt.
How would they rate their codebase health?
The state of their codebase is evidence of how well their organization prioritizes time. It also indicates the quality of the decisions they’ve made in the past. It’s expected an early-stage startup will have lots of accumulated tech debt. An established company shouldn’t have as much. This question is useful to gauge the maturity of their teams.
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 they decide not to come onboard? If not, you should factor in how long it’d take to train or hire people to work on it.
Are their people joining your team? Great! You should handle the people part as a ten (or twenty, or a hundred) people interview, all happening at the same time. Depending on the size of the company, the time or logistics of the acquisition won’t allow you to talk to everyone. You’ll need to ensure as much as possible the people you are hiring are technically sound and a good fit for the team. The main question you want to answer here is if the project never finds traction, would we want to keep the people?
How is domain expertise distributed among the team? What about technical skills?
This question is useful to gauge where the expertise lies, find out who are the senior developers, designers, and product managers that keep their machine oiled and running.
How is product direction currently decided?
Ask for details about their decision-making process for the product. Do they have a product management team? Ask about how they prioritize work and how long the current backlog is.
What about technical direction?
It’s useful to speak with their principal engineer/lead architect/most senior developer and ask about their decision-making process. If you have the chance, talk to an engineer or two and ask about their take on the architecture. Get their opinion on the current state of the tech stack, if it has scaled well to their user base, what are the current bottlenecks, and if there’s a concentration of technical debt somewhere.
How were the people on the team chosen? What does your interview process look like?
For a small company (5-10 people), this question isn’t very relevant. You’ll probably get answers like “So, Sarah and I met in college, Matt worked with Sarah before…“. For larger companies, you should be looking at how diverse their team is, and if their hiring process is open for bias. If the CEO sounds like a frat boy and their hiring is full of bias, the rest of the team won’t be very different.
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 the indispensables are.
What do the state of the product and the codebase say about decisions they’ve made in the past? How well do they optimize spending their time?
The state of the product and codebase says a lot about 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 correctly and spend time on high impact changes. Check if they 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: code in version control, frequent deploys, some system to track and prioritize their work. Ensure you are bringing into your team people that understand the importance of engineering practices.
Would they be comfortable in having us dictate product and technical direction of the project?
This depends on what your plans are for their team and product. If they’ll have to adopt your tech stack partially or entirely, or 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 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, this will be an enormous source of friction that will make both teams unhappy.
Are their people a good fit for my organization? If we eventually kill the project, would the other teams be glad to have them on board?
How good a fit for your organization are their people? Do they share the same cultural values, or is it at least close enough so everyone can work together in harmony? It’s essential to keep in mind the possibility that the project might be a flop and you’ll have to disassemble their team and reallocate the members. In that case, ensure you’re not bringing in people who will kill the morale of your current high performing teams.
So, I hope this article helps you with your due diligence. Unfortunately (or fortunately), in my case, both organizations decided the acquisition wasn’t the best solution for any of the parties. We shook hands and went our separate ways. I walked out glad I had this opportunity and happy about what I learned and the experience I gained during the process.