Trabalhando remotamente: a importância do trabalho assíncrono

Working remotely: the importance of asynchronous work

Software developer Julio Ojeda talks about the importance of asynchronous work and shares personal recommendations for successfully adopting asynchronous work dynamics.

Imagem em destaque

Working remotely has been a hot topic in recent years. For technology people, it wasn't something new, but with the unprecedented pandemic, it was adopted by other industries as well. In the technology sector, many of us (developers, engineers or designers) already worked this way. However, during the pandemic, many others had to work remotely, so it was likely that most of them were not properly trained or equipped to do so. Working remotely has several benefits, but it also comes with some important things to consider. These days, there are even courses that cover most of the things you should follow⁠ – from the very basics, like having the right hardware setup, to communicating to your colleagues and clients that you're now working from home⁠.

In this article, I want to focus on one specific aspect of remote work, which is the importance of being asynchronous. In my experience, this is very significant as it has helped me to be more productive. Being asynchronous means you can keep working while waiting for something else to get done. It could be information collection, a software license, new tasks, etc.

Here are 7 recommendations that will help you enter the asynchronous world:

  • Understand how to work.
  • Have the right tools (Jira, Asana, Trello).
  • Read, read and read. Read the documentation.
  • Come up with more than one question.
  • Being able to video call co-workers on an agreed schedule.
  • Write documentation in a structured way and specify the level of detail.
  • Being able to work on more than one thing at the same time.

1. Understand how to work agile.

To work asynchronously, the first thing you need to do is adopt an agile methodology within your team. Most developers already know agile methodologies and already work that way. It doesn't have to be exactly the same as it is described in the textbooks. You have to adapt it to your team's needs. For example, on a previous project I worked on, we followed the Scrum methodology, but we only had 3 meetings per week instead of strictly 5. We started with 5, but then realized it was better to have just 3, as we had very little to do. say the next day. The important thing is that you have a reference for how to work and how to measure your team's progress so you can continue improving.

2. Have the right tools (Jira, Asana, Trello).

Once you start working with agile methodologies you will also need several new tools to work asynchronously. Communication is the key to achieving asynchronous work. When working in an office you just need to talk face to face with your colleague to get an answer right away. This is synchronous communication. When you work from home this doesn’t happen as quickly. You ask someone and then there is a waiting period before you get an answer. That's why it's important to have the right tools to follow up diligently. You will need at least one tool for each of the following:

  • Email (Gmail, Outlook)
  • Chat (Slack, Skype, Discord, Google chat)
  • Video call (Zoom, Google Meet, Skype)
  • Project management (Trello, Jira, Asana)
  • Calendar (Google calendar, Microsoft Outlook calendar, Apple calendar)

There are many out there and most of them have a free plan to get started. These tools will help you gather all the information you need to accomplish a task by collecting and tracking all tasks in one place. It will provide an excellent asynchronous communication channel.

In my experience, it was overwhelming at first because it seemed like a lot of tools to learn and keep up with, but over time I got used to them and now recognize their value. I would find it difficult to work without them in my daily work.

3. Read, read and read.

This is the basis for working asynchronously, so you will have to master the ability to read documentation. When choosing an assignment, the first thing you will do is read it. If there is any documentation, try to read it as much as possible; that is the purpose of your existence. It doesn't matter if it's outdated or too long. It would probably take less time to read than it took to write, so respect your coworkers' efforts. Also, if you read it, you will understand the context better and subsequently ask better questions.

4. Come up with more than one question.

I would also recommend that if you have any questions, don't ask right away . It's obvious, but sometimes you might forget to read the documentation first. If you can't find the answer yourself, don't ask right away. If it's not critical, put it in a list of questions and try to assume the most logical answer in the meantime so you can keep working. Once you have some doubts or a very critical question, it's time to ask for help. Remember that every time you ask for help, your teammates may stop what they are doing, so it is very important to dedicate as little time to them as possible.

5. Be able to video call co-workers on an agreed schedule.

Video calling is a much faster and more practical way to clarify doubts than via chat or email. When working remotely, your colleagues are likely to work in different time zones, so I recommend agreeing a time frame in which anyone can request a video call to answer questions. Remember to first read all documentation and prepare more than one question before scheduling the call to make the most of these brief meetings. Maybe this teammate has done something similar to the task you are doing and you could benefit from their advice.

I like to schedule these types of meetings early in the day, usually during daily stand-up. This is when I ask questions or I will also be questioned. Then I dedicate the rest of the day to production and I will have new questions for the next day.

6. Write documentation in a detailed and structured way.

When you dine out at a restaurant, the waiter takes your order in detail and passes it on to the kitchen staff for preparation. This is a perfect example of what asynchronous work looks like. You'll have to let others know what you've done so they can work asynchronously too. Writing good documentation is crucial. This will help you in the future to save hours of explaining the same thing over and over again and ensures that the quality of the information will always be the same.

It is important that you specify the level of detail . For example, in this article, you can only read the first paragraph and then you will find the subtitles at the top, and you can only read the titles, but if you want more information, you can skip to the specific topic that interests you. Let the reader have the option to read as much as they need.

After writing a task or message, I always read it. Sometimes I realize that I skipped some important information because I wrongly assumed that the person reading it already knows what I'm talking about. This helped me a lot to improve my documentation writing skills.

7. Being able to work on more than one thing at the same time.

For some people this can be overwhelming, but it's probably because they're doing it the wrong way. If you work in an agile way, have a lot of documentation and have the ability to generate good documentation, you will feel comfortable working this way. Being able to stop a task and then return to it seamlessly is necessary for working asynchronously.

Personally, I like to use the first half of the day to carry out all meetings and administrative work. I dedicate the rest of the day to producing code. This way I am 100% focused and will likely have fewer to no distractions.

Remote work is here to stay and I believe it will continue to expand to most industries in the near future. It has numerous advantages, but it also brings some things to keep in mind, so accept the change and prepare for it.

More blog posts from our BDevers.

Related Content

Back to blog

Leave a comment

Please note, comments need to be approved before they are published.