My answer is based on personal experience from both sides of a fence, working as a remote worker, and as the manager of a remote worker.
In the end I do believe most of these rules are what matter for local offices as well, as emphasized by the first comment to your question above. But, as you realized youself, it is indeed harder to control in a distributed environment.
Direct Communication
Just like you can talk to co-workers at the office, you should be able to talk to remote-workers.
The most common settings I see include to have at least:
- e-mail,
- IM (usually Skype)
- voice calls / phones (via VoIP/Skype or others)
- teleconference and screen sharing (via WebEx, Skype, others...)
These are great for most purposes, but in my opinion, they all stick lack that element where you can just get up your chair in an open-space or an office and wave at someone on the other side of the aisle or through a glass wall and request their attention to ask a 3 minute questions. E-mails, while near instantaneous, are easily muted (and that's a good thing), and most IM software like Skype are too 1-to-1 by design, or limited in numbers.
So my favored recommendation is actually a good old IRC server, though usually corporate IT departments do not like these, for security reasons. IRC is neat because you can:
- simulate a room full of people,
- people can isolate for private 1-to-n conversations,
- people can follow multiple conversations,
- conversations can be recorded,
- other media channels can be plugged into this easily (integration build alerts, etc...)
- users can give an indication of their status, like on most IM, but while still being passive listeners of conversation (you can do this with Skype Chat Rooms, but again it doesn't feel quite right).
A possible downside of IRC and IM in general is that, as it's a "silent" communication channel, people in a quiet period (or slacking...) will use it to talk without giving too much notice to their administrators or managers. One way to mitigate this is to block the possibility to create chatrooms, or have the opened chatrooms publicly listed so you can know if people are actively talking somewhere (you just don't know about what, though your company might give you superuser rights on that to monitor everything, but you wouldn't want to be that nosy): just like you would in an office where people can be seen sharing a room, but where you can't eavesdrop. But as you can see them, you can also feel free to ping them and ask "what's taking so long?" if they seem to abuse it to chat. And obviously, you (or your lead) being connected to the main channel will refrain day-long chatter and banter (but do not mind too much the occasional ramblings and relaxation periods, they're just the same as coffee or cigarette breaks).
When IRC is not an option, you could actually resort to Jabber clients, which are fairly extensible for your own needs and not tied to a particular network or provider.
Time-Tracking?
Time-tracking is not easy, does not reflect productivity and cannot be used (except maybe for freelancers) to keep track of your employees involvement BUT it can still be an indicator of a problem, and some workers will actually welcome it as a way to monitor their own habits. My IT school used to have a custom IM agent on all machines, that would jumpstart at the start of each user session. It was very lightweight, so even users usually annoyed by forced pre-installed IT monitoring stuff would end-up not minding it, and the thing could be muted, used to chat with other users on the network, to check their status but also their location in a building, and would submit usage data so you'd get reports on daily connection times and duration AND actual activity periods (usually triggered by user input on the keyboard or mouse with a permission period to allow them not to feel cheated if reading documentation or other quiet research activities).
Of course, this does not account to everything (they'd appear present but inactive if they were still logged in but tied up in a meeting somewhere else), but it's a nice to have that acts both as a convenience tool and a safeguard, as long as you introduce it the right way and do not make it an annoying spyware.
And the good thing is, pretty much all of this is supported by the Jabber protocol and its implementations... provided you have someone to take care of setting this all up.
Time-Tracking with Your Issue Tracker
Get your developers into the habit of hitting the "start progress" / "stop progress" buttons, if you issue tracker supports such a feature, instead of just opening/closing tickets. They could easily hit "start" and go for a drink, but in the general case they won't.
Schedule Regular Team Meetings
Remote workers obviously are not exempted of attending meetings, provided they have the necessary suppoerting IT infrastructure (which you should provide them, otherwise you're shooting yourself in the foot).
In the genearl case, a development team should at the very least meet once a week. I'd advocate that this is raised to twice a week for remote teams.
If it's only a few elements of your team that are remote workers, then you need to a more personal chats with them at least once a week. In the case of personal chats, I'd encourage that you always have another developer on the call, and that this developer be preferably either the team lead or a senior developer. This is to protect both parties. It protects the developers, as they sometimes might (consciously or not) accept tasks or requirements from you during the these personal chats, and eventually somewhere down the line you might argue about who said what and the developer will end up feeling cheated if it ends up as a "but I implemented this based on what you said on Monday 27, remember?" kind of situation.
And it protects you exactly the other way around and also by giving additional technical support directly on the line. Of course, the 3rd party should know a bit about what the remote developer works on, if possible.
And encourage your developers to take meeting notes, even if you will take them down yourself.
If you do stand-up meetings, obviously have the remote worker be on the call as well.
Pair Programming Works Remotely as Well
Try to have the remote worker always working with at least another developer on his tasks, and never solo. If your development team is used to pair programming, this should be very natural, even if the dynamics obviously are different, as they don't litteraly use only one workstation and might work in parallel. But they'll be used to look over each other's shoulder, and that's what matters. If your team was NOT used to pair programming, it might be hard to get started, principally because you'll need to realize that 2 developers working on the same task does not necessarily mean twice as much money spent, or a task completed in 50% of the time, or time wasted that could be used on another task.
So, just dive in a always distribute your teams so that at least 1 person (either local or also remote) always works with your remote worker. Developers are a lot less enclined to slack off if they know that another developer is looking at their code, waiting on them to finish something, or likely to report them. It sounds harsh, but it's also a very motivational group dynamic, and usually makes the whole development fun.
However, do occasionally rotate the teams, as you don't want them to buddy up to the point of spending time arguing about details (or football games) too much, and end up in a double-slacking-lock where they protect each other's back.
Additionally, have the pair-ed programmer also join the weekly chat up.
Code Reviews
This is the natural follow-up to pair programming, and is especially important if you don't do the pair-programming bit. You need to review code, for the same reasons. It's not only about code quality, it's also about giving a driver for (remote) workers as they know that some of their peers will look at their code. All programmers are naturally judgmental - the point that it's important to find some who can learn to be detached about it and not focus on details and accept to see the positive things in what they consider "imperfect" code - and so they know very well how their code is going to be seen by their fellow programmers.
Some Things NOT to DO
We's seen the DOs above, but there are a few DON'Ts as well.
DO NOT constantly bug or even ping your remote worker.
When you're in a local office, it's annoying to have physical people come to tap you over the shoulder and ask about one thing or another. It gets you out of your concentration zone. So in general you'd prefer people to wait a bit, or just send a more discrete request via IM or email, which can be ignored or won't totally stop the receiver in their tracks.
However, for your remote-worker, IM and phone calls become prevalent and quickly replace the physical element. So, try to not be the annoying boss that pings every 2hours to know what happens. It's fine to do with relatively new hires or on tricky projects, but slowly increase the intervals at which you check up, and trust your employee. See next point.
DO NOT make you remote worker feel like you don't trust him.
There's nothing more demotivational than having a boss nagging you without justification, and even with justification it won't help much to get the remote worker back on track. They know you won't trust them, as you know they might slack off. It's part of life, and no different that in a local office.
DO NOT complain too much about slight delays.
A common problem with remote workers is that the local team members often feel they are waiting for them on conference calls, for instance. So it's tempting to tell the remote workers to be there ahead of time, or not late. But do realize that in the case of the remote workers, they don't someone to grab them out of their current task and tell them "it's time to go", so they can be there within 10 seconds of leaving their chair. They need to get out of their task and dial in using whatever service and codes you may use. Sure, they should know that, set their own timers and get into the professional habit of being early themselves. But we all have times where we are sucked into something, and this is slightly harder to control. Feel free to mention it in a personal meeting, but DO NOT complain about it (virtually) in front of the team, or they'll feel cornered.
DO NOT nag remote workers for not responding instantly.
They may just be away from keyboard for the usual valid reasons (bathroom, lunch, coffee break), and though it raises suspicion from afar they're probably following a rather normal pattern. Also do not mind the occasionally extended AFK status, as, unfortunately, remote workers need to deal with the unforeseen drawbacks of their own environment, which you don't control. If they work in a remote office, they may have their own share of "normal" problems to deal with (IT issues, customers barging in, mail employees showing up, etc...). If they work from home, then, whether you like it or not, and not considering distractions that would actually be real slacking, they might have to attend to some home-related tasks: mail-man, kid falling from a chair, partner burning something in the kitchen, etc... No matter how much they try to isolate themselves (and believe me, remote workers will try to isolate and confine themselves as much as they can to work in peace), you cannot just say NO / LEAVE ME ALONE to people around you the way you can when they ring you at the office. It's a lot harder, and also if you're just right there and can help with something under 5-10 minutes, you will, and will catch up later and do the additional time when you can. It REALLY isn't fun for them, so don't make it look like it's too much of a problem for you.
In fact, DO NOT treat them that differently. The ones who will slack remotely are the ones who would have a tendency to slack locally as well. The environment is more prone to slacking and it can be difficult (and depressing) for remote workers to stay at the top of their game, but if they weren't the kind to shy away from work when they worked locally, then they shouldn't be too much of a worry for you remotely. However, that implies you've "tested" them locally first, and preferably before they knew they'd work remotely, which is hardly ever the case. But you can get feedback from past employers and co-workers on their working ethic to limit this.