Quansight has been fortunate with the recent shift to working remotely; that is our normal mode of operation. This is due in part to our leadership’s heritage in open source software. For decades, open source software developers have been creating great software mostly working as volunteers in their spare time outside of normal working hours, often at home. In addition to our Founder, most of our staff have years of experience working in distributed teams on various open source projects.
Ultimately, the differences between working remotely versus working in the office are social; both in the social aspects of conducting business and in personal social issues. New tools, behaviors, and processes are needed to maintain both types of social interactions when shifting to remote working. I will discuss here some of the things we at Quansight were already doing that allowed us to easily transition to remote working exclusively, and some things we have implemented or expanded in response to the current situation.
One of the big challenges of working remotely is not having the ready channels of communication available in the office (notably chatting on a break, encountering someone in the hallway, or knocking on someone’s door). There are a host of text, voice, and video communications technologies available to replace in-person conversations and meetings. We use a variety of services to help people stay in touch such as Slack, Zoom, Jitsi, and Hangouts. We have often said to each other that “Slack is our office” and people typically check-in on Slack at least once a day. I won’t go into the details of text, voice, and video communications technologies and how they are used. Most companies are familiar with those options and there are plenty of resources available to learn about them.
Beyond the technological approaches for staying in touch and for conducting meetings via teleconference, there are subtle---but important---lessons to be learned about team management, decision making, and social interaction.
When managers are not co-located with their teams---especially when each team member works alone---the managers do not have regular visual feedback on the team’s activities and productivity. You don’t see who “comes in early” or “stays late” or “seems productive in their space” as you make “the rounds”. Each team member must be responsible for their own activities and deliverables. It is harder for managers to gauge progress. The focus for the manager shifts to deliverables and the mindset of their team. Making sure that team members have the right goals and priorities and that they are in a productive frame of mind. This, however, has always been how open-source teams collaborate.
Open-source collaborators have very few signals as to how much time contributors spent on a task or if their work on a line of code was interrupted by frequent snack or bathroom breaks. The time at which code or other contributions are submitted gets recorded, but exactly when the work happened is not. Open source has always been about asynchronous coordination, text discussion, and a focus on the result and not how it was achieved. Open-source teams are managed via a lot of text communication and documentation of work results. Other indirect signals that can be indicative of productivity are not essential to how open-source teams stay in sync.