Working async as a truly global engineering team

This is the successful story about how our first distributed and asynchronous team managed to deliver their work efficiently.

The customer onboarding team at Remote was the first team inside engineering to have people across the entire globe, covering the full 24h clock. Our goal is to make it easy, fast, and delightful for prospects to sign up and use Remote to hire employees and pay contractors compliantly, all around the world. For now, we have people in America, Europe, and Oceania.

See also: Supercharged forms guide: Using JSON schema in forms

Organizing and coordinating the work

With people living in such different time zones, the challenge starts with time itself. If I say to Dino that I will deploy the change at lunchtime, what does it mean to him? Or if Matthew says to Martin, he will start at 9 a.m., again, what does it truly mean?

To avoid misunderstandings, when we share times, we make sure to do it using UTC (Coordinated Universal Time). It’s easy to calculate, it isn't affected by Daylight Savings Time, and we don’t need to ask people where they are. Using my examples, I would say to Dino that will deploy at 12 a.m. UTC, or Matthew would say to Martin that he will start at 1 p.m. UTC.

Another difference from other teams I have worked with in the past is that we don’t use SCRUM or any other Agile methodology. Since we work asynchronously, we can’t wait for people to assign work or to have a planning meeting to discuss the next big piece of work. Instead of following the traditional Agile methods, the Remote engineering team has its flow. The work tasks are displayed on a Kanban board. We have the autonomy to pick up whatever task is more important/beneficial for that moment. Our Kanban contains a list of issues ― what we call our tasks or tickets. Those issues usually contain a description of what needs to be done and a few labels. For example, we have one to categorize if the proposed work is for frontend or backend engineers. It helps us to identify and choose what task would have more impact and benefits for customers. The Remote flow allows us to work independently and asynchronously, as we don’t have to wait for the end of a sprint to achieve goals or to have a retro meeting to identify what went wrong or could be improved.

Scheduling meetings

In general, engineering teams at Remote have, at least, one meeting per week for social catchup or to align the team within projects and to make decisions. For our team, however, it wasn’t possible to do this in the normal way.

First, we tried to adjust the meeting times, but it was never good for someone as it was either too early or too late for at least one of the team members. Quickly, we noticed achieving a reasonable time for all team members would be an impossible mission. In an attempt to improve team interaction, our team decided to break weekly meetings into two fortnightly meetings: one APAC (Asia-Pacific) meeting and one for EMEA (Europe, Middle East, and Africa).

In the beginning, it appeared to be working. Nobody needed, for example, to stay late to be part of the meeting. Nevertheless, the feeling that we were excluding the opposite time zone group from the decisions was still there. So, for instance, if the Europe/America team decided to release something important, the team based in the Pacific would only know about the decision later and couldn’t be included in the discussion. We felt a deeper change was required for the asynchronous work to be well established. So, we agreed to transform the team meetings into social team meetings. That way, we could use the time to get to know each other better. This is a marvelous opportunity to know more about different cultures, as we are based in different countries.

Daily work in a distributed and asynchronous team

But how do we make our decisions? How do we make sure all the teams are updated about the projects? How do we discuss some crucial development points?

All discussions, questions, and decisions happen in one or more of these tools: Gitlab, Slack, and Notion. In that way, we make sure all decisions are documented and all questions are answered transparently, making any discussion or decision searchable. We prefer to not assume that all our colleagues agreed with something or that everyone knows about a particular issue. We try to wait at least a few hours until everybody on the team is aware of what will happen and has a chance to participate in a discussion or take any action. We rely on all Remote values like ambition, ownership, and kindness to accomplish that.

Additionally, as part of our daily routine, we separate a few minutes during our day to ask questions to our team or Remote colleagues, even when they are offline. Questions and replies are part of the process to progress on the task and run projects smoothly. We try to keep this type of conversation in public channels, allowing everyone to know what is going on.

Sometimes, this cycle is interrupted. When it happens, there is a straightforward impact on the team's productivity. For example, in Australia and New Zealand, the weekend always comes first, before it does in Europe and America. We constantly joke that Martin, Andrew, and I live in the future. Due to this day's difference, we often leave comments, feedback, and questions to others who are still working. When we start working on Monday, we can read all the messages left to us and take action. If for any reason we don’t receive a reply during our weekend, then it means the answer will come to us only on Tuesday. This gap can cause frustration and delay work if not handled appropriately.

But what if the person doesn’t know the answer or needs more time to figure out what to do? In this case, we prefer to be transparent and say something like, “I don’t know the answer. I will ask someone else to see if I can identify why it’s happening.” For transparent and kind communication, it’s better to acknowledge we’ve received the question/message, even if we couldn’t reply to it, instead of saying nothing and leaving the other person in the dark.

We use a similar approach for merge requests on Gitlab. At Remote, developers rely on each other's code reviews to deploy code. When we send our code for review, it is important to have it reviewed as quickly as possible to avoid having the code sleep one or more nights due to the time difference. Usually, we tag one or two reviewers to look at the code. And when the reviewer can’t do it for some reason, that developer tends to write a message to say when it will happen or explain why they haven’t done it. As I said earlier, we like to be honest and transparent when something unexpected happens.

The team is always learning and improving its communication. A good example happened to me. I had done a deployment during my working hours. But during my night, Bridget contacted me to revert that code because it shouldn’t have been deployed just yet. Because I was sleeping, I didn't see the messages Bridget sent and was unable to act upon Bridget’s request.

Fortunately, she remembered the time zone difference and sent a message to Matthew, who is based in Canada. Matthew reverted that code, and all was well. Then, to avoid situations like this from occurring in the future, we began notifying people when we do deployments on Slack and Gitlab. We also leave notes on tickets to share when is a bad or good moment to release specific code in production.

A new addition to our process is recording videos to share the work and list important points. Those videos have been a really powerful tool and have been used by designers, product managers, developers, and others. Videos provide an easy and simple way to avoid confusion and misunderstanding. When associated with a good description in Slack, for example, a video is a robust way to start a new issue or project.

One positive side of working in a distributed team is we have 24-hour team coverage. When someone in the team is sleeping, someone else is awake. The frontend team may send an update to the backend team at the end of their working hours, and the Backend team can then pick up this update and make progress during their working hours. When they come back the next day, the frontend team’s developers can continue the work. This is a very positive approach, as the backend team avoids being blocked by any frontend work and vice versa. We can be very productive, with little downtime, without overworking to complete a task/project.

Synchronous work also happens sometimes!

Despite all the work coordination, occasionally a synchronous deployment or catch-up is required. Although those moments are happening less often, as a distributed team, we need to be flexible to arrange synchronous catch-ups as every member has a different work routine. Remote is a company that respects its employees' time, and also works asynchronously. As such, we try to avoid this synchronous work as much as possible to avoid routine disruption.

When synchronous work is necessary, we coordinate a good time to sync with Google Calendar. A synchronous meeting that requires all team members is rare. Normally, synchronous work involves two or three developers, our team lead or project manager, and possibly a product designer. We always try to have an agenda and a clear intention about the synchronous meeting.

For instance, we can have a synchronous call to deploy frontend and backend work at one time. Both developers need to be prepared, which means the code is reviewed, updated, and prepared to be released. As part of our communication process, we share with the team what will happen. Following my example, we let engineers know we will do a synchronous deployment. When we conclude the deployment, we also let developers know that. If it is a design meeting or a product meeting, we share the conclusions of that meeting and the recording of the call.

Another type of sync communication are our 1:1 meetings, which are, in our case, regular Zoom calls between developers and team lead. It’s an opportunity to give the lead our feedback, keep each other in the loop, get help with our career growth — and a way to establish a deeper bond as work colleagues.

Async drives speed and flexibility at Remote

Our asynchronous work allows us to have a flexible routine. We can determine when to work and where we work. We can work from home in the morning and at a coffee shop in the afternoon. Some people prefer to work at night, and our asynchronous work allows that. This flexibility brings us such impressive independence!

We can work when we feel we are most comfortable and productive. This helps all of us avoid overworking and deal better with unexpected situations

In my case, this flexibility also supports my health. I have suffered from chronic pain since 2018. A flexible work routine allows me to sleep more when I am tired, go to doctors and physiotherapy appointments, and have breaks during the day to do exercises and self-care activities. I do not need to lose a day of work anymore if I need just a bit more rest during the day.

As always, there is no silver bullet. Our team is still evolving and learning from its own mistakes and success. Our goal is to improve our communication even more by creating more opportunities to share the progress of our work. Adopting these processes can help us detect earlier avoidable bugs and prevent misunderstandings through good communication inside the Gitlab issues.