As MoodleNet Lead, I’m part of a remote team. If you look at the org chart, I’m nominally the manager of the other three members of my team, but it doesn’t feel like that (at least to me). We’re all working on our areas of expertise and mine happens to be strategy, making sure the team’s OK, and interfacing with the rest of the organisation.
I’m always looking to get better at what I do, so a ‘crash course’ for managing remote teams by Andreas Klinger piqued my interest. There’s a lot of overlap with John O’Duinn’s book on distributed teams, especially in his emphasis of the difference between various types of remote working:
There is a bunch of different setups people call “remote teams”.
- Satellite teams
- 2 or more teams are in different offices.
- Remote employees
- most of the team is in an office, but a few single employees are remote
- Fully distributed teams
- everybody is remote
- Remote first teams
- which are “basically” fully distributed
- but have a non-critical-mass office
- they focus on remote-friendly communication
When i speak of remote teams, i mean fully distributed teams and, if done right, remote-first teams. I consider all the other one’s hybrid setups.
Using these terms, the Open Badges team at Mozilla was ‘Remote first’, and when I joined Moodle I was a ‘Remote employee’, and now the MoodleNet team is ‘Fully distributed’.
Some things are easier when you work remotely, and some things are harder. One thing that’s definitely more difficult is running effective meetings:
Everybody loves meetings… right? But especially for remote teams, they are expensive, take effort and are – frankly – exhausting.
If you are 5 people, remote team:
- You need to announce meetings upfront
- You need to take notes b/c not everyone needs to join
- Be on time
- Have a meeting agenda
- Make sure it’s not overtime
- Communicate further related information in slack
And this is not only about meetings. Meetings are just a straightforward example here. It’s true for any aspect of communication or teamwork. Remote teams need 5x the process.
I’m a big believer in working openly and documenting all the things. It saves hassle, it makes community contributions easier, and it builds trust. When everything’s out in the open, there’s nowhere to hide.
Working remotely is difficult because you have to be emotionally mature to do it effectively. You’re dealing with people who aren’t physically co-present, meaning you have to over-communicate intention, provide empathy at a distance, and not over-react by reading something into a communication that wasn’t intended. This takes time and practice.
Ideally, as remote team lead, you want what Laura Thomson at Mozilla calls Minimum Viable Bureaucracy, meaning that you don’t just get your ducks in a row, you have self-organising ducks. As Klinger points out:
In remote teams, you need to set up in a way people can be as autonomously as they need. Autonomously doesn’t mean “left alone” it means “be able to run alone” (when needed).
Think of people as “fast decision maker units” and team communication as “slow input/output”. Both are needed to function efficiently, but you want to avoid the slow part when it’s not essential.
At the basis of remote work is trust. There’s no way I can see what my colleagues are doing 99% of the time while they’re working on the same project as me. The same goes for me. Some people talk about having to ‘earn’ trust, but once you’ve taken someone through the hiring process, it’s better just to give them your trust until they act in a way which makes you question it.