ggirtsou's Blog

Thoughts on software and architecture. GitHub

6 July 2019 Reading Time: 4 mins

Working with people in different timezones

Working with people in different timezones

Photo by Lukasz Szmigiel on Unsplash

Over the years, I’ve learnt how to collaborate with people working remotely effectively and how to remain productive and remove distractions when working remotely. In this post, I talk about my learnings and how I approached it.

Remote working can be tricky, tiring, have slow feedback cycles, and the most straightforward decisions can take weeks.

Talent is not necessarily where your company’s HQ is

You want the best people (skill and behaviour and culture fit wise) to work for your company. Adapt your culture to embrace remote working so that you can have access to more talent.

What is the remote working landscape in London, UK?

I live in London, UK and there are a lot of companies offering remote working as a perk. Working from home a few days per week is more common than fully remote working. But if you want, you can still find a company that offers it or negotiate the agreement. Some companies are new to remote culture and want to establish a trust relationship with the employee first.

People who are around you +/- 2 hours

My first interaction with remote colleagues was with Povilas Versockas. He’s a top-notch engineer, knows Kubernetes and Go inside out, and his articles were on HackerNews first page many times!

Depending on the agreement you make with the company, you start earlier/later in your timezone so that it aligns with where most of the engineering department is.

What I do

I work in Platform Engineering tribe as a Software Engineer and spend my time with our engineering teams in London, Hong Kong, and Australia office.

Our Onboarding squad works with engineers to help them bring their applications to the cloud. We advocate best practices, participate in architecture discussions and help with scalability concerns, and make great tooling to make the onboarding process easier and faster.

There are three people in our team and hundreds of engineers in the company which doesn’t scale. So we need engineers to learn more about our tooling and how we do things. We help them, but can’t do it for them.

However, what we can do is to make the onboarding easier for them by building great tooling that automates the tedious steps.

People who are around you +/- seven to nine hours

With Hong Kong, we have 2 or 3 hours overlap (depending on BST), but with Australia, we don’t. When we get to work, its 6 pm in Australia and people have gone home for the day.

How I work with Hong Kong

Our Hong Kong engineering team wanted to deploy several services to AWS.

We prioritized requests from HK when we started work, and a few days later, I flew over for two weeks. Here are some pretty pictures:

Buildings in Hong Kong

Hong Kong Port in Causeway Bay

View from the office in Hong Kong

View from the office in Hong Kong

Dim Sum Restaurant in Hong Kong

Working with them was great for both sides. I got to know them in person, understand their problems. I helped put a face for our team, and they learned all they need to know about the tools and workflows to get their applications in AWS. They stay up to date by joining our demos, chatting with us on Slack, and doing Zoom calls.

How I work with Sydney, Australia

I volunteered to have a midnight call with our recently hired engineers in Sydney. It seemed like a great way to give them an introduction to our tooling, our workflows, and how they can get started.

While this was an excellent way to get started and say hello to each other, it doesn’t work in the long run. I cannot ask people to do the same, and they cannot expect me to do it.

So we have a person flying over and staying with us for two weeks to get things done :)

Common patterns

If your company can afford it, fly over people from one region to the other for two weeks. They can work together, learn from each other, better understand the workflows and have quicker feedback. They will catch up quickly and establish a trust relationship. Being on the same page is fantastic as you have less back and forth when merging Pull Requests, for instance.

Get remote workers in the office every couple of months, or if your team is fully distributed, you can all meet at a different location (what Canonical does). This way, everyone gets to experience a new country, team members bond, and they can work together for a while.

Are you considering a remote offer?

If you are not in the same timezone as the people you’ll be working with, think very carefully what you’re getting into before accepting the offer. It might seem like a great deal, but you have to take into account the sacrifices you have to make to work different hours and how that is going to affect your work-life balance and your family.

Your experience

I’d love to hear your thoughts or the challenges you faced working remotely. Feel free to reach out to me on LinkedIn!

tags: remote - working - challenges - timezones - distributed - teams