A New(er) Problem
Context
I’m here to talk about issues with time-zones.
Not issues forgetting to call .toLocale on the frontend. And not issues using a time from the user or server instead of Unix time or UTC in data-systems.
With remote work exploding after COVID-19, teams are built from talent across the country. Geographical diversity increases the ability to build teams with a variety of backgrounds, cultures, and experiences.
However, a new problem emerges for companies recently going fully remote: coordinating across multiple time zones.
This problem is amplified for companies that were primarily dependent on synchronous collaboration pre-COVID.
Symptoms
- Communication issues internal to a team or across teams
- Difficulty in finding time for synchronous collaboration across individuals or teams
- Engineers complaining about too many meetings or not enough focus time
- Meetings getting scheduled regardless of a team’s availability
- Calendars with awkward gaps between meetings
- Collaboration is solely or primarily synchronous
Evidence
Below are a few recent studies and another from 2014 regarding remote engineering teams and working in distributed time-zones.
on the impact of time-zones:
The case study data indicated that multiple time zones were perceived as having a highly negative impact on the effectiveness of plans as coordination mechanisms.
…
Time zone differences were revealed as having a highly negative impact on the effectiveness of FMA as coordination mechanisms. All participants made a number of negative comments relating to time zones and formal interactions between team members.
FMA Acronym:
Coordination by formal mutual adjustment: coordination by formal mutual adjustment are those mechanisms that require team members to interact in a pre-defined manner, such as project meetings.
(source - 2021)
on the impact of Zoom for remote teams:
The current paper presents the development and validation of the Zoom Exhaustion & Fatigue Scale (ZEF Scale)
…
Similarly, consistent with our hypotheses, the ZEF Score was positively correlated to the three measures of video conferencing use: a higher ZEF Score was associated with having more meetings (frequency, r (2724) = 0.27, p < .001), longer meetings [duration, r (2724) = 0.12, p < .001], and the tendency to cluster meetings together without breaks in between [burstiness; r (2724) = 0.22, p < .001], suggesting high convergent validity.
(source - 2021)
on the slower response times across teams with temporal distance:
In contrast, hypothesis 7, was consistent with both the predictions of existing theory and the oft repeated statement “latitude hurts, longitude kills” that indicates that it is not merely the presence of geographic distance that results in slower interactions, but the presence of temporal distance that causes the greatest challenge to response time in distributed teams.
(source - 2014)
A Solution
Asynchronous communication is not new.
For the majority of history, async communication was unidirectional (books). Bidirectional async communication has been increasingly growing in usage and decreasing in latency. From smoke signals, letters, telegraphs, voicemails, text messages, emails, instant messages, and the entirety of the internet - we’ve reached a point where asynchronous communication tools can be leveraged effectively in a real-time / synchronous-like manner.
Is that a good thing?
An imbalance & misalignment in how communication tools are leveraged appears to cause more than a few issues as noted above.
If one individual uses a communication tool expecting near real-time collaboration and another expects asynchronous - how do we resolve those differences?
Let’s clarify these two communication types for engineering teams more specifically. For the remainder of this post, let’s assume that:
- Asynchronous: Diagrams, Documentation, and anything not expecting quick replies
- Synchronous: Video/voice calls & instant messaging
Note that instant messaging (eg. Slack) is grouped within synchronous communication. While messaging apps can be used in the traditional async non-realtime manner - the affordances of instant messaging seems to benefit from realtime communication rather than delayed responses.
1. Establish the Team Zone
Implementing a common ground for when synchronous & asynchronous collaboration occur is one small step in improving the situation.
That common ground can be by establishing a Team Zone.
A Team Zone is:
- a time in which synchronous collaboration is expected
- respectful to team members working hours
- communicated across teams for visibility
How do we decide on the time? Put people first - start with working hours.
Let’s say we have a team members across Eastern, Central, & Mountain time zones:
- Alex (Eastern), works 8-4 ET
- Blake (Central), works 9-5 ET
- Carter (Mountain), works 10-6 ET
The Team Zone could be placed from 10:30 - 4 (ET) as diagrammed below:
With our 10:30 - 4 (ET) Team Zone, we get 4 hours of protected time and at least 4 hours of synchronous collaboration. Protected time above is noted so that other forms of synchronous communication can occur besides meetings.
You’ll notice one individual does get the short end of the stick in this scenario - Blake. Blake’s maximum time to focus on heads down work is an hour and a half. Depending on the project, it could be hard for Blake to contribute meaningful work without working outside of his normal hours.
Disagreement among the team for the range of the Team Zone can be solved quickly with your favorite survey tool and some ranked voting.
2. Balance Synchronous & Async Communication
- If it isn’t written down, it isn’t real
- Lean heavily on diagrams and writing to communicate ideas effectively
- Sent does not mean received
- Build in a mechanism for tracking acknowledgement if it is important
- Make meetings matter
- I’ve noticed meetings having a single goal, agenda, and supporting documentation/artifacts end up being much more productive
- Gather feedback via new methods
- Obtaining consensus or reactions across a broad audience via short surveys is simple and having quantitative data is better than just observations
- Use synchronous tools in async ways
- Leverage video/screen recordings to scale announcements or knowledge sharing
- Schedule messages to send during the Team Zone. (such as slack’s scheduled messages)
Team Zone Scenarios
Let’s dive into some scenarios and play around with the range of a Team Zone across a distributed team.
Team Members
- Alex (Eastern), works 8-4 ET
- Blake (Central), works 9-5 ET
- Carter (Mountain), works 10-6 ET
- Daniel (Pacific), works 11-7 ET
Protected Time - max continuous: Out of all team members maximum protected time, the team member with the smallest continuos protected time. (Remember Blake’s hour and a half for focused work in the original example above).
The Mid-day Break Team
Team Zone: 10 - 4 (ET)
Impact
- Team Zone: 4 hours, 50% of the day
- Protected Time: 4 hours, 50% of the day, max continuous: 2 hours (Blake & Carter)
- Synchronous availability: 4 hours, 50% of the day
Highlights
- Per title, a reasonable break protected from meetings in the day
The Hungry Team
Team Zone: 11:30 - 3:30 (ET)
Impact
- Team Zone: 4 hours, 50% of the day
- Protected Time: 4 hours, 50% of the day,max continuous: 2.5 hours (Blake & Carter)
- Synchronous Availability: 4 hours, 50% of the day
Highlights
- Per title, no one has time for a reasonable mid-day break between synchronous collaboration
The Async Team
Team Zone: 12 - 3 (ET)
⭐ For this scenario, Alex (Eastern) prefers to work 7-3 instead of 8-4.
Impact
- Team Zone: 3 hours, 37.5% of the day
- Protected Time: 5 hours, 62.5% of the day, max continuous: 3 hours (Blake & Carter)
- Synchronous Availability: 3 hours, 37.5% of the day
Highlights
- Alex & Blake can grab lunch at a semi-reasonable time, Carter & Daniel can take lunch after the Team Zone
- Adding a mid-day protected block would be simple if some team members are willing to have a shorter maximum uninterrupted time of 3 hours.
Unresolved Questions
Why are people only working 8 hour days in the above scenario?
The Team Zone concepts could easily be applied to 8h+ days.
Four hour work week studies are showing promise. Software engineers are capable in producing massive efficiency gains on products and their internal workflow.
This blog is focused on the efficiency of code, systems, processes, user-experiences, and teams. If we can’t make our days efficient uses of time - we have a serious problem.
What about global companies?
Without any experience in the area - clustering Team Zones could help.
For example, having decoupled Team Zone clusters in the Americas and in Europe would be ideal.
The Americas and European Team Zone clusters would operate on fully asynchronous communication.
How to deal with cross-team meetings?
There’s no silver bullet.
As seen in the above scenarios, there are clearly conflicts if teams are not aligned on their Team Zones.
Too many cross-team meetings can be a symptom of a greater problem - strongly coupled teams, async communication issues, or some other systemic problem.
However, cross-team meetings do need to occur. Browsing through the above scenarios - roughly 1-3 ET would be the ideal time to schedule cross-team meetings across when team members are available.
If cross-team meetings became frequent, the likely impact would be that teams would drift their Team Zones to full encapsulate the 1-3 ET time frame (due to mid-day protected time getting stomped on).
Below are the three Team Zone scenario’s along with the original example as Original Team.
In the end, it all depends on what we want to optimize for.