Distributed teams: Better communication and engagement

As I have written before, I work on a very distributed team.

I always think that as a distributed team, we have to overcome friction to communicate. If we all worked in the same physical office, you could just walk over to someone’s desk and look at the same screen to debug a problem.  Instead, we have to talk in slack, irc, a video chat, email, or issue trackers.  When the discussion takes place in a public forum, some people hesitate to discuss the issue.  It’s sometimes difficult to admit you don’t know something, even if the team culture is welcoming and people are happy to answer questions.

Over the last month or so I’ve been facilitating the releng team meeting. We have one meeting a week, and the timeslot rotates so that one week it’s convenient for folks in Europe, the other time it’s convenient for those in Pacific timezones.  The people in Eastern timezones usually attend both since it overlaps our work days in both cases.  We have a shared document where we have discussion items and status updates.  As part of each person’s update on the work they are doing I asked them to add:

1) Shoutout to someone you’d like to thank for helping you this week, or someone who you’d like to recognize for doing great work that helped the team

2) Where you need help

One of the things about writing tooling for a large distributed system such as Mozilla’s build and release pipeline is that a lot of the time, things just work. There are many ongoing projects to make components of it more resilient or more scalable.  So it’s good to publicly acknowledge that they work they are doing is is appreciated, and not just in the case of heroic work to address an operational failure.

Sometimes it’s surprising what people are thankful for – you may think it’s something small but it makes a difference in people’s happiness.   For example, conducting code reviews quickly so people can move forward with landing their patches.  Other times, it’s a larger projects that get the shoutout.  For example, when we were getting ready for the Quantum release, Johan wrote a document about all the update scenarios we needed to implement so release management were on the same page as us.  Ben wrote some tests to test these update scenarios so we could ensure they were implemented in an automated fashion. Thanking people for their work feels great and improves team engagement.

Asking people to indicate where they stuck or need help normalizes asking for help as part of team culture. Whether you are new to the team or have been working on it for a long time, people see that it’s okay to describe where they are stuck understanding the root of a problem or how to implement a solution.  When you have all the team in a room, people can jump in with suggestions or point you to other people with the expertise to help.  Also, if you have too much work on your plate, someone who just finished a project may be able to jump in which allows the team to redistribute workload more effectively.

At Rail’s suggestion, some people started having regularly scheduled 1x1s with people who aren’t their manager.  I started having 1x1s with Nick, who lives in New Zealand.  Our work days don’t overlap for very long so we haven’t worked much together in the past.  This has been great as we got to know each other better and can share expertise.  I was in a course earlier this year where a colleague mentioned that a sign of a dysfunctional team is when everyone talks to the manager, but team members don’t talk to each other.  So regularly scheduled 1x1s with teammates are a fantastic way to get to know people better, and gain new skills.

We have been working on migrating our build and release pipeline to a new system. During this migration, Ben and Aki would often announce that they would be in a shared video conference room for a few hours in the afternoon, in case people needed help. This was another great way to reduce friction when people got stuck solving a problem.  We could just go and ask.  A lot of the time, the room was silent as people worked, but we could have a quick conversation.  Even if you knew the solution to a problem, it was useful to talk about your approach with other team members to ensure you were on the right path.

The final thing is that Mihai created a shared drive of team pictures.  I gave a presentation last week, and included many team pictures.  I really like to show the human side of teams, and nothing shows that better than pictures of people having fun together.  So it’s really awesome that we have an archive of team pictures that we can look at and use when showcase our work.

In summary, these are some things that have worked for our distributed team

1. Saying thanks to team members and asking for help in regularly scheduled team meetings.
2. Regularly scheduled 1x1s with teammates you want to get to know better or learn new skills from
3. Regularly scheduled video conferences for project teams to assist with debugging
4. Shared drive for team pictures

If you work on a distributed team, what strategies to you use to help your team communicate more effectively?

Further reading

• Julia Evans’ zine on How to be a wizard is excellent and has a fantastic section about asking questions
• Camille Fournier’s How do individual contributors get stuck?