I am a Web application developer who also is responsible for project managing some projects, I sometimes have to manage remote developers, who work for me under a contract basis. I feel that sometimes it is really difficult to manage. I am facing some strange situations. For example:

  • Once a developer didn't respond for two days while we had to deliver a project. (didn't attend calls or respond to emails )
  • Once a developer templated a CMS with static solution (this one had less expertise I think).
  • Once I asked a developer to complete search functionality, the next day he said done, but when I looked, it wasn't done. Upon asking I came to know that, he had done the search but not search result listing formatting :). (I guess he is unable to manage his time while working from home)

So does this mean that I don't have right people? Or there is a problem in project management that I need to cover? I understand that sometimes misunderstandings can happen, and therefore we need to communicate in writing using a tool like unfuddle or basecamp, but what we can do for instance in the above situations? The person who did has at least 2 years of experience as a developer.

So I actually want to know: where is the problem? I am a programmer and know that programmers understand these things, then what should I do in such cases?

  • 2
    It's good to be very explicit, but that's a two way street. I cannot imagine being on the developer-side of this and not making sure it is exactly what is asked for. Actually, I have been on the developer side of this situation, and frustrated that I could not get enough information from the project lead.
    – Jeremy
    Commented Aug 1, 2011 at 16:40
  • @jeremy Heiler: If you will be asked for implementing a search functionality then will you leave the search result and will think that your work is done? I suspects that my developer didn't have time for work due to some other reason so he did that. So in this situation what you suggest?
    – Hafiz
    Commented Aug 1, 2011 at 16:54
  • 4
    A very light way to do this is using Agile Zen (agilezen.com) and make sure you put in the high-level tasks in each user story. For example user story "Provide Search Functon for users" you would have "Search Form", "Search Queries", and "Search Results" tasks. Then as they mark those off you can track the percent progress easily and without much hassles as in other systems. And have them check in the code for each task via git or whatever version control they are using.
    – Turnkey
    Commented Aug 1, 2011 at 17:10
  • 1
    @Hafiz - If I thought my job was to provide the API/library that did the search and that someone else would handle displaying/formatting the results (and thought that was clear), then yes, I would. I recommend making sure your freelancers know exactly the tasks that they're supposed to complete. I also recommend checking out the book 4 Hour Workweek. There's a chapter in it that covers pitfalls of communication breakdowns in outsourcing, and not detailing every task a person is supposed to do is one of the "lessons learned".
    – Shauna
    Commented Aug 1, 2011 at 19:05
  • You need to define "Done" better...
    – user1249
    Commented Jul 15, 2012 at 21:20

8 Answers 8


I don't know your precise situation, so it's very difficult to tell what's happening. Nevertheless, here a few elements which may or may not apply to you:

1. Communication

Do you communicate clearly your ideas? I mean, are you sure that those developers understand correctly what is the work to do?

2. Management

Asking to do something may not be enough. On large projects, you have functional/non-functional requirements, acceptance testing, etc. All this stuff is not just to waste time; it is useful to be clear on the expectations, and to be sure that those expectations are met. Maybe you should use more the techniques used in real project management.

3. Staying connected with the developers

If you let a developer in the wild, chances are he will not be under pressure to end the work. It's like those stories about the interns on Daily WTF: you ask the intern to do something, you forget about this intern, and a few weeks later, you discover that the work is not done and the person is currently doing something strangely different because he was afraid to ask for explanation.

4. Tracking

It is a good idea not only to stay connected, but also to keep an eye regularly on what's done. Asking the developers to commit to your version control server is a good idea: not only do you get the updates daily and can quickly take the required measures if you see that something goes wrong, but it also forces the developers to work from the beginning, and not keeping the work for the last day.

Another technique is to ask the developer to report you daily about the work which was done by phone or through a video conference. I hate this and would never work for somebody who asks me to do that, but it may work very well with other developers.

  • thanks a lot,but what should I do when I am tracking developer on daily basis, I assign daily work and then some items are missing from daily work?In response I have to see those reasons that I know, a developer tell when he don't have any thing to tell because I have passed that time also :). So is it a better idea to get a timeline from developer for daily work? I currently tell them daily work and ask if it is achieve-able , so they agree to do it but end of day we don't have work done because they waste time in their other activities. So what to do in such case? Should find more people?
    – Hafiz
    Commented Aug 1, 2011 at 17:06
  • 1
    If you see that the day 1, half of the work is missing, you ask to explain why. If on the day 2, 3 and 4, it's the same thing, you tell this person that she may not have enough skills to work for you, and you search for another one. There are some developers who are very good when it comes to working in a company, but are just unable to do the work remotely. Commented Aug 1, 2011 at 17:10
  • Yah I think you are correct, some people are not good at their time management so they can't work well remotely.
    – Hafiz
    Commented Aug 1, 2011 at 17:14
  • +1 to Version Control for your tracking. Have them push as soon as they have something that will not break the build if not daily. If you go a couple of days without a push, then you start finding out why not. Commented Aug 1, 2011 at 18:21
  • 1
    @Hafiz - Do you communicate with your freelancers in English, or in your native language? If it's in English, that might also be adding to the issue. Regardless of the details, it seems there was some confusion between what you were expecting and what the freelancer thought you were expecting. If you're communicating in English, I can see where language issues might come into play, as it appears English isn't your native language. That said, my other comment still stands with regards to general rules. I was simply using your search case as an example.
    – Shauna
    Commented Aug 2, 2011 at 17:01

I think that this is part of freelancer hiring. And this is why, getting the response(s) and work you want from an individual, giving them some time to understand how you expect things to be done, and what you want, does take time. Hiring freelancers doesn't always offer that time.

I usually like to stick with people who are good at listening, and quite skilled. That is a rare bread, but I try to treat them well. And I appreciate there skills. People who go by the letter, tend to need more explicit direction. It takes a little more time, but I prefer this. Then I know exactly what gets done. Also, you can't add things into a contract after it is negotiated. You can't say you assumed that they knew this or that. Make sure the details are covered in the contract.

The other side of things is the 'team' contract. These guys are more likely to get things done, but they are often less than professional in terms of communication. They sound like they should be selling used cars, not dealing with an obviously intelligent demographic. My view here is no team, no matter how good, and how easy the price tag is, is worth dealing with behavior that is less than professional.

Regarding not responding, unless they are on contract you can't say much about that. If they are, let them know you will rate their professionalism, or communication in the review of the contract. Ambivalence can get on track pretty quick with a subtle reminder of the consequences.

Don't be too soft, keep talent, reject arrogance. That sums it up.

Paul V.


One practical thing I do is pay half up front, then I pay the other half upon completion to spec. If it doesn't meet spec, they don't get the other half. I don't do unlimited hourly pay as that is asking for trouble. I ask for an hourly estimate up front and pay according to that number. If you don't, then they have no motive to finish on time. The only key is, you have to define your expectations very well and communicate them to the developers. Also, if I hire someone for one project, and he screws me, I never hire him again. Eventually, you get some pretty good freelancers. If you pay them well, and you cull out the bad ones overtime, you will find that you get regulars who are good and who will clear out their schedule for your projects.

All of this of course is in addition to @MainMa's suggestions.

  • I didn't pay them any thing upfront but if they need or require it because they know me that I don't keep any one's money, If I ask some one to leave a project then I pay them a bit more than what their amount is (according to the amount that was set), but it is another trouble to leave some one in the middle of project because it is a bit more expensive, so I think it is a good idea to be with them on current work and next time only utilize them on a bit lose sort of projects that are not as much important and with lose deadlines.
    – Hafiz
    Commented Aug 1, 2011 at 17:11

I help manage remote teams for our clients, and these are the best practices we follow (based on agile and scrum):

  1. Daily Skype Standups - Every day the full team gets on skype for 15 minutes to coordinate and collaborate. We discuss what we did yesterday, what we plan to do today, and if we have any obstacles.
  2. Maintain consistent teams - We keep the same people on the project so that they can develop a relationship with the customer and truly understand their needs. We don't sub-contract out different parts to different people and then try to manage them separately. They need to operate as a single team.
  3. Weekly Demos - We follow 1 week Scrum sprints. That's shorter than many Scrum teams like to do, but for us it's important to do weekly demo's with customers. Demoing that frequently is really critical on remote projects because it makes sure we don't go too long without customer feedback. The example you gave where they implemented search but not search styling is something that would have been caught in one of those regular demos.
  4. Lightweight weekly planning sessions over detailed contracts. Someone else mentioned contracts, but in my experience they don't help with defining clearly what the freelancer needs to get done. You likely can't predict with certainty what they need to do weeks or months in advance, so instead have a contract that makes it very clear how much you are willing to pay per hour and a maximum amount of time you are willing to bill for. Then adjust the scope every week and give them clear instructions what the most important priorities are for the next week, and your definition of "done" for those priorities. This allows you to manage the scope as you go, give clear direction to the team, and stay within your budget.

I know this reply is well after you original post, so hopefully you've long since solved your particular project's challenges. But I wanted to reply anyways in case it's helpful to others who may come across this article. Good luck!


You need to ask the person paying the salaries what your expectations of the consultant's time should be and what to do if you are not satisfied with the quality of the work. Once that is established, everyone can decide if they want to be a part of this project. You can't establish specific rules for every single little situation or you'll be policing all the time and not getting anything done. Ideally everyone has the right attitude and behaves professionally. Personally, I like contractors that have enough experience to be up front about their time constraints and ask what I expect. My dog sitter made sure I got my neighbor an extra key, I always leave contact numbers when traveling, and she has a network of other professionals available in case of an emergency. When you qualify your customers and handle the logistics, it shows you know what you're doing and can be trusted.

MIA for two days? Was it the weekend?

  • First thing is my developers are not salaried. Other thing is that these single things affects my work as I am not a CEO of big organization, what I have posted is the thing that I am experiencing for almost 2-3 months. So I think I should think and have strategy for such situations?
    – Hafiz
    Commented Aug 1, 2011 at 18:16
  • I don't think you have to be on salary to have any expectation of availability. Paying by the hour does not mean you can work when you feel like it. I was not under the impression you had the authority to fire people who do not produce. If you do, what are you waiting for?
    – JeffO
    Commented Aug 1, 2011 at 19:18
  • hmm, I think only bad part in this context was, some of them are friends. But I think one should keep two different relations separate, and I should be strict in work , if some one needs work then he should do it with responsibility other wise we will one day lose business and to avoid this we should be strict and tell them that if they are not good at time management so we need to find for better people as told by MainMa.
    – Hafiz
    Commented Aug 2, 2011 at 7:17
  • And also it was a little difficult to leave some one at middle of a project while he have understood most of things, as any new person will need to do understand it again
    – Hafiz
    Commented Aug 2, 2011 at 7:26

At first glance, the problems you call out have little to do with working remotely, and a lot to do with the interview process.

Interviewing contract resources and vendors is brutally difficult. So difficult, in fact, that for small projects that need to be contracted out it may be more efficient just to think of the first couple projects as part of the interview process, and only consider a vendor reliable after a few successful engagements reflect key skills.

Here's the core interview tasks that my team uses for new vendors:

  1. Technical Skills: We spend an hour w/ watching new resources write code to a problem we give them at the begining of the hour (w/ screen sharing software). We expect developers to be able to write code, and to ask high quality clarifying questions to make sure that they understand the task they are assigned. We also expect outstanding communication skills: If you can't write code and talk about the code you're writing, you wont' be able to collaborate effectively.

  2. Communication skills & work experience: Once we know that a candidate can write code and talk about what they're doing, we walk through their resume with them and talk about their previous experience: do they have real collaboration experience? What has guided their career choices so far: is the work we need done compatible with their professional goals?

At the end of the interview process, we're looking for a resource that people are going to fight over, someone you want to get on your project. If none of the interviewers is anxious to get the candidate on their team, there's not a good fit. This process is heavily inspired by Joel Spolsky's writing about how to find people who are smart and will get things done, and Brad Smart's book on topgrading.

Now as the problems you call out:

  • MIA developer: this can happen with virtual or in-person developers, and usually only if you've not screened carefully. If a vendor doesn't show up when they've commited to be available, its game over, whether their virtual or IRL.
  • CMS w/ static solution: when you give a project to someone who doesn't have the required experience, they'll fail wether they're in the office or not.
  • Work not finished: again, I've had loads of experience with developers not fininishing work, both in the office and virtually. Almost always, this is a result of insufficient technical screening before giving someone a project.

In my experience, which includes more than 15 years of working both in offices and on virtual teams, effective developers are usually productive, and waste of time developers are usually a waste of time. I'll do everything in my power to work with effective developers, and to support them with whatever mix of virtual and in-office work they preffer. And if I do have to work with waste-of-time developers, I'll assume that they'll destroy value and try to minimize their impact until I can roll them off the team, regardless of whether they're in the office or not.


Focus on creating options for yourself.

If your project and budget permit, hire more than one programmer. This should create a healthy level of competition, which is always good. This should also ensure that knowledge is shared amongst the team and will increase redundancy.


I know oDesk has a feature which allows PM's to get screengrabs as the developers are coding a project, however from my direct experience I stick with coders referred through my contacts and I avoid outsourcing at all costs due to the logistical hassles.

  • in above mentioned 3 situations 2 were my referenced developers to whom I know personally know and I think that was wrong thing here :)
    – Hafiz
    Commented Aug 1, 2011 at 16:55
  • I am really sorry for someone that has to monitor developers that way :O Commented Jul 16, 2012 at 5:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.