I am a Web application developer, also responsible for project management. I occasionally manage remote developers, who work for me under a contract basis. Sometimes, this can prove very difficult. A few challenges I have encountered:

Once, a developer went incommunicado for two days while we had to deliver a project.

Once, a developer templated a CMS with static solution.

Once, I asked a developer to complete search functionality and the next day he said he'd done it. But when I looked, it wasn't done. He completed the search but not search result listing formatting.

Am I working with the wrong people? Or is my management style the problem?

Answer: 4 Focii (34 Votes)

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 your ideas clearly? I mean, are you sure that those developers understand the work you ask them to do?

2. Management: Asking a remote developer 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 focus more on techniques used in real project management.

3. Staying connected with the developers: If you release a developer into the wild, chances are he will not feel 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 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 on what's being done. Asking remote developers to commit to your version control server is a good idea. With version control, not only do you get daily updates, but you can quickly reverse a mistake if something goes wrong. Also, version control encourages developers to avoid waiting until the last minute.

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

Answer: Pay Smart (2 Votes)

One practical thing I do is pay half up front, then pay the other half upon completion to spec. If the work doesn't meet spec, remote freelancers 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 go hourly without an upper limit, then remote devs 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 that person again. Eventually, you will find some pretty competent 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.

Answer: Tangible Milestones (27 Votes)

Screenshots (which a manager can grab via remote contracting programs like oDesk) seem counter productive. If it comes to managing like that, you're in trouble.

The ideal is to have tangible milestones, and check remote developers' progress against them. If you can't get your money's worth on the milestones based on the amount of time you have to pay to get them, find other help. If you can't create the work at this level of detail, and don't know if you're getting ripped off, it might be inappropriate to source the work remotely. You could introduce a system of competitive bidding for the work, but if you can't detail what's needed at a low level, can you tell what the code quality is?

In general, outsourcing and remote work should be about buying results, not buying time. Otherwise, as you've found out, the trust breaks down.

Answer: Put Objectives in Print (14 Votes)

What you want is called a contract. The contract says what remote developers must deliver and when, and what you have to pay and when.

It is this simple. Everything else is dramatically counter productive. It will break confidence between you and the freelancer. If you want to closely look at what people are doing, then consider hiring in your office.

Answer: Hire Intelligently (2 Votes)

You need to be comfortable with the people you are hiring, before you hire them.

At the point you are thinking of essentially spying on the people you hire, it is too late. I am an honest programmer, but I wouldn't work under those conditions (even assuming that they are legal). It's like when you cross the border—you might not be hiding anything, but customs and immigaration sure makes you feel like you are.

Do background checks, get references, ask questions. Use reputable services. Make careful decisions, and follow the advice of managers you trust.

Think you know the best way to manage remote developers? Disagree with the opinions expressed above? Downvote or upvote an answer, or bring your wisdom to the original post at Stack Exchange, a network of 80+ sites where you can trade expert knowledge on topics like web apps, cycling, scientific skepticism, and (almost) everything in between.

Understand the cultural differences with your remote workers, especially those in foreign countries. There is a very different perspective on work life balance in many countries, and what US based employers may see as laziness or lack of dedication to the corporate culture, may just be their interpretation of your guidance.

You will need to explicitly define your requirements and delivery times, while leaving nothing to the imagination. Remember these people are not next to you white boarding and collaborating with you directly. They are going to take the requirements handed to them, interpret it, and depending on their culture go off and build it or come back and question it. For example, most Europeans are very collaborative and often won't do anything without consensus, they also leave at 5 pm and that is it for the day. Most Asian cultures on the other hand will work hard, but they won't question or rock the boat. If you don't have it explicitly spelled out and leave something questionable they will do their best to fill in the blanks, which may not always be how you envisioned the end result.

I've been a full-time telecommuter, working from my house, for almost 20 years. I can tell you that biggest problem I've encountered with some managers is that they try to manage via the "seeing a warm body" method (walk around the office and expect to see people looking busy). In order to manage remote workers you really need to manage via the "requirements and deadlines" method (specify what you want done and by when, that's all). As a manager, you need to get into the mind set of, "Here's what I need done and I need it by this time, I don't care how you get it done as long as it's done by this time and the quality of work is good." If the remote worker decides to have their child do the work at the night before the deadline, who cares, as long as it's done, done correctly, and the quality of the work is there. Incidentally, this type of management also works well for office workers and agrees with the Agile way of working as well, so it's all good. It just comes down to learning how to manage correctly instead of assuming that a person "looking busy" is actually doing anything.

I've worked for a foreign company that was based just too many timezones away to communicate with our office. The the "CTO" worked there, another part was I don't know exactly where, project owner aka product manager was in yet another timezone, and we were 8 or 9 hours away. Add the fact that overseas trust is less than optimal and you've got a great, big mess.

Regarding the daily phone or video conference status reports, your people will hate you if you do it.

I have a friend whose boss contacts him at irregular intervals asking for everything he's done since they last talked. He says he loses huge chunks of his day just to satisfy his boss' curiousity/whateveryouwannacallit. It's just another one of those unproductive meetings that we all hate so much, there are better ways to do it.

It would be difficult to give specific advice without knowing the specifics of the situation, however a general discussion may still be useful.

It is important to realize that there are several types of remote workers, and who you are dealing with should play a large role in determining an appropriate course of action.

1) Remote employees

These are people who you intend to keep on the payroll for an indefinite period of time. You may ask of them what you will, and their choice is to quit or stay (or be fired.) It is entirely reasonable to ask for at least a daily call or e-mail regarding current project status. If they are a developer with no other responsibility, it is likely appropriate to give them detailed specifications regarding the project, and expect that they will comply with your specs (with perhaps some clarification.) If your specifications are incomplete or incorrect and they have no customer interaction, this is on you.

2) Contractors

These are people who take on a project which is somewhat long term, and may be in the office or not at your discretion. It is inappropriate to place any project management responsibilities upon these individuals, as that is your job. This also generally covers projects where you have need of additional labor for a short time, but it would be within your capability to do this work internally if you needed to. Your terms should be explicit in contract, and you may request another if they do not meet your criteria.

3) Consultants

These are people who bring expertise which your organization lacks. You have no real ability to ascertain their skills, and are relying upon reference and past ability to determine if they fit your needs. If you want a daily report they will likely be willing to do that, but it will cost you more, and your manager may take great offense at the much increased bill. Your involvement is at their discretion more than yours, and it is important to realize that. It is also common for consultants to want direct communication with your clients, as you may not be able to effectively communicate what they want, and they are hired to solve a problem, and not do what you want them to do.

The perspective on my part is as someone who spent a good decade as a consultant (and is now on the other side of the fence.) If I was bothered six times a day by someone who was under a mistaken impression as to what our business relationship was, I would bill them for the day (at full hourly rate, even if the calls were five minutes.) I would also likely send a message to the senior management about the reason for the huge bill well before this became a problem, and in several cases it cost the middle manager their job as they continued to bother me anyway despite a warning not to do so.

You should not expect that you will reach a consultant at any point that is convenient to you unless you are paying a retainer for that privilege. It was not uncommon for me to defer communication for a full month, as I had other projects to worry about which were billable at a higher rate (I took on lower rate projects to fill open time, but everyone who was party to the contract knew this, and was not expecting full service.)

I also usually demanded direct access to your customers, as the problem was in many cases a failure of management, and not technical.

In short, it is very important to know who you are dealing with. It may be entirely outside your control what work they do and when they do it. It may also be someone who you do control, and is answerable to you.

I haven't work much with remote developers but the biggest problem for in-house ones is the failure of management to specify the interfaces the software units must meet. It's important to get this interfaces written down early in the project so everyone knows what has to been done. And if failure to create the interfaces specs causes problems in-house, imagine what a remote developer would come up with without them.

make sure the project is fully unit testable. Write two sets of unit tests. The first is given to the remote team. The second is reserved for verification. If the first set of tests pass, the second set should pass, too, perhaps with a few exceptions. Once 90% of the second set passes, send those over. They don't get paid until all tests pass.

Coming from a fairly large shop that had resources around the world, it's hard to have this type of work done on a time critical basis like the OP seems to have done.

A couple of big mistakes, and misconceptions. You don't save money outsourcing, you give the bean counters numbers that make management look good. "Look I have twice the developers for half the money"!

The hard truth is that in these situations, if your using offshore resources, the larger organizations will have a project manager that manages their folks. You communicate your project plan, schedules, and technical requirements to this guy and he relays it to his folks. He also verifies that the plan is realistic, fitting in with his/her peoples vacation schedules, other commitments, etc. Chances are, the same developers are working on several other customers work, and if they pay more money, chances are that's where you two day incommunicado developer went.

If they are on-shore consultants, make it clear you expect regular reporting or feedback. The dissapearing act is unacceptable and you won't be using their services again if there wasn't a good explanation. Sometimes things happen, everybody has a life/family and reality sometimes get's in the way. A simple heads up that someone isn't going to be around isn't asking too much, and they should know that is common courtesy. If not, make your expectations known. Again, it depends on the situations. You can't control that, but your schedules shouldn't be so tight as to expect everyone to show up every day.

In general, If you need all hands on board for day 0 (aka cut-over, release day, etc.), speak to each individual, make sure they are on-board ahead of time. Don't pop it to them on Tuesday when your releasing on Wednesday.

Never depend on a developers word for code. Get the code in house, test it, verify it, report back any issues. Pretty standard development life-cycle here. If the quality or timeliness is not up to your expectations, you either have unrealistic time requirements, an unqualified developer, or vague/incomplete specs. At some point you need to make a decision on what the problem is, and in the case of a poor developer, you have that guy replaced.

Never get angry or yell, it really doesn't help anything, but don't settle for excuses. You hold the cash, tie it to specific, well understood project milestones that you both agree on BEFORE the project starts.

Keep your customer expectations under control. You need to avoid scope creep. The best way to deal with that is to give them dollar amounts on how much changes will cost in terms of both time and money.

The old "I know that's what I asked for but that's not what I want" is your customers problem, not the remote developers. This situation should never occur, because that's what the spec gathering phase is for. I know it's not always a huge project and some things are said over the phone, but put it in writing and let the person asking for the work to review it and sign off on it.

Once you've done it a few times, you'll settle on the best approach for your situation. The OP has received some good advice here, he just needs to apply it. Projects are never black and white, but shades of grey, and nobody can control every single aspect. Once you learn that and how to conrol expectations, you'll still hear crap, because you can never make everyone happy!

You hold the cash, tie it to specific, well understood project milestones that you both agree on BEFORE the project starts.

Does not work. Some developers will agree on anything to get the job (this is for both in-house and remote). Statements made under duress are not binding. If you threaten their livelihood, anything can happen.

Think of it this way: when you hire a general contractor to renovate your home, the typical payment schedule is 40% up front, 50% when the job is halfway done, and 10% on completion. Do you pay your developers the same way? If not, why not?

If you want to work with the best, you have to pay on time. If you don't, you'll end up with those who will say anything to get paid. You get what you pay for. And if you don't pay, you get the worst.

Some of those problems stem from unreasonable expectations. I think estimates are the worst thing in this industry, I usually just quote Carmack and Blizzard and just say "when it's done". I also often say you can't have 9 babies in a month and even if you did that would take much more than 81 virgins But it took me a long time to be able to say that - initially as a low level junior dev, I simply accepted and observed deadlines slip. Now I don't accept or communicate as clearly as possible and charge daily.

Some of those problems stem from unreasonable expectations. I think estimates are the worst thing in this industry, I usually just quote Carmack and Blizzard and just say "when it's done". I also often say you can't have 9 babies in a month and even if you did that would take much more than 81 virgins But it took me a long time to be able to say that - initially as a low level junior dev, I simply accepted and observed deadlines slip. Now I don't accept or communicate as clearly as possible and charge daily.

That's too radical - sometimes deadlines are there for a reason and in some cases people appreciate the consequences.Once we were racing to provide a prototype before the beginning of a tax year in order to win a bid. We did as much as we could but enough to win the bid, so in that scenario a deadline made sense and after we won the bid we started writing the code from scratch..

cerberusTI did a great job of describing the types of workers. From there, it all went downhill. Charging a full day for 5 minutes work? Not commuinicating for a month? When you offer a service, you should provide some reasonable level of service. I consider those actions unreasonable.

I got a contract once due to some "integrated circuit expert" in Arizona dicking around the customer. Unknown to this asshat, a staff member had to visit a customer in Arizona and made a side trip to see why jim wasn't returning his calls. It turned out he was repairing his roof! At that point, contract terminated.

In project management, there's a term called "float time" which is added to projects to account for employees calling in sick, missing a deadline, etc. What gets me about a lot of management these days is they think everything will go off like clockwork. Toss in some float time to a project, so various "oops" moments or sick days can get account for.

As for managing remote employees ... I vote for the contract ... SLA ... service level agreement.

It should have both rewards for positive behaviour, and punishments for negative behaviour. Not necessary for EVERYTHING to have those, but it's good for the freelancers to have an incentive to shoot for, and an incentive to avoid if they hose something up.

EG: if they meet milestones before time, then they get a bonus. If they miss them by a day or so, no biggie .. it dips into the float time. But, if they totally blow a milestone by tons of time ... then they get to spend the rest of their time trying to fix whatever hosed up for free.

It's good to have an IN-HOUSE QA person know exactly what the spec should be like, and test whatever the remote dev's roll out as it happens. That QA person should be busy each day testing, testing, testing. When something doesn't seem right, then your QA person will be the first to know.

I think this is the part where managers fail ... they think it's their job to follow up on their employees' work. No...that's the QA's part. It's your job to bring the hammer down, or remove road blocks, or attend meetings ... and do whatever it takes to remove annoyances, interruptions, etc from your remote devs. Your QA person is your eyes and ears ... they test the code. They give you feedback. You get with the dev and you and the QA person put them back on track if they're off spec. DON'T BERATE SOMEONE FOR SCREWING UP. You need to let them know that you are open to questions ... ask quesitons ... a question asked early on can save tons of time wasted doing the wrong thing.

It's also good to do some early proto-typing in-house, that way your group will have a clear objective. If you leave a dev (any dev, not just a remote dev) open to dream up a solution, you'll find it might be all over the map. If you do (as jakob nielsen says) "paper prototyping" of interfaces, some early QA testing with user groups on interfaces, and have your QA person hammer away and test constantly, then as the manager, it's just your job to keep everyone off your devs' backs so they can get shit done on time.

EG: if they meet milestones before time, then they get a bonus. If they miss them by a day or so, no biggie .. it dips into the float time. But, if they totally blow a milestone by tons of time ... then they get to spend the rest of their time trying to fix whatever hosed up for free.

And who decides whether the work is sufficient? You? As I said before, the best in the business won't even look at a contract with such a clause and the worst will spend their time looking for another contract because they know each one is a one-shot. You simply can't put a harsh condition in a contract if you want the very best. If you do, chances are you'll get the very worst.

It's not easy to manage remote workers. I'd like to stress more on her last point: Tracking.

I believe this is the most important aspect to consider whether you are tracking a remote team of software engineers or a team of freelancers. You have to utilize collaboration tools like Skype and Basecamp and also time and productivity tools like Time Doctor. Even though the "results and deadlines" type of manager is the most ideal (as mentioned in this thread), there still has to be an "efficient" way of monitoring them so you will know how things are going on even though you don't see each other physically or on a regular basis. This, I believe is the only way to keep things productive and probably the best way to manage a remote team.

Great topic and I have to just remind myself that I actually did try using time doctor's tracking software like you suggested in this post and my site <a href="http://wallstreetgenerators.com/">wealth generators</a> was having a minor glitch with the template being out of order so I have to now get an expert site developer to fix it. I heard it was good so once this is fixed i'll keep you updated on the results. Thanks.

Great topic and I have to just remind myself that I actually did try using time doctor's tracking software like you suggested in this post and my site http://wallstreetgenerators.com was having a minor glitch with the template being out of order so I have to now get an expert site developer to fix it. I heard it was good so once this is fixed i'll keep you updated on the results. Thanks.