How to Work With People Who Work While You Sleep and Sleep While You Work
By: Myyk Seok
Tags: Collaboration, Software Development, Remote Working

Photo by Matheus Vinicius on Unsplash

Background

Hello, I’m Myyk, a Principal Software Engineer at Grab working on their carpooling matching algorithm backend for GrabShare. I started at Grab in Seattle in January 2017 and later moved to Singapore in May 2018. I’ve had the unique experience of working on both sides of the world overcoming the challenge of working while my coworkers across the world did not. My team has experienced been a lot of growing pains to learn how to make cross-continent work efficient and less painful. I’m sharing some tips that worked for us.

My advice is mostly for software engineering teams but it might apply to other areas. Please share in the comments other tips you might have.

I wrote this and sat on it for about a year and now covid-19 has hit and the lessons feel more relevant but a little different too. I hope this can help teams still struggling to adjust.

Lesson 1: Meetings before work or after work, not both

I’ve been a bit lucky on this because my team is separated by 9 hours and not something closer to 12 where it’s very tempting to alternate between before and after work in the guise of “fairness”. Alternating is a pitfall that will result in everyone working all the time because they have meetings before and after work. My team can only have meetings for a couple hours after work in Seattle and before work in Singapore. People have had better work/life balance this way.

Lesson 2: Have a Code Review Contract

All these pretty much apply to design reviews as well except the timelines can be stretched out a bit.

Code Review International Team’s Code Early In Your Day

It’s very important to have people in the same timezone that can approve changes. This will help keep velocities highest. When you really do need reviews from counterparts across the world, they _must_ review it during their next working day, preferably as one of their first things in their day. This may give the other side the chance to make more progress if they want during the other side’s same day.

SLA for Review Period — 1 working day

You should have company wide rules allowing for reassignment of reviews if required reviewers are not responding. If say, the team in Singapore doesn’t review a request from the US after 1 full working day, the US team may assign a new US reviewer and merge the changes once accepted. This keeps teams from becoming super frustrated with working with each other. And if the SLA breaking team is upset, they can improve by upholding the SLA in the future.

Description of Changes

Since you can’t just pop over to your coworker’s desk and explain the set of changes, make sure the commit code review tool has a detailed explanation of the changes. Even call out something you think they will say with an explanation on it where a code comment doesn’t make sense.

Automate Style Comments

Don’t add onto the slow turn around time on reviews with style nits.

Document Best Practices

This serves as a great learning tool for new hires and allows you to link in to your code reviews.

Example of a good guide: https://github.com/uber-go/guide/blob/master/style.md#error-types

Approve with Comments

Trust your coworkers to handle tiny refactors in a follow up commit while landing the code if it’s otherwise ok even if style isn’t 100% up to team standards. This will let everyone move faster. If they regularly forget follow up, fire them.

Lesson 3: Rethink how you do meetings

Reduce In Person Meetings

In person meetings are really convenient, but they do leave out anyone not there. It’s better to put these discussions into wiki, documents, slack or email to include others not there. They can either follow along or ignore, but it feels a lot better to your coworkers not there if you give them the option.

Everyone Dialed In

This is something I found really useful when my team was in NYC and I was remote while working for Gilt. Everyone in the NYC office would be sitting at their desk and dialed in on a headset. When compared to a meeting room with people dialing it, this puts everyone on a near even footing in the meeting. When a bunch of people are in a meeting room, two people talking at once makes it impossible for remotes to hear, also latencies make it hard for remotes to add to the conversation. This brings everyone closer to even.

Record Meetings

If you can, record your meetings. This is a way you can do in person meetings and require less sync ups if the other side is optional to attend. You can alternatively setup the laptop to record. Your teammates can then playback in up to 2x speed which will save them time too.

Take Meeting Notes

Take notes and share them so that those that couldn’t attend could read what was discussed and what outcomes came out of the meeting. This is also good for if people forget what was committed to.

The note taker should be either the most senior team member or rotate this role each meeting so that there’s not one teammate becoming a secretary. Good leaders should watch out for gender bias here.

Give Remotes an Opportunity to Accept a Meeting

In other words, don’t expect your sleeping coworker to attend a meeting that wasn’t scheduled before they went to sleep. It’s acceptable for them to miss your meeting because they may have planned to do something in the morning or wakeup later.

Lesson 4: Send new teammates to HQ for a while and early

It’s good for morale and the team to understand the product. In Grab’s case, our product is in South East Asia only, it doesn’t make much sense to use Grab from the US since it largely just doesn’t work. It’s important to make remote employees excited about what they’re working on and instill the company culture early. The new teammates will need to make a few personal connections on the other side or they will not be effective at their job.