About the Foundation for Public Code

Tips on communication in a remote first environment

This resource


  1. Questioning video-call as default
  2. ‘Closing the loop’ on open-ended requests

As we aim to work remote-first, and a lot of our work with codebase communities happens remotely, here are some tips on communication in a remote-first environment.

Questioning video-call as default

This is definitely down to individual preferences, but video calls may be more taxing on the eyes and require more points to pay attention to.

Some people on the team found that when having 1-on-1 check-in calls or chats, doing it over a phone call while walking around outside worked just as well (or better) and was less tiring. 

‘Closing the loop’ on open-ended requests

We identified a potentially harmful pattern around open requests not being ‘closed’. 

So for example, someone sends an open ended request for input or help or review, but doesn’t hear back from anyone.

This can be demotivating for the initiator (feeling of shouting into the void, not being taken seriously, valued or respected, and feeling like doing meaningless work), expensive for the organisation (many people reading, thinking about it, closing, opening it later again, without coming to a conclusion), and lead to a cycle of the item resurfacing without resolution.

While this loop is easily closed in a co-located working environment (reach over and say hey), a remote environment makes this more tricky.

Several ways to mitigate this could include developing a culture around:

As an initiator:

  • Set a deadline for responses, and signal what you will do after that deadline (move ahead, or stop working on it if no other interest,…) 
  • Signal clearly if/when this is a blocker to your work that prevents you from moving on
  • Where possible, ask individuals for input over an undefined group 
  • Where possible, provide clear context, aims and expectations around the request

As a responder:

  • Don’t deprioritize with silence, but actively say you can’t/won’t prioritize something
  • When you take on an open request, try signaling whether it is something you will prioritize, or something you will only do if you have time and space