An Acquisition Across Time Zones
6 July, 2020
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.
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.
- 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.
Peter Fedorocko, Director of Engineering at Workday, discusses if a manager should keep his skip-level one-on-ones and describes how he introduced the Open Doors instead.
Director of Engineering at Workday
Lloyd Holman, Head of Engineering at By Miles, explains why documentation is essential for any company to achieve excellence, particularly underlining its importance in onboarding new engineers.
Head Of Engineering at By Miles
Pascal Rodriguez, Director of Engineering at Bestmile, shares how his company created a supportive environment for remote work by introducing a self-service and asynchronous mindset rules.
Director of Engineering at Bestmile
Arun Krishnaswamy, Director of Data Science at Workday, elaborates on how he approached a single point of failure problem while sharing three key tips (or guardrails) on how to prevent it.
Director at Workday
Fraser Carlisle, Vice President and Global Head of Digital Product of iShares at BlackRock, explains how to achieve alignment across different time zones and by doing so bridge the gap between different markets, languages, and skill sets.
VP, Head of Digital Product, iShares at BlackRock
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.