So we wrote one. The following document has been through more than 80 revisions and contains text contributed by 5 separate authors, and also reflects the comments of even more participants. We hope you find a generic telecommuting policy useful.
Telecommuting Policy
Some organizations want to offer telecommuting as an amenity for work/life balance. Other organizations do not want to have to rely on local talent to build exceptional teams. Other organizations want to use telecommuting to reduce the cost of infrastructure such as office space.
Regardless of the reason, any organization wishing to succeed with telecommuting must have a policy for handling remote working. An institutional standard must be in place such that everyone telecommuting or interacting with remote workers has had a similar experience using similar tools to accomplish similar work. This is such a policy.
Any team member who wishes will be allowed to telecommute if: the whole team agrees to monitor and be responsive on all of the communication channels required by the organization for telecommuting teams. Team members doing solo or pairing work must keep the rest of the team apprised of their status, and should not be incommunicado for long periods of time.
Telecommuters who are not responsive on all of the required communication channels will be questioned and may be subject to having their telecommute privileges revoked or other disciplinary action.
Here we describe how to implement this simple policy.
For Telecommuting Beginners
As stated above, an effective telecommuting culture makes constant use of a set of communication channels. As a first step to implement this mode of working, an organization with little experience with telecommuting can have an expert supply compelling, collaborative training sessions, presented using teleworking technologies. These high-value training sessions provide a focus as the organization implements these policies and procedures for the first time, or consolidates such procedures already in place, and supplies incentive for everyone attending to participate and contribute. Although everyone will attend the training via the communication channels, interacting with the trainer, the material, and one another electronically as though they were telecommuting, training may take place locally and some or all attendees may be co-located. This enables smooth technical support and a controlled experience, affording natural opportunities for feedback on the policy.
Prepare the Team and Prepare the Environment
We strongly recommend that the organization put an IRC (Internet Relay Chat) server in place and have everyone in the organization know how to use it. The authors do not know of another messaging service that provides even a fraction of the features available in IRC. We recommend an institutional channel like "#social" for casual messages like "how was your weekend", as well as institutional channels for groups that collaborate closely, for instance "#dev" or "#my_team".
Before the remote training session begins, the following equipment must be in place for every member of the team:
- A working headset
- A VNC server and client for desktop sharing (1)
- A working instance of Skype, or other VOIP service that provides conference-calling ability (2)
Agree to Participate
Every member of the team must agree to participate in all of the communication channels required by remote workers. During business hours, every member of the team must be monitoring at least the following channels and be prepared to answer on them quickly when appropriate:
- instant messaging such as Yahoo IM, AIM, or similar service
- VOIP/Skype
- yahoo IM video (3)
- wiki (4)
- IRC in both #social and #
We consider these channels to be a minimum standard for telecommuting. Telecommuters require high bandwidth communication channels to be effective. If they are disconnected from the ongoing work of others on the team, the lack of critical information will make them unable to contribute; the risk of wasted work is far higher than for those on co-located teams. Having a required set of standard institutional communication channels mitigates the risk of wasting the work of telecommuters.
Other communication channels like a microblogging service, IRC interfaces to Twitter or Facebook, or other such communication channels may also be appropriate. The authors are aware of at least one organization experimenting with virtual worlds like Second Life for distributed teams.
Ongoing Remote Working
Telecommuting Policy
The organization must have a telecommuting policy to refer to once the training sessions are finished. Since we have built an institutional standard, where all of the telecommuters who participated in the training have had a similar experience, using similar tools to accomplish similar work, we can now put such a policy in place.
Upon finishing any required training, any team member who wishes will be allowed to telecommute at will under the same requirements that were agreed to when working in the training session: the whole team must agree to monitor and be responsive on all of the communication channels required by the organization. Team members doing solo or pairing work must keep the rest of the team apprised of their status, and should not be incommunicado for long periods of time.
It should be understood that telecommuters who are not responsive on all of the channels mentioned above will be questioned and may be subject to having their telecommute privileges revoked or other disciplinary action.
During the training experience, we assume that some workers were on-site, interacting with the trainer (and with each other) using the channels described above. When such workers are remote themselves, there may be a need to have on-site workers available on their office phone extensions. The open source PBX project "asterisk" supplies VOIP connections to office phone extensions, as do a number of commercial phone applications such as Avaya.
Meetings
Meetings should be structured such that remote employees can participate on an equal basis with those on-site. On-site meeting rooms must be equipped with adequate speakerphones. A multi-user IRC or IM 'back channel' where both on-site and remote participants may comment on the ongoing discussion in the meeting increases meeting bandwidth and makes it much easier for telecommuters to raise interruptions.
Travel
Travel requires a careful balancing act. Face-to-face time allows coworkers to connect on a human level and can be incredibly productive and beneficial. However, full-time telecommuters are telecommuting for a reason, and mandatory travel that inflicts hardship upon them harms the company in equal measure. Have a clear travel policy for telecommuting workers.
Appendix: Tools
(1) Desktop sharing is required, both for pair-programming and for demonstration of issues with software. Employees should be able to screen-share spontaneously, without the need to schedule a slot in advance. Tools such as Microsoft LiveMeeting or Webex or YuuGuu may substitute for the open source VNC. When working in a *nix environment, screen(1) is more productive than VNC for collaborating in a text-only environment. Examples of when to use screen(1) are, for instance, when using Vim or when doing system administration from the command line.
(2) The open source 'asterisk' project provides a professional-level PBX with multiple conference-call and office numbers available. Proprietary tools such as Avaya or other systems may provide the same sorts of features. What is required is the ability to have a group of people speaking together without echo, distortion, or other interference. Employees should be able to hold impromptu conference calls without the need to book a conference extension in advance.
(3) Some people find video screens of individuals unnecessary if those individuals are available on other channels. For remote workers interacting with an on-site team, having a camera in the team room is valuable so the remote workers can see who are at their desk, or engaged in conversation, or otherwise disposed.
(4) Teams need to manage significant amounts of project documentation and other text. Storing documents on network drives and sharing documents by email is far too low-bandwidth for remote workers to negotiate effectively. As well, these media do not allow for effective multi-user collaboration, nor do they provide an easily accessible revision history for documents, nor do they provide a single authoritative place to access a given document. A full-featured wiki like Confluence, Socialtext, Mediawiki, or Twiki is required for the access to constantly changing information that remote workers need. In our experience, Microsoft SharePoint has shown to be subpar for this purpose.