What recommendations can you give in managing a team of remote software engineers? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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!

Answer 5

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?

Answer 6

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.

Answer 7

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.

Answer 8

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.