Asynchronous work and remote teams
If anyone is remote...
It is our contention that they are the same thing, because if anyone is remote, you need to act like a distributed team. As everybody has learned in 2020, if they didn't already know, everyone could be remote and part of a distributed team. So the question becomes: how?
Don't replicate the office. Don't strive for synchrony. Those are two different paradigms. Instead, focus on good communication.
Asynchronous communication channels
Running your company through private communication channels excludes people, their experience, smarts, and knowledge. This is true in an office and it is true online. Communication should be public and permanent by default. Make things public and searchable, and let people respond in their own time. If you get the communication right, a lot falls into place.
To start with, stop expecting immediate responses. Make that expectation common, role model it, and lead it. State out loud: "oh, I do not expect to reply to this until later. I'm time shifting my work right now. I don't expect a reply until sometime in your workday". Secondly, when things are public by default, and permanent by default, it allows everybody else to catch up in their own time, and be part of the conversation.
Policy by Pull Request
Have you seen those companies with their handbooks on GitHub? Literally their company's procedures and policies are in text files on a public website. It is a brilliant idea. You don't have to do it publicly, and you don't have to use a software version control system, but think about what this gives you: your discussions are public, there is a way to have a conversation about a change to a document, and the decisions are transparent. Anybody can go back and review the background to the policy. It is searchable. If GitHub is where everybody does their work, everyone can feel encouraged to contribute. Obviously, as your company includes people who are not just working in GitHub, that can change. The tool itself doesn't matter. It is the concept of open collaboration, where discussions are public, discussions are transparent, and everyone is encouraged to contribute.
Regular retrospectives
If you are not looking at what you have been doing, then how do you know what you can improve? Regular retrospectives help us in this regard. When conducting retrospectives, you need to concentrate on the problems, not the people. Addressing the issues early is better than addressing them later. You need to keep the conversations transparent. "You" here means: you the team, you the company. You are not going to be able to do this by yourself. Hence the need for retrospectives. Other people will raise things that you hadn't identified or had thought were relatively insignificant. They will help you understand that these issues are significant, and need to be addressed.
Remote pairing
Pretty sure people have worked this out in 2020 but let's quickly review. There are products that allow you to control each other's computers, type together, actually do pair programming, and other related work in close proximity. An example of a couple of tools we have used are: tmux using tmate or Tuple Some IDEs have screen sharing functionality. Or you can use whichever video chat that offers screen sharing. However, pairing doesn't necessarily have to be over a video conference. For those who do not write code, you can use the collaborative tools in various online document editing suites, which allow you to do real-time work together.
Documentation
I write down all the things I did wrong so someone else doesn't have to
It should not be up to somebody else to point out the mistakes that I made. They should be self-evident, but they should be documented so that we can all learn from them. And so that people understand that I recognise it was the wrong decision, the wrong call. If you never acknowledged that, then people go: "Oh, well, apparently this here is acceptable". Having a defined process in place is good, but not heavy process. When you have a process, light as it might be, it still needs to be documented so that you have a central source of truth.
Everyone should write their own documentation. Don't assign it all to Jess. It is part of the work and everyone does the work. If everyone does some improvements, each time they use a document, it is small task and the documentation stays up to date. It will not be getting in the way of you doing your work. It is part of your work!
Internal blogging is amazing
It enabled knowledge sharing in perpetuity because it is searchable. Use GitHub, a wiki, Notion, Slite, or any other tool. The tool does not matter for the purpose. Just do it where people do their work. Same place as the documentation, same place as the policies and procedures. There are so many ways you can do it. You can ask everybody to post "Today I Learned" most days of the week. You can write up case studies (they might take a little longer). Weekly project reports can be mostly generated with a blurb at the start to provide some additional context.
Personal stuff
The personal stuff is what a lot of people fear. And it is definitely hard. It can, in some ways be harder than the office, because you have to keep track of your people, and you have to know are they okay? Are they productive? Are they communicative?
One-on-ones are your greatest asset, but you should also pay attention in meetings. Is someone talking more than usual or are they talking less than usual? Do they not show up? Is their video off? Which is not to say you can't have your video off, but has their pattern changed? Are they behaving differently? It is worth checking. It is worth asking questions when patterns change.
Create opportunities for interactions
You can also create other opportunities for interaction, to people feel connected, and help people feel part of the same experience and process. Demo sessions are quite common. People love a good demo session. Friday afternoon or fortnightly, show off what you did this week for the rest of the company to see.
You can also organise social sessions. You can book in a session for everybody to have a chat, and just kick back and talk about things. Buy everyone lunch! We have a client who is now regularly buys lunch for every employee and whomever they live with. So that those people will also join the lunch, and you get to meet people's family, friends, or roommates.
In these social catchups, you can rotate and pair off a couple of the tables as it were, to have more intimate chats for a few minutes before going back into the big chat for everybody. It is a lovely way to connect and meet people. Having the people there who are not employees changes the context of the conversation, and lets everybody enjoy it more.
You can organise a randomised catch-up roulette. There are tools that allow you to put in the list of people, and pair them up based on their work hours and their work days. So that now, they have an excuse and a justification to catch up, and spend some time together, and get to know each other in a social situation.
Key points
- You already are a distributed team. Make sure you act like one.
- Asynchronous work is about communication.
- Rituals help. So try some!