Learning patterns/Communication as a fully remote, part-time team with different timezones

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
A learning pattern forteamwork
Communication as a fully remote, part-time team with different timezones
problemCommunication as a fully remote, part-time team with different timezones is difficult, and a problem that many low-budget teams might face. How do we work around this?
solutionA balance of asynchronous and real-time communication may be best.
created on17:40, 4 December 2019 (UTC)

What problem does this solve?[edit]

This learning pattern discusses the issues that a fully remote and part-time team may encounter with team communication, based on the experience of the Commons App team.

What is the solution?[edit]

As a fully remote, part-time team with different timezones, scheduling frequent real-time meetings can quickly become more detrimental than beneficial, because people may need to stay up at odd hours or interrupt other work to attend, and this places a burden on the team. On the other hand, purely asynchronous (text-based) communication can have the downside of making team members feel isolated from one another, and does not lend itself well to skill sharing or complex discussions.

We have found that a balance of both kinds of communication is ideal. Where the "correct balance" lies would depend entirely on the team, their preferences, and circumstances (such as how different the timezones are, whether the people involved have 9-5 jobs additionally, etc). Team leads should discuss this with their team, obtain input from everyone involved, and take into consideration personal limitations, rather than forcing a specific meeting schedule.

Choice of software for asynchronous communication[edit]

  • The Commons App team uses Zulip for text-based communication, which provides us with some useful features: topics, comprehensive search and history, and GitHub/Travis integration. It is also open source, which appeals to our FOSS ethos
  • We previously used Google Hangouts at the start, but that is very lacking in features for team communication compared to Zulip (although it is good for communication with users and other general public, e.g. GSoC applicants)
  • If you are an open source project, Zulip's paid "Cloud Standard" plan is free, you would just need to email them

Things to consider[edit]

  • We are a software development team - best practices may differ for other types of teams
  • Part-time vs full-time makes a huge difference - if someone is only available (paid) 4 hours a day, they will have a smaller range of available times compared to someone who is available for 8 hours a day
  • Clustered timezones (e.g. if everyone is in the US, just different parts of the US) would make it significantly easier to handle this issue

When to use[edit]

When you are a fully remote, part-time team with different timezones


See also[edit]

Related patterns[edit]

External links[edit]