Acquisition Troubles: Learning from a Legacy System
24 September, 2021
null at A Startup
Last year we identified a capability gap in our skillset. To fix it, we started looking for a small startup whose demonstrated excellence in the field could help us cover the gap. I worked with a corporate development team on developing the M&A strategy and was an internal sponsor of the idea. It is always a risky situation, and it implies asking the company to do something big based on your assessment. But I stepped in and was excited to make it happen.
The decision we made, from the business perspective, proved to be sound and revenue-generating. But what happened post-acquisition was something I was not prepared for. A new group of people who were all experts -- unlike us -- walked in, and suddenly we were all mesmerized by what they could deliver to the point that we started neglecting the past work that brought us where we are today.
The startup we acquired was a small organization of eight to ten super talented people who were experts in the field. In the process of convincing them to join us, what we ended up doing was bashing our legacy system too much. When the new people came in, all they could hear was our criticism. We simply didn’t give enough credit to what we had done already, which created internal strife between us.
Our initial approach was that the new people would be our holy grail to solve everything for us. But the existing teams did all they could given the objective constraints. They felt unappreciated and were right to point out that they were the ones that got us this far. No one could argue that the reason we had customers for that product was because of them. But, somehow, we didn’t emphasize this enough.
We made the radical cut -- what we did was the past, now we will head toward the future. It was a clean separation. A clean break was not bad as such, but whoever was on the past side of that line felt uncomfortable or undervalued. It was an upsetting message sent to people responsible for our existing revenue. At the same time, all the praise was given to a group of people who hadn’t done anything yet. They were getting all the love without proving anything.
Part of the problem was inadequate terminology we were using from the very beginning: old vs. new or past vs. future. Instead, we should have talked of ourselves as the same team. We are one team that brings some new individuals to help us boost our efforts. It’s the same effort, the same product that is evolving to the next release. In hindsight, I wish I framed it as a partnership and synergy rather than conflicting old and new. I should have brought in and embedded the new people in the existing teams, and helped them appreciate what already existed, thus helping strengthen the cohesion. I made a mistake because I wanted to start fresh, which removed any appreciation for the legacy system.
- When you acquire a startup, dedicate enough resources to get the new team up to speed with what you have done well. If you don’t do that, the new people may feel like they are building the future and should do their own thing. Devote enough time to do demos, tech spikes, meetings and have new people dispersed across different teams if possible.
- Acquisitions are never easy. Technologies may differ, which could take some time to make into one, but people should become one much faster. The moment people start to feel like a part of the same team, you will reduce anxieties around whose work is more valuable or important. You don’t want these feelings to exist and impede the integration. You need to have a clear plan and messaging to address those feelings of discomfort and anxiety.
- While the existing people are excited about the new technology, you have to make sure they are excited about their new colleagues. Adequate vocabulary is a big part of the integration. Instead of using conflicting dichotomies of old vs. new, create a narrative about evolution, growth, opportunities, etc.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Technical Program Management at Apple Inc.
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), shares her experience launching a product with two newly acquired startups within six months.
Technical Program Management at Apple Inc.
Amar Rao, Senior Director Of Engineering at FanDuel, recalls his exposure of acquiring a legacy system where his team had little experience and was unsure how to create a clear map of functionalities.
Sr Director of Engineering at FanDuel
Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.
Divisional Vice President, Global Supply Chain Technology at Trimble Transportation
Neelima Annam, Sr Director Information Technology at Outmatch, shares how something as minor as collaboration tools can be a BIG issue during mergers and acquisitions.
Vice President, Engineering and Planning at AIM Specialty Health