For a number of reasons at a number of times in my career, I’ve found myself working with variously-distributed teams of one kind or another. Perhaps the “office” is a building that spans 2 square miles, perhaps someone was working from home for a day or someone was on a 2 week “vacation”, or even working for a distributed company with no real office. These were all different situations, but they all suffered from simliar challenges. I want to take a look at a couple of those challenges and some ways that you can help mitigate them.

I’m looking at this mostly as a member of a technical team of some sort, but I’m sure a lot of it would apply to pretty much anyone who’s not working face-to-face with their colleagues. Apologies in advance for this being kind of rambling (and very long). It’s a collection of all sorts of observations, links and ideas that I’ve collected over time.

Communication Deficiencies

This is first for a reason. Number one in frequency and potential to cause damage are all manner of communication deficiencies. This is one of those things that is just as true for cube-workers as it is for distributed teams. Communicate or die. Here are a couple of guidelines to help you all communicate:

• Get a wiki and use it at least for more “permanent” documentation like company policies/rules etc.
• Ideally, use your wiki for specifications, project requirements etc – you get a revision history and a neat, centralized document that everyone can check up on.
• You could also put a page on the wiki (or somewhere) for each person in the company, so that new hires can “get to know everyone” by reading a bit about each person.
• Consider setting up an internal blog (perhaps Prologue, Yammer or Present.ly even) or mailing list for announcements etc that everyone in the company needs to know about (email isn’t great for this, because it gets lost in amongst everything else)
• Don’t CC: everyone on everything. It’s annoying, often irrelevant, and it leads to “boy who cried wolf” syndrome where people start ignoring emails they should be paying attention to.
• Get everyone on IM and make sure that you’re all comfortable talking to each other. This doesn’t mean that the sysadmin needs to be IMing the CEO of the company telling them about their weekend, just that normal “communication lines” within the hierarchy of the company should be open online as well.
• Consider using video chat as way to do some synchronous communication when the situation calls for it (but don’t overdo it).
• Use email when it makes sense.
• If it’s an emergency, it does NOT make sense to use email – call.
• Get Skype (or something similar) and use it when it makes sense.
• Always keep your language as simple as possible (whether you’re interacting with someone with the same native language or not). e.g. (bad) “I’m of the opinion that without the conversion of these resources to the requested format within a limited period, the ramifications for the project deadline would be negative”. How about (good) “We will not meet the project deadline if the resources aren’t converted to <format> by <date>”
• Be succinct yet descriptive with all communications – you’re just wasting everyone’s time if everything requires confirmation/discussion.
• Consider setting up a group IRC channel or something similar which you can use for group discussions. Log it and make the logs available and searchable to everyone in the company.

Task Management/Allocation

Knowing and managing what everyone is working on is hard enough when you’re all in the same office, but when you’re spread out across the country or across the globe, it gets even harder. You need to keep track of what people are working on now, what they are aware of that they should be working on next, what’s been allocated to who, etc etc etc. This one largely comes down to communication again (doesn’t it all?) but there are some unique challenges here (don’t think you can just solve this with a lot of email, it doesn’t scale). Here are some tips:

• You’ll want a centralized system of some sort for this so that you can all “go” to the same place to see what’s going on.
• Being able to allocate/assign tasks is important so that you can see who’s responsible for something.
• It’s good for everyone to be able to look at everyone else’s list, so for example I can see if someone else has a huge list, then there’s no point allocating them additional work. Or I can see that someone has nothing on their list so either they’re not using the system, or there are other questions to be answered!
• Transparency is a good thing – pick a system that keeps track of who changed what, when. Especially changing the assignment of tasks.
• There’s a balancing act to be played between privacy and control as far as who can edit what, who can allocate tasks etc, but personally I think companies should strive to have an open enough culture that you can remove these sorts of barriers and allow people to use their own judgment.
• It’s good to be able to attach/associate files with tasks, but be careful about revision control on those documents (especially if you’re all used to relying on a different system for everything else).
• Email integration is important, even if it’s just notifications when things change. It will help bring people back to the system and keep using it, since email really is the “nerve-center” of most people’s online business world.
• Something like BaseCamp might be handy here, or you can use a bug-tracking system like Trac, a new player like FlySpray or Lighthouse or any of a number of other options. Some companies choose to roll their own to suit their needs which works as well.

Version/Revision Control and Race Conditions

The minute you have more than one person working on any kind of file (Word Document, source code, images, anything) the question will arise: “is this the latest copy of this file?” This is not a question that you want to answer with “no”, especially when you’ve already saved it, uploaded it to your live server and lost all track of any previous changes. A race condition is when 2 people edit the same file at the same time, and then try to store it back in a central location (e.g. networked drives). In addition to race conditions, what happens when you need to see previous versions of a file for some reason? You made changes that are going to be reverted, you made changes that are plain wrong? There are some different common solutions to different parts of this problem, for example:

• Google Docs attempts to solve the problem by providing a single “master” copy of documents, which everyone edits in the same location, at the same time. This means that you don’t take a copy of your document and then go and edit it, you actually edit the live, master copy, every time. In addition to removing potential race conditions, GDocs also stores revisions of your documents over time so you can get old copies if you need to.
• Subversion, Git, CVS, SourceSafe and a bunch of other traditional “source code versioning systems” are designed specifically for working with source code (for programmers) and other pure-text based documents, but they can also usually handle other file-types. There are differences between the options, but in general you get a “working copy” of a document of some sort, and can manually update it based on a centralized master copy. If there are clashes between changes you and someone else has made, then you can “merge” the changes into a single new document (then put that back as the master copy). Most of these systems allow you to install them on your own server, or there are also hosted options like Beanstalk and GitHub.
• Wikis will maintain previous revisions of each document (one of their most valuable features), so you can always see what people have changed over time and how a document has evolved.
• Ideally, all documents would be under some sort of version control, with little to no user intervention/interaction required. Google Docs does a decent job of this for “Office” style documents. Wikis handle it automatically for anything that’s created within them, while SVN/Git etc all require users to be involved, but for good reason (you don’t want your source code doing things that might result in breaking on its own).

Timezones

Although there are some benefits to having people in different timezones, there are also some real problems when you’ve got people you’re trying to interact with spread all over the place (and awake/asleep at different times).

Benefits:

• Global customer support: depending on which people you have in different timezones, it may allow you to provide support to your users for more hours of the day
• 24/7 progress: perhaps not completely 24/7, but if the timezones mesh up, then you can potentially set a task as you’re leaving at the end of the day, and come back to work the next day with the completed task in your inbox.
• Localized contacts/markets if your staff are actively engaging with people in their real world surroundings as well.

Challenges:

• Lack of synchronous communication: if you’re all on different timezones, it’s often difficult to get everyone online at the same time to discuss something. This means you either a) communicate very clearly and descriptively what you’re trying to do, or b) spend a lot of time going back and forth clarifying things before anything gets done.
• Delays: generally stemming from communication problems, you can easily find yourself waiting days at a time to get something seemingly simple done because of the back and forth resulting from people requiring extra information/authority etc.
• Potential for additional costs due to requiring multiple office locations (unless people are working from their own locations, in which case this becomes a benefit because you can save on having an office at all).

Wrap-Up

I’m really interested in these topics in part because they’ve directly affected me and my work, and in part because I know they affect so many other people. There are no doubt still plenty of opportunities to provide tools and systems to help groups work together from disparate locations and timezones, so I’m interested to see/hear more about what’s going on in this space. Do you know of any other tools which are particularly handy for distributed teams? Please add them in the comments. What other elements of the distributed office are specific pain-points for you?