Technical managers of remote and semi-remote teams need to ensure that their people have all of the tools they need to communicate efficiently and effectively in several different contexts. If you've followed the modern pop-culture advice on hiring people with free and open source software development experience, you may assume you have everything handled.
Yet without discipline and effort on everyone's part, people will fall back on familiar patterns of communication even when there are better ways. When you understand the different contexts of what communication should happen for what purpose, you can multiply your effectiveness.
The insight that multiple communication contexts exist comes from the word of Patrick Lencioni, specifically his book Death by Meeting.
Tools for Individual Development
The context: individuals contribute to the development of software, whether as developers, technical managers, project managers, QA experts, support associates, system administrators, etc. To some extent, this advice applies to many creative industries, though an attorney preparing a memo for a client may not use a source code management system such as Git to solicit and apply feedback.
For developers steeped in collaborative, distributed development systems, nothing in this list should be especially new. It's more important to understand how each tool contributes to the whole, however.
Laptop
Each individual needs a laptop. This is especially important for remote workers, as they may be expected to travel for work. To the degree this can be managed and administered centrally—not by individuals—you remove a source of frustration and tension and a big source of friction. In other words, you can assume everyone has the appropriate applications installed, configured, and licensed if you assert some degree of central management.
Also you can enforce whole-disk encryption, so if that laptop accidentally gets left in an airport for a couple of hours before being retrieved you have fewer worries about important data being accessed inappropriately.
Shared Access to Shared Services
Because an individual may be working from a beach in Hawai'i one day to debug an urgent issue discovered during his only holiday of the year, and because you can't trust public wifi, everyone needs secure access to shared systems such as your source code repository, deployment machines, and other important apps and services.
While a physical secure token for your VPN may make you feel like a secret agent for a while, at least until your cat knocks it off your desk and under a chair, soft tokens and two-factor authentication systems using smartphones and other devices are often more convenient.
Individual Communication Tools
Every individual team member needs the ability to communicate with other indivuals in a one-on-one format. Sometimes this is a one-on-one . Other times, it's the virtual equivalent of catching someone in the hallway for a chat.
Be careful not to underestimate the value of these ad hoc conversations. They're great for getting quick answers in a high-bandwidth medium and they're also incredibly important for building team cohesion. Shared work areas are controversial for introverts and people who like to work without distractions, but at the same time being able to overhear other people working on something interesting gives you a lot of options and lot more information about your work as a whole.
It's easy to overestimate the value of email; it's all too easy to get caught up in a chain of forwarded emails with a dozen people eventually added to the distribution. Email is valuable for long-form written communication and it's filterable and searchable and archivable, but it's asynchronous.
Textual email can be effective as a broadcast medium to spread information and it's an effective fallback medium when you don't otherwise share a higher-bandwidth communication medium, but it's one of the least effective ways for a group to discuss something quickly.
You're already using email. It's available on your laptop, your phone, your tablet, everywhere you need it. You likely already have security and retention and access policies in place. Keep yourself ready to switch to other media when appropriate.
Remember as well that an effective IT department can create unlimited email addresses and mailing lists. The possibilities here are endless, especially when it comes to notifications, reports, or any alert emails set via automation. Collaboration also includes collaboration with systems, not only people.
Instant Messaging
Email is asynchronous text. Instant messages can be synchronous text. This works great for quick notes and questions, such as "Running late, but start the meeting without me" or "Please send me that document we talked about". Again, you probably already have this.
Your IM history is more difficult to search, and it may not be available quite as many places as your email is. Worse, the world has no single simple standard for IMs, and not all IMs support groups or mailing lists the way email does. Yet for a quick one-to-one update, IMs are handy and you need them.
Voice and Video Chat
You have telephones, of some form or another. Voice chat is synchronous, high bandwidth, and direct. Add video chat and you have the next best thing to colocated discussion. Yes, you need to work out details such as bandwidth and fidelity, but for the same reason you'd pop into a team member's office to chat for a couple of minutes, you can dial him or her on video chat regardless of location.
Keep in mind that even relatively low quality video can give you some degree of body language and communication tools that aren't present on the phone.
You will need sufficient infrastructure and computing power and hardware to make pervasive video chat work for you. It's worth it.
Tools for Pairing and Mobbing
A group of developers working on a shared project needs the ability to work together for hours on end as if they all sat around a table in the conference room collaborating shoulder to shoulder. Sometimes this is pair programming. Other times, with more people, it's mob programming.
Traditional pair programming puts two people side by side in front of a single computer. One person types (driving tactical decisions) while the other person plans (navigating strategic decisions). This strategy can be invaluable while walking through new code, chasing down a bug, or exploring a problem space.
For pairing or mobbing to work with a remote team, you need the to see the same code and to talk to each other. This suggests either a secure connection to the same machine and terminal-based programming tools (often Vim or Emacs). For this to work, you need some sort of secure network connection everyone can use together, not to mention the familiarity and comfort with the same tool and similar configurations.
Another approach is to use remote desktop software or voice/video chat tools which support screen sharing. The higher bandwidth requirements of video sharing may add a barrier to active pair programming, though the author has had great success with SSH, Vim, tmux, and Google Hangouts, with careful use of SSH keys, login accounts, and a network proxy.
Your team will make its preferences known.
Team Communication Tools
The context: a team of creative people focused collectively on one or more projects must communicate among itself. The important questions concern what the team must accomplish, the status of that work, and the processes which govern that work.
An Issue Tracker
Everyone needs to know the current work to be done and the current state of that work. This is worth an article in itself, but the summary is this: it should be simple for you to answer the question "What should I work on next?"
This system can be almost anything, as long as it's accessible to every stakeholder and supports at least the minimum of linking to other documentation and resources. In other words, you have to be able to take screenshots of bugs and link to third-party API documentation.
It's helpful if you can create and track multiple projects, manage custom workflows, and report on various criteria.
An On-Call Alerting and Monitoring System
If your work includes things such as monitoring servers, detecting security breaches, and serving customers outside of business hours, you need a mechanism by which you can have someone on-call to triage problems and coordinate solutions. In the olden days, this used to be a pager that system administrators carried. These days, you can find several software-as-a-service companies who will send text alerts when a system looks questionable.
The value in a system like comes from two places: first, automatic notification and escalation. A single pager may get lost, run out of power, or go ignored. In contrast, a whole team may cover for each other.
Second, a really good system will allow manual creation of notifications. In the case where one person on project X notices a critical problem with project Y but doesn't know how to raise it, using the alerting system will route the problem to the correct person, assuming it's been configured properly.
Yes, that is an ideal case, but now that you know that scenario may be valuable, it's up to you to configure it properly.
A Shared Document Repository
Any good team has a lot of projects and process in progress. You need to manage on-call schedules, deployment rules, project planning documentation, business forms, lists of services and servers, and other vital information.
If your group is solely developers, you may be able to store most of this in a source code repository. The moment you have other people who don't work primarily with the repo all day, there's value in even a simple wiki which supports file uploads. Besides that, your financially-minded people will prefer spreadsheets in a native spreadsheet form to CSVs with PRs.
Depending on how much access third parties need, you may need to support a system with access controls‐or separate systems entirely.
Google Docs works pretty well here. It's not a substitute for a good wiki, but it's a good system for sharing documents, spreadsheets, and presentations in a collaborative form with effective access controls. You'll need to manage the sharing capabilities and processes with a tool like this.
A Calendar
A calendar may seem like an individual tool, but it's a communication mechanism for the team as a whole in its own right. As a simple example, consider how a team tracks who is on-call for the week or who is on PTO.
A good calendar system will let everyone share part or all of their calendars with everyone. A great system will allow groups or pseudo-entities such as conference rooms or teams to have individual appointments or reservations.
A good calendar system will allow detailed views of scheduled events, such as a description and other salient details. A great calendar system will include links to agendas, supporting documents, locations, and deep integration with your video chat system.
A good calendar system will let you set up recurring events. A great calendar system will make it easy to schedule ad hoc meetings as necessary. It's up to you to make your calendar process work for you—but a great tool far outclasses a good tool.
A Group Chat System
Teams need to chat as teams. Sometimes this happens in meetings, where high-bandwidth communication and synchronicity helps communicate and decide quickly. Other times, a perpetual and searchable record of asynchronous communications has more value.
You and your team have to decide what process needs you have and how each of these communication tool types work for your processes.
A good group chat system supports multiple channels. These may reflect organizational groups, projects, specific technical and non-technical interests, and cross-cutting concerns. This implies you need also to support chat clients which make it easy to manage these groups, and a great chat system allows clients on many devices (laptop, phone, mobile, web).
A good chat system supports persistent channel archives. A great chat system will not expose these archives and logs outside of your organization—you need solid access controls which reflect personnel changes as well as some ability to host and scrub logs yourself.
A good chat system supports integration beyond chat: the ability to host file logs, snippets of code, photos, and other documents enhances text chat. Even though the ability to type a single sentence "Everyone please stop deploying RIGHT NOW; there's a site outage!" is the quickest and easiest way to broadcast, an architectural diagram or 10 lines of code can clarify in a way chat doesn't.
Managing the expectation of a chat system is important; the decorum and practices of individual channels and teams will vary with team members and their preferred working styles. You can set the expectation that people are generally paying attention to the chat system during core working hours, though managing process around individual, private notifications can take some work.
This system may be integrated with your IM system, which allows for nice synchronicity. Supporting private chats is valuable, but beware of the most popular or senior people in your organization sharing information in private chats that would be better in public chats.
The real value of this chat system is that it can provide a public record of important information. A strong organization will curate this information and promote it to a well-organized permanent archive—but if the chat logs are searchable, you still get many of the benefits.
A Presentation System
For presentations such as quarterly meetings, internal training, and demos, a system which allows a one-to-many presentation is valuable. An ideal system lets you share audio and video, including sharing computer screens—not just slide decks but the actual device screens for software demos.
This software may be part of a video chat suite on its own; the important feature is a presentation mode, where one person can speak and everyone else is muted (pending access controls). It's too difficult to present your quarterly strategy slides to a couple of dozen people when one has a dog snoring in the background and another has road construction outside.
Group Video Chat
You probably already have this if you have individual video chat. The same guidelines apply, though the ability to mute everyone but the speaker and the process by which people can signal their desire to talk require some teamwork. Again, the information bandwidth of video is worth the cost of communication bandwidth. Audio only conferences can work, but you need much stronger process to manage them effectively.
Be aware that IM and group chat can and will be used as a sidechannel for these meetings. Embrace that.
A Travel Budget
None of these tools have the information bandwidth of a face to face meeting. Whenever possible (annually at least, but quarterly can be helpful for certain teams), arrange a few days of colocation.
Ad Hoc Backups
The context: no matter what systems or processes you have in place, you will eventually be glad to have fallback mechanisms in place. When something goes wrong, the ability to text someone's phone directly can save you valuable minutes or hours.
This principle applies beyond emergency contact information. As an underappreciated benefit of a separate presentation and group chat mechanism, you can perform maintenance on one while organizing everyone involved with the other. Even having a well-understood conference call mechanism as a low-bandwith communication medium may come in handy.
For your team members to trust you to give you emergency backup contact information for spouses, partners, roommates, family, etc, you must have cultivated a healthy working relationship with all of these other communication tools.
You must be careful collecting private communication channel information such as phone numbers and personal email addresses, but if you're very cautious and diligent about the lines between work and life and what constitutes a real emergency, you can maintain a list of alternate contact methods to alert someone to get on your company's grid.
Sometimes phone is all you have. Sometimes email is all you have. Sometimes pinging someone on Twitter can mean the difference between a few minutes of an outage versus days. People who care about each other and the team—people who want the team as a whole to succeed—will do their best in this situation, especially if they have all the tools they need.