Asynchronous (Async) vs Synchronous (Sync) collaboration is one proverbially "hot topic" of remote work, and we're grateful to Tijana Momirov for hopping on to share her expertise in this area. Tijana, has been working fully remote for 10 years, and is the Founder of StartupSetup -- consulting with tech startups designing, developing and launching software products in remote environments.
Any opinions expressed within this blog post are those of the author and not necessarily held by Workplaceless itself.
With the remote work and the gig economy booming, the ways we collaborate have been going through significant transformations in order to respond to the new requirements. By working fully online since 2010, I’ve noticed several phases the remote work collaboration has gone through, and reached some conclusions on how I see it working out for my teams nowadays.
In the beginning, we were happy that we could exchange info somehow from a distance and then try to work with what we have. There was e-mail as representative of async, and Skype as the main representative of the real time communication. There was no office, and that was good enough.
But pretty soon, not only the number of remote projects and companies started to increase rapidly, but we’ve also moved away from marginal, low-budget, side projects that were running in this space mainly because they were not able to do it the right way (office, suit, business card). Then serious players started showing up. Companies were deliberately opting for remote culture and communication could not just simply be there any more - it had to be efficient, it had to scale, it had to be as good as in the office - if not better.
Slack was certainly one of the main game changers, with many of its’ amazing features, such as the specialized channels, mentions and file sharing, to list just a few. The team started to feel as a team, and we were super excited about that! We went ahead and installed Slack on our phones as well. As a very social person, I was happy to have the colleagues “around”, and without a doubt there were improvements in the work done, but I was often finding myself responding on the chat during all the hours I was awake. Soon I realized that we were taking for granted that we are accessible and starting to neglect the good old planning, specifications and processes. We’d just opt for asking a question whenever we please. This was creating many blocking situations in the project progress, but not only that.
What was even more alarming, and it remains one of the main concerns today, is the unhealthy work culture leading to burnout. Being connected to work around the clock, feeling that the team cannot proceed unless you are there, taking no true breaks and making no boundaries between the work and free time, is a serious lose lose. Async to the rescue!
If people know when they are needed, they won’t feel obliged to be online all the time. Instead of leaving it as an option to jump on a call whenever, unless something is on fire, try sticking to the pre-scheduled calls. Any activity (depends on the nature of your project, but something like iteration planning, campaign preview, release review etc.) should happen in the pre-defined rhythm, so that everybody knows when they really need to be there.
Daily standup calls in the traditional way, even those that are supposed to last for 15mins, quickly become a productivity killer in the remote environment. One of its’ purposes - setting the focus for the day - is already not making much sense if you are having the standup at an odd hour for your time zone. I had situations where I had standup calls at 11pm or similar, which was making my life complicated. By using the async standup tools (I use Slack bots), we can still remain on the same page without it getting crazy. Ofc, as someone in a managing role, if I see an impediment reported by a team member, I’d reach out and organize a real time call if needed.
There are not many things worse than getting online only to see that chat window with hundreds of messages. You feel like you can’t move on with your tasks before you check if something crucial has changed, but in the same time you keep reading so much of what does not matter to your current work. Not to mention that very often you end up missing something important. For this reason, I always insist on putting any kind of information (comment / question / attachment) in its’ context. That could be a comment in a Google doc, or a question in a Trello card or Jira issue or similar. This way, people can have everything related to the task in one place, can focus on following only that and even refer to the previous comments (even if they were added long time ago). It also helps when somebody new needs to join the same task / activity: they can easily read through and catch up.
In addition, use the user mentions where applicable, so that people give priority to the comments that mention their name (most of the tools will arrange this as a notification of a sort), and will feel free to read later if none of the comments called for them.
In order to achieve async, the team members should be able to work on their task independently. Apart from having the required skills, they’d need the task requirements. And some really good ones for that matter, so that they are not getting blocked by waiting for the others to discuss details. In order to prepare quality requirements / specifications, I like using the dual track flow, where the coming iteration is getting specified while the current one is getting implemented (I create custom workflows in Jira, Trello or similar). In this way, we have enough time to do it slowly (which means people do not have to respond to the questions immediately) and make sure that all the questions are answered and everything is clear and well covered, prior to starting the actual implementation. I’ve seen many teams simply agreeing on what generally needs to be done, and leaving it to the discussion during the implementation. What happens then is that the number of blocking questions hits the roof, the work becomes super inefficient, and the team members feel obliged to be online at the same time to avoid blocking their team mates.
I had a few occasions where I’d join an existing team which was having calls (and I mean long calls) on almost daily basis. When I say that I work with 1 biweekly call only, usually they think it won’t be possible. So I introduce the above mentioned techniques, and start eliminating the calls gradually, so that people don’t feel anxious and lost, and soon it becomes clear that we don’t need all these calls any more. Everybody is on the same page, the tasks are clear, the progress is transparent, the blockers are few, and if any, we know how to report them and react to them.
As much as it’s important to review the product (the result of the team work) after each iteration, it’s extremely crucial to look in the retrospective at the way the team work was happening. This simple format (asking each team member to share where they see the space for improvement, and also what they think went really well and we should keep on doing) actually does work. It can be anything, like putting the comments in a more clear format, leaving more time for certain activity, correcting common understanding of the workflow and similar. It takes a bit for people to relax and realise that it’s not about picking on anybody’s mistake, but rather talking about the team as a whole and finding ways to improve our work processes. I always make sure to actually introduce the changes agreed upon, so that it doesn’t feel as it was just a formality to hold this session.
Design your way of work, and put it in a nice and concise KickOff doc, which you will keep updating with useful findings from the retrospectives. This document helps the existing team members embrace the changes, but it’s also of an immense assistance to the newly onboarded ones. They will get there faster without feeling blocked by waiting for somebody to help them. In addition, this way you will protect the existing team members from too many interruptions and questions to be answered.
Async collaboration is truly precious for the future of work, with multiple time zones, often multiple projects and teams (as freelancers), varied workloads over time and similar. In order to work efficiently and avoid blockers by waiting for responses, we need to be able to work asynchronously. And on top of that, as a win win, we achieve another goal, of at least the same importance: healthier lifestyle for everybody. In the days of digital noise, we need to highly value the times when we can turn off our digital notifications and focus on the life happening around us.