Working From the Other Side of the World

TL;DR

Working across timezones is tough, and requires a supportive and flexible team. Communication will become more difficult, but trying to find small things that work for you and your team - and steadily building on those things - can help to make it work.

---

One of the benefits of working as a developer is the ability to work from anywhere, anytime. But how about when your team is working at a set time, in the same time zone, and only one person is working from the opposite side of the planet?

That was the question that our team had when I boarded a flight in Tokyo, and headed home to the east coast of the United States to work remotely for the month of December.

A little background

A fair number of tech companies these days are fully remote with people working all over the world. Some companies have "work anytime, anywhere" implemented into the core of their company culture. Without a little bit of context, what I'm writing about probably doesn't seem all that interesting.

I'm a developer in Japan. Within Japan, I work remotely, as does the rest of our team for the most part, and so working remotely is something that we as a team are used to. Like many people living abroad, it's been quite a while since I've visited home because of Covid. With this in mind, the company that I work at, Globis, introduced a system allowing international staff to visit home and work remotely for a few months to spend time with our families.

We use scrum as our development strategy, usually working in two week sprints. We have a daily stand-up, weekly product backlog refinements, as well as various other meetings where we refine tasks, discuss on-going issues, and communicate with other teams – not to mention the more general division and company-wide meetings.

Who we are

• two frontend developers (me included)
• two backend developers
• 1 scrum master (and frontend/backend hybrid developer)
• 1 product owner

How we work

• Communication: we have a good mix of text and voice, with lots of jumping into calls to talk things over
• Working together: many days will include at least a little bit of pair/mob programming or actively working together in some way
• Input from everyone: not many decisions are made just by one person, and we like to hash things out before deciding on things
• Rhythm: we try not to let issues sit for too long, and value quick back-and-forth in code reviews

The issue

So we're a fairly small team, working remotely in Japan, who enjoy working together. If I was going to try to work purely according to Japan hours, I would be working from 8pm to 4am each day, which would be tough. The question was, "How could we maintain that level of communication and still maintain a healthy life style while having little overlap between time zones?"

(For reference, here's the overlap between JST and EST)

The first thing that we did, was that we made sure that the times that we did overlap would be focused on in-person activities: one-on-one meetups, pair programming, discussing important issues, etc. We figured that the best chance we would have each day would be 10am-12pm JST for the team, and 8pm-10pm EST for me.

Originally, my plan was to work from around 2pm until 10pm each day, but because of jet lag – and also the fact that I'm just a morning person in general – I ended working a morning block from around 5am to 9am, and an evening block from around 6pm to 10pm. It actually worked out great, as I would work until my wife and 2 year-old son woke up, hang out with them for the day, take a nap with my son in the afternoon, eat dinner and then jump back on to work in the evening.

Keeping in touch

As I mentioned, we're a team that values communication, and so we wanted to try to somehow maintain that level of communication while in the states.

A few things that I did which I think worked pretty well were: 1) create a daily remote log, and 2) send a video message on Slack each morning.

For the remote log, I basically kept a daily blog in Notion where I would take notes about the work I was doing, the problems I was having, some things that I thought were funny, and even a daily picture from my time in the states. The content was focused on anything that wouldn't fit cleanly into pull request comments, JIRA ticket logs, or the other channels that we have for topic based communication.

For the video message, I would record a one minute or so video each morning and share it in our Slack channel. The content wasn't really too important - more than anything it was just me trying to show my face and make sure everyone remembered my voice. I think people enjoyed it (or at least they made it seem that way 😇.)

Furthermore, we set up a 15 minute block each Monday morning (Sunday evening for me) for just a quick, fun, random chat between the team.

Record everything

One of the biggest concerns that we had as a team was how I would be able to keep up with the daily/weekly scrum events. Our scrum master thought it would be good to record all of our meetings so that I could watch them, and so that's what we did. To start, he would link the video for each meeting on Google Calendar, but we quickly felt that it was too much of a hassle. In the end, we ended up making a new channel on Slack where the videos would be posted whenever the recording was complete. It ended working out well, and I think it was a pretty cool solution.

Besides the meeting recordings, we also started to use Slack video messages for discussion about code as well. Of course, we did the main communication by text in the pull requests, but we found that sometimes it was easier to explain things simply by sharing your screen, and talking through what you were doing. Something that could take hundreds of words and a lot of thinking/editing in a pull request comment, could sometimes be more cleanly illustrated by explaining your reasoning while walking through the code, highlighting some variable and function names, and the always helpful phrases of "you know what I mean" and "something like that."

My general schedule

Here's the schedule that I came up with, that worked out for me.

Morning block (5am - 9am)

• Log on
• Drink some coffee
• Catch up on Slack, make sure nothing's broken
• Create today's remote log, and start taking notes
• Chat with people if anyone is still awake
• Watch the previous day's daily standup video, as well as any other meeting videos from the previous day
• Do work (coding, PR reviews, documentation, other stuff etc.)

Evening block (6pm - 10pm)

• Continue working
• Finish today's remote log
• Check-in on Slack with a video message and link to the daily remote log
• When everyone gets on, have meetings, talk about work with coworkers
• Figure out what I'll be doing the next day
• Log off

A case study

During my time in the states, the main task that I was working on was the implementation of a logging mechanism for our web app. Without going into too much detail, the project is a bit of a tricky one, as it's centered around things that the user touches - buttons and links, and those sorts of things – and has pretty wide ranging consequences for our code base. We wanted it to be close enough to the code that we could get the necessary data that we needed from user events, but not too close that it would be baked into our logic or components.

The mobile app team had implemented a similar sort of mechanism, and so we originally planned to keep the general structure of the event names and properties as close to the mobile app as we could. However, we quickly learned that things would need to be a bit different for the web. It was the sort of project that required a bit of coming up with a plan, trying it out, and then rethinking things as we got a greater sense of how the architecture of everything would play out.

Normally, this sort of thing would happen throughout the day, with bouts of writing actual code mixed in with little meetings and some back and forth across Slack. However, because of the time difference, things happened more in blocks: I would spend the day when everyone else was asleep working on the code, then spend the evenings (or, mornings for the team) talking with the other frontend engineer about the implementation, sometimes leaving unanswered questions to him while I would go to sleep, and vice-versa.

It had its ups-and-downs, but one day in the early morning (late evening in Japan), my coworker and I were able to release the core logging mechanism onto the production server. It was an exciting moment, as it is anytime you find a solution that you feel comfortable with. But it felt extra sweet because we had managed to release it while working across the divide of 10,000 km and 14 time zones.