Someone asked me recently about managing outsourced piecework, where people outside your company are paid by the number of tasks performed. I did this on various projects for over a year with a previous employer. Our trial-and-error approach had quite a few errors, but we did eventually establish a stable system. This is an outline of that successful system, with a few notes about things we tried that didn’t work.
Amazon’s Mechanical Turk is an obvious option in this area, but we didn’t use it, so I can’t comment on its quality. However, two of our biggest challenges were finding people to do the work, and organising payments to them, so a system which makes that easier could be attractive even though it is expensive.
For the rest of this post, I’ll assume that you’re not using Mechanical Turk, that you have at least a few thousand items of work that need to be done, the work is information-based and done over the internet, that you know how to do that work yourself, and that you have trained at least one other person to do it. That last part is important, because a lot of effort will be needed to ensure that people really understand the work that you require.
If all of those conditions are true, what’s next?
The first thing you need is a good set of instructions. Overcoming the curse of knowledge might be the hardest part of your project, and the better your instructions are, the easier the rest of your project will be.
Start with a brief explanation of why you need the work done, and then go through the work itself in as much detail as necessary. Stay away from your company’s jargon, or your industry’s. Describe any decisions that must be made, in excruciating detail. Pictures and screenshots are great, and don’t be afraid to have your instructions be 80% graphics and only 20% text. We created PDFs, for easy distribution, but web pages can work as well.
Once you’ve created a set of instructions covering everything you think someone needs to know, you need to find someone to test them. The less this person knows about your tasks, the better. Give your new instructions to your tester, and ask them to read them through, then complete a few sample tasks. Note any questions they have, and then look at the work they did.
Based on the questions your tester asked, and the mistakes they made, you will probably want to modify your instructions. Do that, and then give them to another tester. Remember that the final users for your instructions will be people you’ll never meet, and may never even speak to: they’ll start knowing nothing about your tasks, so your testers should start that way too.
Once you’ve modified the instructions so that people can complete tasks successfully, you can move on to the next step.
What not to do: training in person. This didn’t work for us because preparing the training takes a long time, finding a venue takes time and costs money, and even if you refund the travel, your are limiting the pool of people who can work with you to those who are willing to travel to you. It can also delay people who are keen to work with you from starting to complete tasks. This approach will not scale well.
We found that our best way to recruit people was to post cheap or free online adverts, in venues like Gumtree or groups on Facebook. Since we weren’t offering full-time employment, we certainly didn’t want to pay for adverts on recruitment sites.
There were as few steps as possible in the process: our adverts contained an email address to write to; we would send out our training document, pay rates, and a list of details we needed for a contract and payments. Once that was returned to us, we would issue user accounts on our software system, and take people through some basic quality control.
If someone took a long time to respond to the email, or repeatedly failed to provide information they were asked for, this was a sign that they might not be able to do the work effectively. It wasn’t a completely reliable sign though, so no-one was excluded at this point, even if took weeks for them to complete this stage.
What not to do: signing contracts in person. It’s very tempting to want to look someone in the eye before signing any kind of contract with them. You should resist this temptation, because again, it limits the pool of people who can work on your project to those that are physically close to you.
What not to do: screening. We tried phone screening for new recruits, but it was impossible to tell if it was saving us any time or effort later in the process, and it did slow down the recruitment process. The only testing of potential workers that was obviously valuable to us was checking whether or not people could do the work we required. Perhaps screening would be useful if there’s a particular skill you need that is easy to test for (a language, maybe?), but it was never useful for us.
For most of life of any project, there was just a single point of contact for these projects. This was the only member of staff that external workers normally approached with questions or comments. This person does not need to be the project manager, but they must at least be an expert in the work required.
For each project, we set up a chat channel for messaging. We used both Skype and Discord successfully, and there are plenty of other options that would work. Whatever software we used, we created the channel, so we had admin rights to it.Our staff member serving as point of contact would need to work through emails and messages for hours each day early on in the project. If they shared answers to new questions, updated the training, and required the remote workers to acknowledge changes to the training, then the amount of work required each day would gradually taper down.To set reasonable expectations, we told our remote workers how soon to expect replies to any emails. With workers in different time zones, perhaps working at unsociable hours, it was important to be clear that our staff would not be available 24/7.
One advantage of a chat channel is that it allows remote workers to start cooperating with each other. We found that more experienced members of the project were often willing to help new members with work queries.
It was fine to have another member of staff handle the early steps of onboarding new remote workers, as long as they clearly handed off the new remote worker at a defined point.
What not to do: multiple managers. Our project was never big enough to absolutely require this, and when we did try it, we often found differences in management styles created confusion for the remote workers.
What not to do: separate contacts for payments. Queries about how much someone would be paid should go to the regular point of contact. We explained when and how those payments should happen during the onboarding process.
The last part of our hiring process, after finding a potential remote worker and getting their details, was checking that they understood our requirements. To do this, we had them do a fairly small amount of work which we reviewed very carefully.
We expected the work we set to take between 30 and 60 minutes. We reviewed every part of it, and gave feedback explaining every error we found. Then, assuming it was possible in the project, we required our remote worker to make corrections.
Where possible, our systems included a setting for each user indicating whether or not they were allowed to freely take on new work items. That option was disabled for new users until we believed they understood the work required, and could do it well enough.
Once people were approved to do as much work as they wished, we would still review a sample of it. The exact proportion depended on how easy the work was to review, how good their previous work had been, and if they were doing unusually difficult work. That said, the proportion was never less than 1% or more than 20%.
The exact upper limit for review will vary from project to project, but for us, if we felt we needed to review more than 20% of a remote worker’s output, it was a sign that we didn’t trust them to get it right. In that case, we should still be limiting the amount of work they were allowed to do, and reviewing all of it.
In one project, we managed to send out a small proportion of work twice to two different remote workers. This increased our costs, since we had to pay for the extra times the work was done, but it also allowed us to quickly compare the results from two unrelated remote workers, effectively using them as checks on each other. If this is possible in your project, it’s probably worth doing.
What not to do: give people too many chances. If a potential remote worker can’t get something right, even if you’ve explained the issue to them two or three times, while other remote workers don’t have the same problem, then it may be time to cut your losses. We found that some people couldn’t give the kind of attention to detail we needed, and it was easier to cut them early, rather than let them take up too much of our time.
Our gross pay rate was always set out up front, a certain number of dollars or euros per item. We set that rate once we were familiar with the work, and knew how many items a reasonably diligent worker could complete in an hour.
I don’t have a copy of one of the contracts handy, and I wouldn’t necessarily recommend it to you even if I had: I’m not a lawyer. Depending on your location and the location of your remote workers, there may be legal requirements around pay rates, tax liabilities, or other issues. We stressed in our contract that we intended to pay only per unit of work of acceptable quality, and that we were paying gross, without withholding anything to pay any taxes.
Our usual rhythm of payments was to complete one payment cycle every week, and to pay each worker in every cycle, provided that we owed them more than a certain amount, typically 100 euros. If we owed a worker less than 100 euros, we would typically withhold payment on that week, unless the project was completed, or the worker wanted to leave the project entirely. This avoided us having to pay fixed fees again and again while transferring relatively small amounts of money.
If a worker stayed with us for a few weeks, was working over 20 hours a week, and was always passing the quality checks, we’d normally give them a small pay bump, perhaps another 10%. These workers were the backbone of our project delivery, and required little supervision. Paying a little extra to keep them putting in the hours was worthwhile when we had deadlines to meet.
What not to do: agree to pay a certain amount into someone’s account without specifying how. Transferwise is great, and very cheap when available, but we found ourselves needing to use Western Union pretty frequently, and they are pretty expensive. Our early contracts simply said that an amount would be paid to the remote worker, so we had to bear the cost of any transfers.
One thing we did not do was add as many people as possible to a new project early on. For the first few weeks, we kept the number of remote workers limited to about ten, ideally people that we had worked with before.
Instructions, quality control, calculating payments and distributing payments were slightly different in every project. It’s far easier to clarify instructions, repeat calculations, or change payment method at the last minute if only ten people are affected, rather than fifty. By the time there were twenty or more people in the project, we had smoothed out any rough edges, and our progress was regular and predictable.
Other Things To Try
Something that worked well for one project was video instructions. These were created by the expert point of contact; the video was a screen share of them doing a piece of work, accompanied by them talking about how to solve particular problems. I can’t remember what software we used to create the video, but we uploaded them to YouTube as unlisted, and shared the URL with our external workers.
One idea that I considered, but never tried, was giving some of the better workers some responsibility for quality control. We never reached 100 concurrent remote workers, but if we had, we might not have been able to stay on top of the quality control work. In that case, distributing the quality control work seemed like the logical next step.
That’s what I remember off the top of my head about how to manage these projects, but if you have any questions, let me know!