You’re reading an excerpt of The Holloway Guide to Remote Work, a book by Katie Wilde, Juan Pablo Buriticá, and over 50 other contributors. It is the most comprehensive resource on building, managing, and adapting to working with distributed teams. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, 800 links and references, a library of tools for remote-friendly work, commentary and future updates, and a high-quality PDF download.
Time Zone Protocols
Common questions covered here
How do you handle time zone differences between remote teams?
How do you overcome time zone differences?
What tools do you use to manage time zones for remote teams?
Like most factors in remote work, time zone management depends on how each company (or each department or team within it) chooses to deal with the spectrum of time zone differences, as well as the tradeoffs they want to make.
Time zone protocols are outlined in the team agreement, clarifying how people communicate when they are not in the same time zone, and hence may not have periods of overlapping availability for synchronous communication like video calls.
In general, you have two broad options here: establishing windows of “core hours” overlap during which things like video calls or stand-up meetings can occur, or designing collaboration plans that push more collaborative communication to asynchronous mechanisms and don’t rely on overlaps that are needed for regular synchronous communication.
Establishing Core Hours
Tools like the World Clock Meeting Planner help you plug in all the locations of your distributed team to see where you have overlap (areas in green across all locations).
This sample team is spread across four cities in four different countries, and has two hours of overlap, presuming some folks can start at 8am, and others can end at 6pm. If the team sticks to a traditional 9-to-5 schedule, there’s not even a single hour of overlap. So if team members want to have a stand-up meeting, their protocol might be to have one that alternates between an 8am start time for San Francisco on some days, and a 6pm finish for London on other days.
importantIf you maintain core hours and some team members fall outside those hours, it’s imperative that your protocol be clear about the impact in terms of early or late hours for meetings, and that it ensures anyone impacted by that is OK with it. It’s also important to revisit that protocol semi-regularly, to make sure it’s not taking a toll on anyone who enthusiastically agreed to it initially, but is finding it hard to sustain.
cautionThe above team might be just one new employee away from losing any areas of standard business hours overlap. Asking people to attend meetings at early or late hours can be very challenging for people who are caretakers, which is one of the many reasons people choose remote work in the first place. At some point, you may be forced to architect your time zone management in a way that will support business growth and individual needs.
Decreasing your dependencies on time zones can allow an organization to quickly expand to different geographic regions, to be resilient in case of emergencies, and to give increased autonomy to employees so they can deal with life as it comes.
Follow the Sun
Eliminating a dependence on time zones for synchronous communication requires some significant shifts in how your team works. For some kinds of work, this shift might be a bit easier. Customer support teams with queues that people work through can easily adapt to having team members roll into the queue as others roll out. Even for more collaborative teams, like software development, marketing, or sales, examining and breaking down the work to be done can lead to practices like software developers noting the status of where they left off so that another developer can pick it up when they begin work; or a marketing team member providing edits or feedback on written materials for someone else to revise when they’re back online.
Much like other aspects of your team agreement, this will require some introspection and iteration from the team to figure out how to break down the work so it can travel around the world. Practices that we detailed earlier, like having clearly documented goals and tools for status details, are critical in this case. It may change your team’s cadence as well, as you can’t rely on synchronous meetings to get status, resolve issues or questions, or make decisions if something needs to change.
importantIf the speed of execution and/or very tight coordination between team members is critical to your business, too much time zone spread may be a risk you’re not willing to take on (at least not at the moment). In this case, you’ll have to constrain your hiring to specific regions or time zones.
Determining whether you build an organization with core hours or one that transcends time zones is ultimately your choice. Whichever way you go, it’s best to be sure to explicitly define how you think about time with your team, and then to incorporate this into your team agreement.
It might be good to know who’s around in a true emergency, but 1% occasions like that shouldn’t drive policy 99% of the time.Jason Fried, co-founder and CEO, Basecamp*
Availability protocols are a part of a team agreement that clarify how people communicate what times they are present and available to respond in communication tools like email, chat, and calendaring apps.
If a team is skilled at working asynchronously, presence becomes secondary to getting work done. When everyone defaults to “on track” and has thorough documentation available about best practices, they shouldn’t need to interrupt anyone to get things done. But sometimes, someone on the team will be stuck without the information they need, or something may be truly urgent. In those cases, it helps to know who is available when, the best ways to contact them, and what to do in the case of emergency.
You’re reading a preview of an online book. Buy it now for lifetime access to expert knowledge, including future updates.