Introducing async work in a product company

Recently I’ve reviewed the Gitlab article about the async culture of work and I believe that this is a very long, but good guide on how to deal with it. I can only say that everyone should read it to understand what is async work.

What is your experience with asynchronous work?

I thought that I will share my thoughts on this topic. I write here about my specific environment, but I believe that most of the things can be applied everywhere with some adjustments.

My environment

I work in a cross-continental environment, where the highest timezone difference is 9 hours. We all work on one product. We are split into cross-functional feature teams, and we have platform guilds. We try to have a feature team in one timezone, but platform guilds connect all developers that work on a specific platform. Synchronizing and developing a good platform is hard in that circumstances. Even harder is to learn people’s asynchronous work when they used to sync all the time. The shift of the mindset is a huge challenge.

Initial async rules

  1. Overcommunication is the king
  2. Enforce all communication on proper channels
  3. Ban most of the direct messages (limit it to them only when it’s really personal things)
  4. Enforce agenda for all meetings, no agenda = no meeting.
  5. Every meeting has its confluence page and note
  6. In addition to the above, also most of the syncs, standups can be written async before the meeting itself.
  7. Have a good rule that every day people will go through his tasks, messages, PR’s and answer people.
  8. Use the slack tools to convert messages into tasks.
  9. Leads enforce to care about the rules

Overcommunication is the king 

We can’t be afraid of repeating ourselves. Write as much as you can! Let’s bring all the topics to the crowd!
This is very hard to build that kind of team so maybe we need to find a different way of how to enforce that.
The other, not so obvious, the reason, why cooperation in feature teams is good, is that we have plannings and whole team ceremony.
It’s important because we plan our work to non-block each other. So where is the biggest problem? All the places where we need to cooperate outside of the feature teams like platform guilds or cross the domains. Platform guilds don’t have their autonomy, ceremony, strict laws.

Cut the meetings

One of the important things that are missed and which often have an opposition camp:

if you schedule a work-related meeting (e.g. not a coffee chat) it is required that you have an agenda

I see that in general people are afraid of writing, or believe that it takes too much time from them.
Maybe we should have a requirement for that?
No meetings without the agenda, no direct communication, only writing on the channel.
All meetings should have their place in the confluence, notes, and action points.
I don’t have to say, how easier it would be to find the answer if you don’t need to ask directly about something.
Do you need the answer? Look at the confluence, maybe there was some meeting about it, look on the slack, maybe someone wrote about it.

How we can enforce better async communication?

Of course, the first idea is to document all the things (discussions, meetings). The second idea is to give people time to respond to messages. For example, everyone could have two spots per day to review slack discussions, review PR’s, etc. Outside of that spots, we can mute all notifications.
There is a great slack tool to create tasks from the slack message! Three dots by the message -> Remind me about this in… Later you can find all your “tasks”(messages) in a slackbot communication. Another idea is to delegate leads who will be responsible for moderating these discussions and enforcing “laws”.
Tech Leads would be responsible for moderating platform discussions (and of course, they should be responsible for enforcing platform development in a common way). There could be also Domain Leads who are naturally would be Product Managers of the specific feature teams. They could have a similar role but in the case of the moderating domain discussions. Every team member should be able to work as a bridge between business and platform. In async work, we should avoid anything that would block anyone from exchanging knowledge. Especially, we should hire proper people.

Async Skills

Great quote from the Async Remote book about the async teams:

Async teams are great, but require some special skills – overcommunication, proactiveness, trust (always assume the best intentions), selling skills, good writing.

Last, but not least – this thread is pure gold that answers why async work is something that we all need:

Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.