The most important contributor to success in any project is the talent and commitment of the people working on it. Good people do the right thing, do it fast, and do it with minimal intervention. This is especially true in software development, where the good engineers are anecdotally reported to be ten times as productive as the average contributor. If you believe this (I believe it), you will invest heavily in getting and keeping the right people.
Managing a distributed team is not easy. If you are doing the work, you should insist on getting the benefit. The benefit is that you can work with good people, even if they cannot come to your office. If you are having trouble getting the right people into your office, you can expand with a distributed team.
Here are some hints from on our own experience building distributed teams.
We hire people that we have never met. Instead of interviews, we do trials. If we like someone on paper, we offer them a temporary contract, usually two weeks. Then, we ask them to help us with some real work. Usually, we can see if we want to work together within the first few days. At the end of the trial period, if we like the candidate, and the candidate likes us, we try to set up long-term job agreement.
Trials are often faster than doing interviews. We find that it often takes two weeks find the right people to talk to the candidate, schedule times, and get feedback. If you measure this in your own organization, you will be surprised at how long it takes. And, the time that you spend on interviews costs you money. Trials can be cheaper, even if you pay the candidate well.
Trials can also improve results. I have found that when I hire people for on-site work, even after doing careful interviews, there is only about a 50% probability that the person will stay long term. Half the time, they have a problem with us, or we have a problem with them, and they leave within 3 months. This finding is consistent across many different companies and job types. It is disruptive and expensive for both sides.
There is some evidence that trials give better results if you do not meet the candidates. When you interview someone, you won't select the person who does the best work. You will select the person that you like. In the book "Blink", Malcolm Gladwell tells the story of orchestra recruiters who compared a process with a personal interview, and an audition, with a process where they listened to candidates play an audition piece from behind a screen. It turns out that personal interviews tended to result in the hiring affable, good looking men. Without the screen, the personal, visual impression of the candidate is so powerful that it actually affects the sound that the committee heard. They thought they were selecting the best audition player, but when they used the screen, and really were able to listen to the audition, they heard differently. The human mind, your mind and mine, is filled with powerful biases. Some of those biases are useful for making quick decisions, and some are just misleading. You can use trials to make sure that candidates are good at the work.
Over many years, we have discovered things that help us succeed with trials.
Use a standard contract and contracting process. We built an entire oDesk style contracting system into Assembla to manage these contracts and payments. It's worth it. You can set up an internal process to bring in candidates, or use a crowdsourcing site.
Make sure the candidate is really available. The most common cause of failure in trials is that the candidate does not show up for work. If the candidate has a different job, they will almost always overestimate the free time they have available. Get a full time commitment, or assume a part-time commitment will only be 10 hours per week.
Don't let an outsourcing project manager or recruiter obscure the identity of the candidates. You want individual talent and commitment.
Do real work. You can give people a test task. This helps you compare one candidate to another. However, I think this gives you a lower probability of succeeding with the trial. The candidate will see that it is just a test task. The internal leader that is running the trial will not spend much effort to help the candidate do a good job, because he doesn't need the work. It's just a test. If both sides are working on a real task that the project needs, they will pay more attention. The trial will succeed more often.
Save beginner tasks. You should keep a list of tasks that you can give to candidates.
Provide a lot of support in the early stages. You will get good results if the candidate feels like part of the team from the first day. Sometimes, the trial leader will spend time with candidates. If the trial leaders are busy, you can ask a team member or admin person to communicate with the candidate every day for the first few days.
Do a formal evaluation at the scheduled end of the trial. It is easy to let this task be delayed if you have a lot of work. However, it will hurt your recruiting, and recruiting is the most important thing that you do. I recommend asking an administrative person to send out "What did you think / What did you accomplish" messages. Send them to both the candidate, and the trial leader. Do this promptly just before the end of the trial.
A lot of people do recruiting by asking friends, relatives, business acquaintances, and employees for referrals. If your referrers are enthusiastic supporters, they can persuade some great people to become candidates. That's a terrific result. However you should not depend on this strategy because it is statistically a bad bet. I call it the "ask your cousin" strategy. Would you rather select from 50 people that your cousin knows, or 5000 people reading an advertisement? Even if you are getting a good flow of referrals, look at outside candidates to make sure that the referral process is giving you better candidates.
Write the job description and post it. The act of writing a job
description and agreeing on it will get your own team involved, and
make the recruiting more likely to succeed. Posting it will get you
candidates.
Post as widely as possible. Use both general and specialized online
job boards. Use internal forums to post jobs inside big
companies.
If you are assembling a new team from employees of a big company, you can still use these tactics. You can write and post team openings on internal communication boards. You can insist on a trial period, and on the ability to select the people you want.
Crowdsourcing sites are good sources of leads. They fit naturally with a trial process. Read the terms of the crowdsourcing agreement carefully. Look for agreements that allow you to work more directly with a "provider" when you find a good one.
You will need an internal team leader to work with your trial candidates. You should train people for this role. To work with programming candidates, you will need a Tech Lead. Please see our "Tech Lead Checklist" for a description of Tech Lead tasks, including recruiting and team onboarding.
I like working with truly global teams where a person in any location can grow to do any job. Try to remove obstacles based on location, contracts, or history
You will get best results if you can get full-time attention from your team members. When possible, try to organize full time jobs, and not part time jobs.
Getting attention can be a problem in "functional" organizations. You may only get a small slice of an expert's time. According to lean theory, you will get good results if the functional experts focus full time on one task until they finish it, even if they have a lot of tasks waiting. You can help functional experts by setting up a Kanban board where they can display the work that is waiting, and show the WIP. They will appreciate the opportunity to finish their WIP.
If your project is complicated, you want to keep people long term. It takes a long time to build knowledge of a complicated system, and you want to keep the people that have that knowledge. Here are some things to think about: