Communicating and Maintaining Alignment Across Different Time Zones
28 July, 2020
Achieving alignment across different time zones is far more complex than achieving the alignment of people who happen to be distributed across different physical locations. The difficulties occur when multiple time zones have little time overlap between them which impedes collaboration but also brings along an additional set of accompanying issues. Different time zones often imply different markets, cultural and language differences, as well as different skill levels depending on how the team is distributed.
Firstly, we acknowledged that there were not enough hours in the day to hold long meetings and collaborate as we typically would if co-located, as we were constrained by an overlap of only two or three hours. We made these overlap hours our ‘golden hours’ to make decisions and the other twenty-one hours were for people to do their work asynchronously or have non-timezone-dependent meetings. We established that expectation clearly and simply -- only schedule meetings for critical cross-timezone collaboration during ‘golden hours’.
In doing so, we had to change our working patterns and migrate part of our work to collaboration platforms. The team would use these collaboration spaces outside of meetings -- using their own time to ask questions, build understanding and give feedback on project work. Meetings were used exclusively for decision making on the assumption that everyone had provided input ahead of time and that we would use the meeting to confirm a shared understanding of the decision being made. If there had not been adequate ahead of the meeting it would not go ahead.
In addition, to make meetings as effective as possible we instituted a rule that meetings should have an agenda, the agenda should be circulated more than 24 hours in advance and ideally with the materials that would be discussed. This meant that everyone could pre-read the material and come to the meeting with a good understanding of the topic being discussed while clarifying questions could be sent in advance.
Finally, after the meeting, we would be very attentive to documentation -- every time we made decisions in the meeting we would write them down and share in a wiki environment. If anybody wasn't after the meeting or wanted to prepare for future meetings, there would be a clear paper trail of all the agreed-upon actions and decisions. Intentional over-documenting spared us from having to repeat meetings for anyone who could not attend and to mitigate ‘corridor conversation’ decisions that may have taken place after the meeting in an ‘in-office’ environment.
- Every meeting is actually 10 to 15 percent shorter than the allotted time as it takes people extra time to get online, engage in general chatter and start a meeting. For a 30 minute meeting that left us with 20 minutes to cover the entire meeting agenda. That was enough time to address one big decision only and being focused on only coming to an agreement on that one decision was critically important.
- We tried not to make a 45-minute agenda fit into 20 minutes, but to have 10 to 15 minutes of content. This allows enough time to properly discuss the topic within the scope of the meeting. It also leaves enough space at the end of the meeting to recap any actions (with owners) and the next steps. This is critically important because it is easy for meetings to run long and for everyone to leave without a clear conclusion. We also found it helpful to distribute actions and next steps in a recap note.
- When using sharing platforms, particularly in larger organizations, be aware that if you need to collaborate outside of your immediate team, you can encounter issues around licensing permissions and tool understanding. Sometimes it becomes tempting to overcomplicate and to use the latest platform when often the simplest tools could be most helpful if that means everybody can access it and collaborate most effectively.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Vadim Antonov, Engineering Manager at Meta, dictates how he brought a brand new team into the remote learning process by ramping up onboarding and creating a mentor system.
Engineering Manager at Facebook
Vadim Antonov, Engineering Manager at Meta, details his process of implementing an organized execution system for his cross-functional team.
Engineering Manager at Facebook
Rajesh Agarwal, VP & Head of Engineering at Syncro, shares how effectively he collaborated with a newly-joined team as a diverse candidate.
VP and Head of Engineering at Syncro
Han Wang, Director of Engineering at Sonder Inc., talks about adopting a writing culture for making team meetings more effective.
Director of Engineering at Sonder Inc
Deepesh Makkar, Sr Director of Engineering at SunPower Corporation, details the processes he formalized to stay in touch with large, remote teams that are located internationally.
Sr Director of Engineering at SunPower Corporation
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.