I have a company (about 6 programmers, and 14 workers in total). As I am going to expand my company, I am thinking about hiring remote workers for programming jobs and get them to be involved in the main development.

But one thing that I have problem with is that, how can I make sure my remoter workers are not slacking off while everyone else is busy working? I know it is not good to measure employees performance in terms of the time he spends in an office. But psychologically it is pretty hard-- for the employers-- to see that the employees are not reachable during the working hours ( if in the same timezone). This, couples with the fact that the programmers are the one who provide estimates, makes me fear that my would-be remote employees would cheat on me.

Maybe it's just that I need to trust them and it's just my thinking that needs to be changed, but, before this, is there anyway to make sure that your remote workers are not slacking off?

  • 30
    In your current situation, what do you have in place to ensure that your local workers are not slacking off?
    – jcmeloni
    Commented Jun 12, 2012 at 10:25
  • 33
    I have know local workers who can slack off right under the bosses nose. Commented Jun 12, 2012 at 10:29
  • 49
    @mhoran_psprep stackoverflow is full of people slacking of Commented Jun 12, 2012 at 14:13
  • 33
    I'm slacking off this very second Commented Jun 12, 2012 at 15:34
  • 13
    @Graviton So... in your mind you believe one must be controlled constantly, everybody is a child, and no one likes his job? Depressing. Not especially depressing, as most establishments actually roll this way, but sort-of-average depressing.
    – ZJR
    Commented Jun 12, 2012 at 23:59

14 Answers 14


If you, personally, are not able to keep an eye on estimates and make sure they don't get ridiculous, you probably need at least one person that you do trust who can confirm. Beyond that, it's just a case of "if the work keeps rolling in, I'm happy." It is my experience that the programmers who are most productive are those who are most trusted and have the most autonomy.

If you really cannot trust anyone, you can keep an eye on source control commits or push a policy that people must be available on chat during work hours. That's not too onerous or asking too much of people but, if someone really wants to slack off, then they will find a way, even if they're right under your nose all day.

Your two best defences against that are

  • Learn to hire trustworthy people
  • Be a great person to work for, make them want to work for your success

These two rules apply whether they're working in an office with you or working 4000 miles away.

  • 10
    If you, personally, are not able to keep an eye on estimates and make sure they don't get ridiculous, you probably need at least one person that you do trust who can confirm. God forbid ANYBODY hire a local software developer anymore... Commented Jun 12, 2012 at 10:55
  • 5
    This question has as much to do with "hiring local developers", as keeping employees that telecommute busy. Remote employees don't always have to be outsourced contractors. Commented Jun 12, 2012 at 18:58
  • 10
    +1 This answer cuts right to the chase. In my group, we have 6 developers, 3 local and 3 remote. The local workers work from home an average of 2-3 times per week. I do not worry one single bit about their productivity, because of the communication methods we have in place (daily standups, team chat, good ticket system) and the processes as well. They've all easily earned trust, and do a great job. Never a single issue.
    – jcmeloni
    Commented Jun 13, 2012 at 11:56
  • 1
    @BrendonDugan I disagree that monitoring source control commits is a reflection of productivity. It doesn't take into account the time spent in at least the following activities - training, documenting, designing, discussing, any kind of planning activity, local team meetings, collaborating with other teams/emailing etc. Instead I feel a daily report would give you better clues about how productive they were.
    – Mugen
    Commented Aug 10, 2013 at 16:31
  • 3
    @Mugen: To some extent, I agree with you. It certainly can't be as simple as "you've committed only once this week, so you're fired." But a half-competent manager can look at source-code commits and see if the amount of work being done is what he would expect, having taken into account all the things you mention. That's not to say you can't also have a daily report, but that could be a pack of lies, without something solid to back it up.
    – pdr
    Commented Aug 11, 2013 at 21:29

I've been remote for several well-known companies since 1999 and another stint in the early 90's. I've been both an individual contributor and a manager. Take it for what it's worth...

I define myself as a remote as "an individual working from home or a rented office". This is opposed to an off-site or off-shore development team where all employees are located together. I'm mostly talking about myself as an individual remote, but I'll get to the other in a bit.

Communication is the what makes the relationship work. If you will have some overlap in time zones, make use of it. Use IM between the local manager and the remote. They should have a good rapport and be comfortable chatting at any time for any purpose.

Newsflash: I'm not sitting at my desk every day from 8 to 5. Get used to it. I will take my kids to a doctor appointment when my wife can't. I've been known to go to the golf course on a nice Wednesday when there are no meetings. In return, you'll find me online on Saturday night while watching a ball game on TV and most evenings after the kids are asleep. When it's time to ship the product, I'm up until 2AM testing corner cases. What matters is not the hours, but the progress and the results. If there is no progress and no results, then your action should be obvious.

If you are naturally suspicious and will always be wondering if your remotes are screwing around on you, it's not going to work. Your suspicions will rub off on local employees and they will assume your attitude toward the remotes. Your remote workers will resent you for heavy-handed attempts to micro-manage them and the results will not be what you want. You are hiring someone who is representing themselves as a professional, so give them the chance to prove it. If they can't, cut them loose.

As for off-site teams, I've not had much experience with India or China, other than in parallel organizations. I have managed a team in Brazil the last 4 years from my home office in the Central US. In the North American summer, the difference between me and the team is 2 hours. In the NA winter, it's 4 hours. I get most of a day with my team with just a little effort on my part. My team leads and I are in constant contact via gTalk and we hop on a VOIP bridge or use GoToMeeting when we need a wider channel. I've been very happy with the results and the bonus is yearly trips to Brazil.

Between me and my boss on the west coast, the method is repeated. It wasn't uncommon for the daily chat log between us to have several hundred lines. When I recently got a new director with different priorities, the lack of communication up the ladder was disorienting.

Finally, off-site or remote doesn't necesarily imply "less cost". Even if the guy in Madison costs less than the guy in Sunnyvale, there are times when having them in the same room makes sense. Budget travel into the total cost of every remote. Either bringing them to you or sending your managers to them.


It's the hardest lesson in management but you really will have to focus on results.

If people need to be available for production issues or for emergency consults, that needs to be part of their contract.

It's key to remember that "being busy" and producing quality work are much less true for information workers that it used to be. An inexperienced young programmer may work 12 hours straight produces an amazing date widget. An experienced programmer used a pre-built one and does it in 10 mins.

If you are also relying on their estimates then I would try and run them by your existing folks in the office to check if roughly ok. Make sure that if you plan on keeping everyone you have, that they know that. Also let them know they they should now also be operating at a higher level for this review of the contractors code. Reward them finally title-wise or otherwise for this.

If instant availability ismore important than high quality work, make that clear. Just don't expect many interruptions a day to produce high quality work. Many workers spend hours getting in the zone, sometimes at very wacky hours.

Spend your time, emphasis and focus on selecting the remote workers/organization and on the end user results they produce rather than managing the process along the way. Use Agile development to make small measurable goals that will let you know that things are progressing. Use daily scrums and additional set meetings (even if only set a couple of hours ahead) to help people schedule them in and adjust their schedule and practices.

You may also gain some useful tips from:
How to convince employees that IM and Facebook during work is unethical?


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 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.

  • best reply imho!!!!
    – wpb
    Commented Oct 29, 2013 at 9:10

I've worked with all kinds of remote workers the last few years. What I have noticed is that good remote workers keep in contact. You don't have to bug them for progress reports, you don't email or IM them and never hear back. Your projects don't go into a dark black hole and hopefully come out OK at the end (But maybe not).

So in managing remote workers, to me the first thing to do is set clear expectations about contact. If you have core hours that they must be available, make that clear; make it clear how soon you expect a response to an email or IM.

The next thing you want is good solid source control and policies concerning how often work is uploaded to source control. Remote workers, particularly those out of town, should be uploading their changes to a branch (not necessarily the main branch) at a minimum of every day. If you aren't seeing any code changes frequently, then it is time to have a chat with them.

One reason why this is critical even on a long term large project is that sometimes people get sick or take emergency leave due to a death in family, etc and you need their latest work to get the job assigned to someone else during their unplanned absence. Someone who works in the office, it is easy to go get the code off their machine if they haven't checked it in, with remote people, you really need the frequent check-ins.

Next make sure you set a up a way to video conference and share documents etc in a web conference and put money in the budget to bring remote workers into the office for a couple of days every year. People do work better with people they see and know in person.

Code reviews are something that should be a requirement for everyone. Using your web and video conferencing, you should have regular code reviews with remote people and have them code review the work of in-house people. If someone is on a longer project and you are feeling uncomfortable about the progress due to what is being said or not said in the regular progress reports, schedule an interim code review for the next day. This will often make the person who is slacking realize that they aren't getting away with it and progress will suddenly be made.

If your remote workers are in drasitcally differnt time zones, you may have to allow extra time in project plannig for the delays that will inevitably occur becasue they need something from you (a clarification for a requirement, access to a particular database, etc.) and you aren't available to provide it.

Remote workers also need good solid requirements to work from. When you give them a new project requirement, talk to them about it and make sure you have covered any intial questions.

Treat everyone as part of the team. Remote workers often get forgetten when it comes to awards and things that we do for in-house people. For instance we frequently have bagels in the morning at our office, the remote folks don't get that. So if you do that sort of thing for those in the office, periodically send the remote people a gift card for Panera's or somesuch so that they feel they are part of the group. We also expect remote workers to be at team meetings and company meetings. It's hard to get a word in edgewise when you are the remote voice on the phone in a meeting, so it is up to the in-house people to remember to ask them what they think especially if the topic is somewhat controversial or when you are discussing things like overall architecture. Plus they are more likely to pay attention if they know they will be asked questions.

YOu have to make more of an effort to provide feedback to remote workers too. It's easy to say good job on XYZ project to the guy you are passing in the hallway. It takes more of aneffort to remeber to passfeedback on to remote workers. And don't be the person they hear from only when you are unhappy. Make sure to pass on praise as well as criticism.

Like any worker, you want to hire the best you can. For remote workers, someone who has a track record of working remotely might be a big plus (especially if they have refernces who can verify that it went well), but don't eliminate great potential employees just because they haven't. Ask why they want to work from home. Ask them how they envision working with your team while they work from home. This should give you a good idea of the way they like to work. If you interview someone who likes to take a project and then give it back to you only when it is is done and who doesn't want to be "bothered" with IMs, email, questions or prorgress reports, run away.

  • +1 "good remote workers keep in contact" -- it's true. With good remote workers, you often have to "manage" less!
    – jcmeloni
    Commented Jun 13, 2012 at 11:57

Here's a few more:

Pursue a group estimation process

Agile development offers a few options - everyone holding up an index card with the estimate for a task. Or agreed by consensus "T shirt sizing" with general estimates on what S, M, L, XL tasks are.

The big deal is that since Agile development assumes that most people can do most tasks with relatively equal ease, the group's opinion is a good estimate of what anyone would take to do something.

Keep notes

I always find this to be the hard part - knowing when a task got picked up by someone for work and when it was finished. This is the thing that you want to keep a good handle on -for everyone, not just remote folks - but keep an eye out for remote vs. local patterns.


For any team, communication is as much a part of the job as the actual work. The biggest thing I see is that remote workers are communicated with differently - left out of the loop, not given access to all streams of information - because people forget to tell them, or invite them to meetings.

It varies remarkably given how a company communicates - groups that ardently use IM, for example, seem to do better than those that yell over cube walls. Also , management sets a tone - management who themselves do some remote work and show HOW to do it often end up with staff that does it more successfully.

But you want to keep an eye out and ask sensible questions - did we tell the remote guys what's up? were they on time and attentive at meetings? Do we have a way of knowing what their intented hours are and when they are online (vs. stepping out for lunch or a meeting)? Is there response time when answering a question acceptable to the team?

This stuff can be harder to measure, but it's an important part of going remote.

  • The group estimation process is a good idea. I was going to suggest getting competing bids from remote employees. If you think something is a 6 day project and someone else sees a way to do it in 4, give it to the lowest bidder! This doesn't mean you have to hold them to the 4 hours, but you could even use a per-employee bid accuracy multiplier to figure out how long it will really take (Average, over time).
    – Bill K
    Commented Jun 12, 2012 at 16:22
  • When starting a project we use the index card game to figure the first rough estimates. That works pretty well. We also use the Fogbugz estimation functionality, which takes in estimates and over time tries figure how to correct each user's estimates based on actual time required. It will provide an estimated scheduled based on this information. Managers have to take this estimate with a grain of salt, but it is at least somewhat quantitative. Commented Jun 12, 2012 at 17:07
  • 1
    @BillK - You can either have estimates be as accurate as people can make them, or you can turn them political by things like bidding. If you don't care about accuracy and just want to push people into low bids so they can prove they are really working remotely, maybe bidding will work.
    – psr
    Commented Jun 12, 2012 at 22:54

Set reasonable deadlines for work to be completed but be firm about people (both on and off site) meeting those deadlines.

You should keep a regular and fairly frequent check on these deadlines. Don't say "Here's a piece of work come back in 6 weeks when it's finished". Have daily conversations where you can ask them what they did yesterday and what they intend to do today. You can use this meeting in two ways:

  1. As a check that they are doing what they say.
  2. As a way of guiding them to do the things you want them to do.

It doesn't have to be a long conversation, just 10 minutes or so over Skype (or the equivalent).

You can also hold less frequent, longer meetings/conversations to keep the remote developers up to speed with the wider picture of where you see the development going etc.

You should use the same approach with your local workers - except for having the conversation face-to-face rather than on Skype.

Unless you have someone you trust at the remote location you have to trust the remote workers to do their jobs.

  • Setting deadlines is often difficult, mainly because often work is difficult to estimate in advance. But daily communication is definitely a good idea.
    – sleske
    Commented Jun 13, 2012 at 9:47
  • @sleske - true. But the setting of deadlines should be a discussion rather than an edict anyway.
    – ChrisF
    Commented Jun 13, 2012 at 9:49
  • Yes, if you see the deadlines as means of tracking progress, and not as an absolute requirement, then I agree.
    – sleske
    Commented Jun 13, 2012 at 9:52
  • @sleske - there will be an element of both. A game (for example) must be ready by September to be in the shops for Christmas so that's a hard deadline, but the deadlines for the individual tasks can be more flexible (to a point).
    – ChrisF
    Commented Jun 13, 2012 at 9:54
  • True, external deadlines must be taken into account. As long as no one forgets that scope should also be adjustable, that should be doable.
    – sleske
    Commented Jun 13, 2012 at 9:55

If the only way you can tell if workers are slacking off is by watching them work then you have a bigger problem.

Use source control and look at what they check in (also do this with local employees). If they are contributing indirectly (helping other programmers, whatever), you should be able to find out about that too (again, also for local employees). There is no reason to evaluate remote employees any differently than local ones.

Finally, estimate or find out how many hours they've actually worked. Write that on a piece of paper, rip it up, and burn the pieces in a fire. It has nothing to do with anything.

Judge your employees on how much they contribute, not when or where they do the contributing. (Obviously, I'm not talking about completing tasks on time, which clearly matters. I'm talking about whether they work 9-5. And if they are taking other people's time or getting less done because you can't reach them easily, that certainly should count in evaluating their contribution.)

If it makes you feel any better, I personally get more done working remotely, except for tasks that are very communication intensive where face to face works better. Part of why I'm more effective is that I can do certain non-work chores during the day when things are less crowded if I need to, and that efficiency gives a bigger pool of hours to split between work and everything else.

Also, not having to look busy helps - I can, for example, lie down and close my eyes and think about what I'm doing without worrying my boss will come in and wonder if I was sleeping. Finally, I can often break a work day up into a few shorter shifts interspersed with non-work stuff (usually totaling the same or more hours than I would have had at work), which keeps me fresher than one giant block of working (or, if I'm on a roll I can just keep going).

In short, I think for people who don't slack off there are productivity advantages in not having to as tightly adapt whatever schedule is most efficient for them to whatever schedule their office happens to have.

So, all you can do without causing more problems than you solve is to see how your remote workers handle it and judge all your employees based on effectiveness, not effort.


Everyone needs to understand the time they need to be available. Working remotely does not automatically mean you have flex-time. If others rely on you being available when they are, remote workers need to be in a position to take a call, email, IM, etc.

You can't expect a remote worker to stay up all night finishing a project only to have them punished because they didn't answer an email first thing the next morning.

Don't assume the people in the office will be jealous of home workers and always think they are slacking off. I work remotely and my boss indicated there is no way he could do it because he has young children at home and couldn't manage the distractions.

Too many companies manage by exception, chaos, and every task is considered a fire that must be put out immediately. Interuptions are a killer to knowledge workers, so you need to realize that projects will take longer if programmers are on call.


The remote working works the best when the worker is paid by work done not by hour.

However, with non-remote workers you can easily verify that they are sitting at the desk, but not, how concentrated they are on their work. They may for the half of the time stare at the screen and think about holidays... So, in each case, you can verify, how much work they have done.

Take into account, how much have the remote worker done, and how much [s]he is paid for it. If you're satisfied by this relation, you shouldn't be afraid someone is cheating you, because you got what you expected for the salary you've paid.


My shop has several remote workers. We don't have any written rules about it, but the expectations in general are:

1) The remote worker will be reachable by Skype or phone during a normal work day. In our shop, each employee gets to define what his or her normal workday is. For all of us, remote or local, if we are going to be out of pocket during our normal times we are expected to let our team know as soon as possible.

2) We have frequent scrums. Everyone on a project, remote or local, is expected to attend, or to provide a reason why they can't.

3) We use Fogbugz, which includes an estimator and 'working on now' functionality.

4) At each scrum each team member tells the team what they are working now, what might be blocking them, and when they estimate they will finish the current task.

Essentially, we just treat the remotes in an identical way to the locals. The project leaders are expected to track progress. Some people work faster than others, but I haven't seen any correlation between remote and locals in that respect.

Our teams are built on trust, and as a company we operate on an adult to adult level.

If you team is used to a parent-child style of management then using remotes might not work for you.


Ask them to tell you what they are working on and got done, every day.

This can become annoying, but there are tools that automate this with the minimum hassle for everyone involved, like Dutyful.

It sends a mail to everyone in the team asking what they got done, they just have to reply in a few lines directly from their mail client. The next morning, you get a digest with everything that got done.

You can configure it so the digest will be sent to the whole team instead of only you. We have found this works even better in increasing motivation. There is no better way to shame a slacker than for her/him to see all the rest are busting their assess while he/she is not.

All that info is stored so you can keep them accountable on what they said.


Remote working, especially for knowledge workers, should be treated no differently than working in the office.

You assign work to the employee and you give them deadlines for when said work should be done.

As long as they are doing the work you ask and doing it in the timeframe and to the quality you expect everything is fine. If they don't, well then you fix the situation just like you would with any other employee and kick them to the curb.


To make sure your remote workers are not slacking off, don't try to look at what they're doing at a specific moment in time. Since you can't really see if remote workers are "in their seats", here's how you measure this:

  1. Look at whether their output commensurate to what they cost you.
  2. Look at whether they are reasonably productive compared to other programmers in your company.
  3. Look at whether they are able to take up additional tasks, i.e. what resources are available to you should you need them.

Wondering if people are “slacking off” or (implicitly) demanding they look busy is not very productive; instead, just stick to looking at results.

  • 1
    This doesn't even attempt to address the main question being asked.
    – enderland
    Commented Mar 14, 2014 at 19:41
  • @enderland I think it does attempt to address the problems that can arise in this situation. Now, as I explained at the end, if the objective is in fact asserting power and having people look busy for the benefit of their boss's feelings, then of course it's not helpful.
    – Relaxed
    Commented Mar 14, 2014 at 23:04
  • I suspect the main problem is how you've worded this and your lack of objectivity, like it's somehow shocking that a manager would want to somehow measure the effectiveness of a remote worker. Maybe you can reword this a bit. Imagine you're a consultant hired by the asker to solve this problem. How would you word this if your paycheck and reputation as a consultant depended on it?
    – jmort253
    Commented Mar 15, 2014 at 0:56
  • 1
    Hey Annoyed, I made some edits on your behalf to get the ball rolling, to give this a more objective tone, and to make it clear that what you're really doing here is providing a solution. Please feel free to edit further to put in your own words. Hope this helps!
    – jmort253
    Commented Mar 15, 2014 at 1:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .