How to Handle Team Collaboration After a Merger?
23 November, 2021
Pitfalls of Merging with a Large Company
Over my career, I have been through quite a few acquisitions, and one of the recent ones I did was a pretty good sized company 一 about 200 employees. They were building a SaaS-based product, which was a purely sales-driven product and development; meaning that the customers dictate what the product is all about for the most part. There were about 50 developers working on it with 8 product resources, but with that, they had not done agile, or any of the traditional market exercises. While the engineering teams were constantly having to pivot from one initiative to another without a work stream around it, the difficulty there was the company was starving for some stability. They did not have any need from a financial standpoint, but from a day-to-day perspective, things were pretty hectic and chaotic.
Supporting Employees During Acquisition
Now the challenging part was having them trust the system, without having them use it before. Bringing in some tools to help them establish some regular cadence was important. There was a lot of hesitancy and skepticism around that. The only way we were going to be successful was by coming in, and letting them be upset with the process. Giving them the space that they were going to have to learn something new, or be given feedback that could be taken as personal feedback was an important first step. We had an agile coach, a scrum master and many other individuals familiar with that.
Moving on, the next step was to make sure that each of us were present with one of the developer teams as well as the product team. As with most acquisitions, a team comes in and integrates the new company with the current organization. We wanted to be with them on a day-to-day basis. We had to live and breathe with the new team and be embedded with them to understand them better.
Over time, we found the engineering teams to really enjoy the process. However, the struggle came up to convincing the product side to get out of the day-to-day product management and start looking at forward-thinking plans. Furthermore, breaking down the initiatives that we need to accomplish for the organization, but doing it in such a way that it has more vision into the future than just two months from now.
The bigger part of that was educating the development teams as to why they needed such features. Helping the developers understand the context behind the marketing or business needs was crucial. Plus, since the organization was sales-driven, they had built a lot of commercial debt, which were the promises that they made to customers over time through the sales process.
All that commercial debt had built up so much that it was difficult to try and create new products that would satisfy the market because we had customers getting in the way of that. They went through some difficult conversations with the customers because of the new approach that they were making to the product. “We know we committed to certain parts of the product, but it no longer fits into the vision of it,” were all that they said to the customers.
In some cases, there were concessions made from a billing standpoint, and some customers walked away, but we knew the business we’d bring in. The changing of direction was greater than what those customers were providing us. In other cases, some customers were grateful for us bringing those products and appreciated the structure behind them. Knowing that it was not going to be a random selection in the sense of direction and features, it brought in assurity.
- Bringing in new talents into the organization takes a longer time to get things to fall into place. You need to leave a lot of space for people to celebrate the small wins. It’s a difficult phase for people, and you really need to leave them alone.
- Make sure to back and justify the progress made through the process. Especially during acquisitions, rather than dictating people on what needs to be done, or how things are done in the organization, give them the space and look back at how much they were able to complete.
- Build strong relationships, and a context to some of the conversations. Take the time and sit down to participate, instead of educating others.
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.
Senior EPM/TPM at Apple Inc.
Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.
Head of Software Quality Assurance at FICO
Henning Muszynski, Head of Frontend at Doist, promotes his ideas on how documentation ensures consistency, efficiency, and standardization.
Head of Frontend at Doist
Henning Muszynski, Head of Frontend at Doist, talks about the cost of slow and arduous processes that add up over time and how to bring the changes systematically.
Head of Frontend at Doist
Christophe Broult, Director of Test Engineering at diconium, focuses on how he scaled his team while building organization and management teams in place.
Director Test Engineering at diconium
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.