Managing Team Collaboration After an Acquisition

Dealing With a Competitive and Unilateral Team

A much bigger company acquired one of the previous companies I worked at. After the acquisition, we started working with the other company’s engineering team on a few projects. At one of the projects, I had to collaborate with the other engineering team to build a data pipeline that would give us accurate data analytics to integrate into our products. As we were talking about the requirements, to begin with, the manager of the other team seemed very confident about how they could deliver and how they are familiar with everything built in the past.

“Oh, we’ve done that many times before. Trust us, we can get it done without a problem,” were their words. That made us happy, and we were getting positive status updates throughout our weekly sync meetings. By the time they were done with their part and handed it to us, we looked at the code and the actual results. It turned out that we could get the right results, but the performance of the system they built would be 10x slower. Of course, that was not the performance we were expecting because it would cause a bad user experience.

Upon discussing the not-so-great performance of the system with the other team, the answer we got was, “this is how we’ve always been doing things, and it wasn’t discussed how fast the system should be.” There were two kinds of mismatch: In my previous company, building a system meant serving the right results as fast as possible. It was all a part of the engineering culture, and we did not need to specify. Apparently, the acquiring company did not follow any such culture. As a manager, I did not do a great job in diving into the details. For example, during the weekly sync, I only looked at the high-level tracker and progress.

Approaching Cultural Change

My team started specifying and looking into the code as to how they could address performance issues. Ultimately, the project was delayed by two months, and the team learned a very valuable lesson, including myself. Now, even if I am working with the usual group that I work with, I still extend the trust but also verify in detail that they are on track. This is to ensure that history doesn’t repeat itself.

We were working on a pretty tight timeline, which meant meeting a deadline for a significant product launch. It had the potential to lift the company’s revenue by 10 percent. Because the product feature is sensitive to the freshness of the data, new data comes in all the time, but if it were delayed, it wouldn’t create much value. The 2-month delay almost cost us some very valuable and trusted customers.

Drive Execution

• Trust your partner teams, but do not overtrust them or blindly rely on them. Also, do not make any assumptions off the bat. It’s always a good idea to brainstorm and collaborate with the partner teams to layout any needed details. Ideally, all the details are measurable.
• I would make a two-pronged approach when working with teams. Before we get our hands dirty, the leadership of both teams should set up the right expectations in as many details and measurable metrics and outcomes as possible to set expectations. When the teams start executing, the leadership should use a set of measurable metrics to monitor the progress and problems.