Managing Team Collaboration After an Acquisition
10 November, 2021
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
I was hired at HUMAN in 2021 to manage a team that went from hybrid to completely remote working environment because of COVID.
VP Software Engineering at human
Consideration for starting a multi year software infrastructure ( V2 ) project that involves hundreds of globally distributed engineers.
VP Software Engineering at human
This is a brief comparison and contrast of Google and Facebook, as a place for one’s software engineering career. Both can be amazingly good places for engineering careers. But both places can be misfits for otherwise excellent engineers. This is a short differential guide. [Originally on LinkedIn]
Chief Technology Officeer at GraphStax
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.
Google Cloud Practice lead at Contino
When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..
VP - Engineering at ITILITE Technologies