An Acquisition Across Time Zones

Problem

Our company was acquired by a company based out of Berlin. Part of the deal was to have a contracting company over our platform and services. Everything we had built was going to be transferred over so it was our responsibility, as the experts of the product, to transfer our knowledge while also continuing to create features and product sets. With that acquisition, we had the issue of collaborating across 4 time zones.

Acquisitions are complicated and stressful processes to handle in the first place, but on top of that we had the added weight of working across time zones. This brought forth a number of issues including working with limited overlapping time, having meetings that were scheduled for a bigger audience, dealing with communication turnaround time, and trying to optimize velocity per Sprint.

Actions taken

On-site Visits

Nothing beats being able to work 8 hours right alongside your coworkers. Although this was a large expense for the corporation, it provided a whole day’s worth of overlapped time that could not be achieved when working across time zones. Individuals would travel for a week or two overseas, giving people an ample amount of time to quickly ramp up before returning home. During these knowledge transfer and deep dive sessions, we had the time to walk through our infrastructure and code base. It left little room for miscommunication.

Weekly progress meeting

In the pursuit of achieving efficiency and optimizing for time, we created a short 15-minute focused meeting done across three different time zones. The point was to get a broad, holistic view of what was happening in the organization, without getting into technical details. Department by department would round-up what they did last week, what they were trying to do in the current week, and how much progress they were making. Everyone was able to quickly gain visibility and insights into what was occurring in customer success, HR, marketing, engineering, etc. all within one weekly progress meeting.

Technical Scrum of Scrums

We decided that we needed to look more in depth technically. As a result I initiated a technical Scrum of Scrums. This was a place where engineering could discuss the things we were doing at that time, how much progress we were making, roadblocks were brought up, and we also brainstormed areas for improvement. It became a feedback mechanism for engineering optimization.

Delegation to engineering leaders

As an engineering leader, if I didn’t talk about delegation then I would have failed. Delegating the work meant that I wasn’t responsible for everything and it also gave others the opportunity to take a different or better approach then I might have. Therefore, working across time zones, it really came down to assigning the work and allowing individuals to coordinate, collaborate, and work on their own time. Not bound by overlapping hours, reports could knowledge transfer, pair program, or work together at their own convenience. This organically evolved to a point where we weren’t having to make sacrifices due to time differences.

Lessons learned

• Find a way to have maximum overlap hours between distributed teams. Regardless, even when you optimize for this, though, there are always going to be gaps. The point is to minimize those gaps.
• I would have front loaded meetings because it took quite a while for us to get a handle on how to operate through an acquisition. I think it would have been smoother if we laid out up front what we should and should not have done.
• I was performing a lot of PM duties as an Engineering leader because I saw that that was the only way to make progress. We couldn’t wait until everything was figured out so I stepped up and took action. If you think you can do it, go after it and do it. Don’t ask for permission, ask for forgiveness.
• Come with solutions, not problems. Instead of discussing problems and waiting to hear back answers from headquarters, I thought it best to provide headquarters with the answers. This was an approach that kept things moving rather than waiting for things to happen.