Improving Collaboration Between Engineering and Product Across Time Zones
6 July, 2020
Post acquisition our company was faced with a delivery problem because for a while we didn’t have any Product Managers (PMs) and once we did they were located and working in a different time zone - in Berlin. Previously, it was required that everyone be collocated so that we could brainstorm ideas, meet, and come up with a plan within days. It was actually really amazing to see this process and the teams felt a sense of pride and accomplishment afterwards. However, after the acquisition it was extremely difficult to get things done.
In addition to engineering having to work asynchronously with PMs in Berlin, though, other PM issues presented themselves. For example, the new PMs were not familiar with our brand, our old PMs had more responsibilities than simply product planning - project management, data, and analysis, and there were few overlapping hours with PMs in Berlin.
During the acquisition there was a period of time where we didn’t have any PMs at all, so senior engineering leadership started to wear the many hats that product had worn. We had domain knowledge and although there was a huge disparity when it comes to engineering and product, we ultimately all had the same goal.
As a result, those in the VP of Engineering positions started having discussions, would brainstorm ideas, and then would make the product decisions. This did not involve the team but we maintained visibility about our ideas and how they would transform the potential problems we wanted to solve. When the PMs from Berlin entered the scene we were then able to give them as much knowledge as possible.
We also started wearing the analyst’s hat too. This was an easy transition for us, though we did not do full blown analysis. We would run the query and be able to present some numbers. We started doing quick and simple analysis to validate that the feature we were shipping was working as expected then later, weeks or months down the line, we would rely on the analytics team to come up with a solid analysis. Using this approach we were able to find issues early, iterate quickly, and prevent delays in delivery.
On top of all this, engineering leaders like myself took up a lot of project management. This was mostly derived from our company culture of knowing what the company wanted to do and then knowing how to get it done. Due to the acquisition and the decreasing number of people in the company, we didn’t take this role for granted and found it to be a very effective solution for our situation.
Lastly, when initially working with the PMs in Berlin, we had an issue with communication and information transfer due to the time zone difference. A team member would have a meeting with a PM but the followup wouldn’t happen for a week, then to get an answer would take another couple of days, and so on.
So I proposed that the entire organization meet everyday for a 15 minute standup and that the PMs be available for an additional hour or two afterwards. It was a forced overlap of time where higher-level items were shared during the standup and then the complexities of the projects could be broken down afterwards. Eventually, this led to a hybrid of meetings and documentation so that all blockers were discussed in a timely manner.
- There’s no harm in having engineering leaders wear many hats, even those of product. This is especially true if your org is lacking a PM, if as an EM you have a lot of domain knowledge, and if engineering and product have a common goal.
- On top of being engineering leaders, try to contribute to other areas such as product and analytics. The value of the contribution and the speed of execution will improve significantly. You will also feel like you have better control and a better handle on things overall.
- There was a lot of preplanning and pregrooming to make these approaches work. Specifically, I took it upon myself to get up early each day and reserve a window of time that aligned with Berlin’s working hours. I allocated this time for all discussions on blocking, giving the PMs in Berlin information they needed to reduce the noise and plan projects ahead of time.
- The business and company value should align throughout the org. Everyone should be working towards one goal even if each role has it’s different principles and philosophies to get it done.
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.