How to Handle Team Collaboration After a Merger?
23 November, 2021
null null
null at Trimble Transportation
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.
Lessons learned
- 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.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
6 February
Internal Hackathons invite team spirit and collaboration which are critical whether an engineering org is co-located or operating remotely spread across 20 times zones. Hackathons give employees the opportunity to connect and network while they solve fun & relevant challenges.

Balki Kodarapu
Senior Director of Engineering at SupportLogic
21 December
Consideration for starting a multi year software infrastructure ( V2 ) project that involves hundreds of globally distributed engineers.

Ahsan Habib
VP Software Engineering at human
5 December
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Jaroslav Pantsjoha
Google Cloud Practice lead at Contino
25 October
Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Mrunal Kapade
Director of Engineering at Inspire Energy
26 June
Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart