4 minute read

ABOUT THE TEAM

Our engineering team consists of 16 members. The majority are based in North America: 3 in the Eastern Time Zone, 1 Central Time, 1 Mountain Time, 5 Pacific Time, and 1 Hawaii Time (Canada and US). The remaining 5 engineers are in APAC, with 3 in Australian Eastern Time and 2 in Australian Western Time/Singapore Time (both UTC+8). This is a fairly wide spread team with minimal overlap across the whole team and so we really have to operate async first. Luckily, we’re at GitHub where remote first culture is a virtue, and this timezone spread really gives us several advantages over traditional centrally located teams.

THE BENEFITS

  1. Our on-call follows the sun

    To minimize disruptions, our on-call rotation will alternate between NA and APAC team members, aiming to follow the sun. This approach reduces the likelihood of overnight pages. Furthermore, individuals working on tasks can hand them off to the newly on-call responder at the start of their workday, allowing the previous person to finish their day. This handoff process generally shortens the duration an individual spends handling a single on-call task.

  2. Long running tasks can be passed between multiple individuals

    Long running tasks or bugs can be picked up and passed between individuals in different timezones. Recently, we had a bug that was discovered by someone working in Hawaii who handed it off to someone in Australia who handed it off to someone in Singapore who then at the end of their day who handed it off to someone in the east coast of the US at the end of their day who handed it back to the original person in Hawaii when they were back online. Now, all of these people have the shared knowledge of this bug, and we have work that was done during all of these hours that otherwise would have just been paused until the individual came online the next day.

    Or, worse case scenario, someone could have exhausted themselves working on the bug all alone not sharing any context without any knowledge sharing or additional eyes to ensure the right solution was found.

    We end up with a tight relay of both information, eyes, and knowledge that allows us to move forward together and closer as a team as if all three of these individuals had coded this solution together.

  3. It’s our code

    Each team member is comfortable and can handle shipping each other’s code. Picking up where another team member left off. It stops being “your code” and “my code” and forces us to look at it under the lens of “our code”.

  4. It feels like we have more hours in a week

    At first I kept getting confused by the date line. “Why are people online on Sunday?” It took me a while to realize it’s Monday for my APAC reports and Friday for me was their Saturday. Then, something clicked and I learned to view this as an asset. We have a feature freeze on Monday, then we have a little bit extra time to get stuff in just under the wire. Our NA friends could count on the APAC team to ship code on those quiet Sunday days. Similarly, for our APAC friends they could hand off their work to us on their Friday so we could take care of it for them while they are out. Suddenly, we’re all making up time we didn’t seem to have before now that we’re all working together. Which allows us to share information and reduce knowledge silos and move even faster than before.

HOW TO MAKE IT WORK

  1. Everything has to be in writing somewhere

    Have a sync meeting? Take diligent notes, or better yet record it and take diligent notes. Have a quick video chat to make a decision? It better be persisted somewhere in writing that other people can reference to understand what happened. Basically, if it’s not written down it didn’t happen.

  2. Minimize as many synchronous processes as possible

    I use geekbot for standups, because it’s automated and async and folks can set it up to notify them at their time of choice in their timezone. Similarly, I suggest doing this for as many things as possible. It’s going to feel hard and odd at first, but it’s really important to get used to this and rely on these tools since it’s absolutely worth the benefits.

  3. Pair folks in projects so there’s at least a few hours of overlap

    It helps that folks don’t feel entirely alone and many need to be able to bounce ideas off each other. So, it’s not a great idea to entirely isolate someone so they’re online entirely when no one else they are working with is.

  4. Create a chart to help you visualize the timezone overlap of your team

    I created a mermaid diagram for my team including the EMs, PMs, and designers to get an idea of all of the timezones that folks are working in which is really helpful when staffing work and when I need to visualize what sort of overlap that folks have. I find it extremely helpful also when I’m trying to schedule meetings as well.

mermaid diagram of timezone overlaps

Updated: