OK, we've spent a lot of time talking about the implications of remote working, how about some practical advice?
Here are some bullet points that will aid in your construction of a remote-friendly infrastructure.
1) Make it available to all. Everyone the company, from the CEO down, should be able to avail themselves of this option should you make it available. If you do it on a case-by-case basis you'll inevitably run into water cooler mutterings and it will implode once people complain that they can't do it too.
2) Make participation and continued employment very much based on results. Sure, you can work from home - however, if you don't get at least as much done from home as you did from the office, then the exercise is over. Working from home comes with responsibility to actually get stuff done.
3) Continuing on from point 2, make most of the measurement metrics for getting stuff done very public and understood, as well as the measurements you expect from people. It is not enough to tell them you are watching their Achievement and Objective emails, you need to tell them what you expect in those emails. If you don't check in for 3 weeks, employees will be asking why.
I say "most" because you don't want every
metric made apparent. Once an employee feels he has the measure of the metrics,
they are open to gaming. Some hidden metrics - analysis of the check-in
frequency or some such - will be necessary to catch those who are gaming your
system. And that will happen, by the way. Mark McCubbin, who has been a remote
contractor working in the games industry for over 11 years has this to say:
"One thing always difficult is measuring performance of offsite developers, not that in reality they are much different that those bodies sitting in the office warming the seats, however, it's the nature of the beast that being out of sight, there will be some suspicion on hours invested in a given task, and certainly for programmers it rather difficult to control exactly where their time goes. There are two things that have helped smooth this side of things immensely in the past; one is person-to-person video conferencing, even just once or twice a week, and focusing more on macro-goal-based tasking!"
4) Frequent and candid feedback from a manager. When working remotely, you do tend to work in a bit of a vacuum and it can feel very much like you have no idea whether you are doing a good job or not, unless you get lots of feedback. A quarterly review and a weekly virtual meeting with your manager is the least that will be required.
5) Give people what they need to get the job done - don't skimp on buying them a PC and a dev kit for use at home, and pay for things like internet connection and cell phones. Give them no excuse to not be working.
6) Agree on core hours and have some method whereby everyone has to be virtually present for those core hours - AIM, ICQ, IRC, Skype, whatever. You have to be visibly online and available for discussion when you are supposed to be, and there need to be consequences if you aren't (beyond the obvious like physical meetings or bathroom breaks or lunch).
Whatever communications methodology you settle on, it has to have voice and, if possible, some desktop / grease board sharing mechanism (more on this later). The core hour concept can get a bit tricky when it comes to real time zone differences, but generally people who are working remotely do tend to want it to work, so they'll deal with them fairly well.
7) Do your due diligence in both task planning and in technical documentation. Just like in traditional development you need to understand what and how you are going to do it, only this is even more required for remote development.
The individual doing the work needs as much back ground on the task he is going to do because chances are he's not going to spend as much time talking to other people about it as he would if he was onsite, regardless of the good intentions everyone has about "staying in communication". The reality is that the individual is going to make a lot more decisions in a vacuum than you really want, so having as much background as they can is necessary so at least the decisions are as good as they can be.
8) In terms of project task management, tasks that are undertaken by those remotely need to be as stand alone as possible - dependence on other people who are remote is harder to mange (it's possible though) so if there are obvious floating tasks, remote people get those first.
9) Despite point 8, the reality is that some tasks (particularly the building of new systems - for example, a streaming system) will be beyond the scope of one person to design and implement themselves. Obviously collaboration is required.
Realistically, while some of it can be done virtually (using the aforementioned communication systems) some of it will be better off done while in physical proximity to each other - at least at the design stage.
Having a central location where people can come and mingle is a necessity for successful remote working. It's just going to be necessary for people to physically meet for many reasons, if only to get the measure of the people they are working with.
As anyone who's been on a discussion forum knows, a foible of human
nature is that if you get an ambiguous message (one that could be intended
negatively or positively) from someone you don't know, the natural urge is to
take it as a negative and respond in kind. However, if you know that person and have met them and understand how they conduct
themselves, it's much easier to understand what the intent was in the first
Having static physical contact at some point is both desirable and necessary. How often you do communal get-togethers depends on your requirements and ability to absorb the costs of the travel for everyone. At the very least, it needs to happen at least twice a year