On Working Remote and Time Zones

Just over one month ago, my wife and I moved to Australia temporarily. We will be here for three or four months, and during that time, I will continue working for my company back in the United States. This means I am working remotely, but more importantly that I am working with a large time difference between myself and my coworkers. My coworkers are split between the East Coast (engineering team) and West Coast (product teams) of the United States, so I am 8.5 to 5.5 hours behind my coworkers - but I’m on the next day. So when I start work on Tuesday morning at 7 AM, my East Coast counterparts are seeing 3:30 PM, Monday. With Daylight Saving Time around the corner, that difference will increase by two hours over the next three weeks.

Such a large time difference creates some challenges, stemming primarily from two sources. First, it is hard to find overlap with my coworkers on the East Coast, and second, it can be overwhelming to start my day when everyone else is in full swing already.

To tackle the first issue, I start my day around 6:00 AM, giving me ~2.5 hours of overlap with the East Coast work day. This is usually enough time to tackle code reviews, technical specifications and troubleshoot anything that may be going on. The short overlap does have some impact on my immediate velocity, for example, on code I need to review as well as code I wrote that needs reviewing. I don’t believe this has greatly effected the overall velocity of the team, but it can make it feel very slow to go from writing code to releasing it to production, as there is often a one day turn arond time.

This overlap will be shorter when Australia’s Daylight Saving Time goes into effect, making my 6:00 AM start into a 4:30 PM start on the East Coast. I am considering trying a split day at that point, getting online between 10:00 PM and 12:00 AM (8:30 AM - 10:30 AM ET) to overlap with the East Coast and then start my normal day a bit later, still getting some overlap with the West Coast.

The second issue, starting in the middle of the work day for the rest of my team, is overwhelming just in the sheer amount of information that is presented to me as soon as I start my day. Most of my team has had nearly 5 hours of conversations, troubleshooting, pull requests, questions, etc. by the time I log on. I have taken to using the first 30 minutes of my day to slowly consume this information, without disctractions. We primarily use Slack to communicate, so I use the “Unread Messages” feature to slowly work through conversations, without the possibility of losing them. If I find someone has directly asked for my help, I try to let them know that I have seen their message and reassure them that I will get back to them as soon as I can. By the time I finish reading through all of these messages, I have a prioritized list of action items that I need to take care of prior to sitting down with the work I had planned for the day.

The final issue that I have faced is that because my overlap with my coworkers, both on the East and West Coast, is during my morning, most of my inter-personal work (code reviews, product requirements, meetings, etc.) happens in the morning now. I prefer pushing most of that work out to the afternoon, however, because I am much more focused and productive during the morning hours, making it the best time for me to be focused on programming and solving problems. I don’t have a solution to this problem, but I think the split day may help, as that will allow me to work with the engineers on the at night, and put focus towards helping the rest of the engineering team be productive. Any product work I need to do will still need to happen in the morning, but there is usually less of that for me.

One unique benefit the time difference provides me is that I start my work week one day before the rest of my company. This let’s me pull in important tickets and focus on them for an entire day without any possibility of interruption. With this time, I have been able to tackle a number of high priority issues early in the sprint, really before it has been started for the reset of my team.