Asynchronous Working
  • Author: Susan McNicholl
LinkedIn
Facebook
Twitter

Making asynchronous work

At close to 4 years old  BoatyardX has, for most of its short life, been a remote-first organisation.  Our clients and teams are distributed across the globe meaning that successful project delivery relies heavily on building remote team culture and work practices that support distributed teams.

I spent almost all of 2022 working with remote teams and clients in the US.

Remote team culture takes time to build

Even in person, developing team culture on new projects can be challenging.  When dealing with remote and distributed teams across time-zones this can be even more difficult.

Establishing team norms, personal preferences and ways of working should be a shared activity which at first can feel quite mechanical and forced.  One of the activities we used during the project kick off was a team values canvas where we collaboratively filled out and discussed topics such as our values, communication preferences and team norms.  I would definitely do this again, but in future revisiting this periodically with the team would be a useful addition.  This can also be shared with new joiners to help them onboard into the team culture and ways of working.

Finding time for more social activities can be challenging, especially when the team in Colombia are having their morning coffee it’s the end of the day for colleagues in Ireland.  When teams are under pressure and nerves are frayed there is a tendency to resent spending 30 minutes on a social activity but it’s probably still a good investment to do something “fun” or non-work related every month or so.

And finally, even with fully remote teams there is rarely any substitute for spending time together and this was hugely important to build stronger relationships and get to know the team better on a personal level. 
Here’s an article from a colleague of mine talking about a recent trip to Bogota.

Asynchronous working is a skill which is becoming increasingly important

I had worked on remote or distributed teams before but not with such a great time difference which presented new challenges.
The cycle time for getting input and feedback can be longer and should be accounted for while planning. If I need input from someone 6 hours or 8 hours ahead, my question or message must be clear so they can respond, and I can pick back up first thing the next day. If my question or request is poorly articulated and I do not get a clear response, I will be blocked until they are back online and will have effectively lost a day on that task. This works both ways and I’m sure there were plenty of times I was the blocker after I logged off in the evening!!
Getting used to low context communications and using technology to your advantage is essential. Whole books or articles have been written on this topic alone but my simplistic understanding of this is to provide sufficient written context so that the question or request can be answered in a single response with minimal clarification required. It places more responsibility on the requestor to formulate their request clearly. The added benefit of this when done in a public channel or via comment features is that there is full visibility and other team members can contribute to the conversation if they have something to add. However, if after five or more messages the query is still not resolved it may be better to have a call. Most of the tools we use in BoatyardX (Jira, Figma, Miro) all have comment features, and my advice would be to encourage the teams to use these liberally.
Finding the right flavour of asynchronous working for the team will not happen by accident and it’s a continuous conversation to figure out what’s working, what’s not and adapting quickly. What’s right for a newly formed team will be different to an established team and its worth revisiting the topic regularly as part of team meetings or retros.

Time together is limited and therefore valuable especially where teams have a short overlap in their working day

Teams need to be mindful of time zones when scheduling meetings.  At first it may feel efficient to try and pack short overlap window with meetings,  however this leaves no space for ad-hoc sessions which are especially important when trying to problem-solve or deal with issues.   

Meeting fatigue is real, especially recurring meetings that are very mechanical or routine.  To free up some time we trialed asynchronous standups on alternate days of the week.This meant that  the team shared their daily update in text form via Teams. This worked well and allowed anyone who missed the session to catch up with a quick summary in their own time.  As the needs of the project changed, we flipped back to daily calls, but it is something I would consider doing again. 

On a personal level, I struggled at times setting boundaries around my working day especially during busy periods. Finishing on time on a Friday was the one thing I was not willing to compromise so the lesson here is to be clear with your teams and have an open discussion about schedules and boundaries.

Susan McNicholl, Solution Architect Lead

Remain flexible and keep learning

here is no one size fits all and each team will need to flex, adapt and learn along the way. However, for me I think starting the conversation and having an open discussion with your teams is the first step.

One of the most useful learning resources I found was Gitlab’s Guide to all-remote but I would also recommend using other sources like articles and podcasts for inspiration.