Why The Mechanical Turk Just Doesn’t Work

I’m on a tear these days talking about my frustrations with offshoring versus outsourcing. By tear, I mean I wrote one blog a few weeks back so in the natural law of thinking that makes me a pseudo expert of sorts right? Well maybe not an expert, but I do have over 12 years experience working with outsourced teams and about 7 years working with offshore salaried teams. There is no jury to be had. I can pretty much tell you that I’m siding with offshore salaried teams over outsourced contractor teams ten times over. I’ll throw in “Sunday” just for grins. Those who know me often joke that I mix-up figures of expression all of the time, so why not do it in this blog.      

Let me start off by saying I have a problem. I know I have a problem and sadly I and my teammates created the problem. We didn’t mean to create the problem. In fact, we had the best of intentions when we set about our work. No matter how we look at it, we created the problem. 

It all started back in 2006 when my company made a big acquisition. We ended up acquiring our largest competitor at the time. I was given some investment to make use of some outsourced resources from a service provider in India. I won’t use their name, but I’m sure if you look through some of my past blogs you ‘may’ be able to figure it out. We brought on a small team of two engineers. They came to my office in Washington, DC. I even had them sit in my personal office, which at the time was small and uncomfortable. It didn’t have good air ventilation or air conditioning for that matter. It was a room with 4 walls and a white board. That kind of sucked for me, but the two guys were used to rolling power outages and work conditions far worst than a humid DC summer in a stuffy office building. I brought in a fan…everyone was fine.

These guys stayed with me on-site for about 3 months. It was great as each day I really spent my time teaching about Performance Engineering which is by far my absolute favorite topic to teach others and talk about with others. Even though these guys were contractors, I treated them like they were teammates. Heck, they sat next to me for 90 days, how could I not. When the 3 months were over, they went back to India and we continued the working relationship remote. These two guys were great as one stuck on our team for two years and the other stayed with us for 3 years. 


Over time we would add team members. I think at one point the team got as big as 7. Today it’s 4 which has pretty much been the sweet spot in terms of what my North American team could manage day to day. Having 7 teammates remote is tough unless you have good leadership. The best leadership we ever got was with those first two teammates. You can tell from that last statement that after year three, everything went downhill. I’ve been thinking a lot about why this outcome of a struggling contractor team has been. The obvious is that these teammates are/were contractors and not officially part of our team. While we try/tried to make them feel as though they are/were part of our team, their solidarity is/was with their own company. They go to their company’s headquarters. They have bosses in India and only points of contact in the states. It’s not like I give them raises or bonuses. I tell them good work or you were awesome today. That’s basically it… I’ve been able to narrow down three reasons in greater detail as to why this model of offshore contracting has been unsuccessful for me and my team. 

The first and obvious is the difficulty to find good leadership to run the team’s day to day operations on the ground. The most talented resources who can do this are identified and hand-picked very early on by these large professional services companies. They become good candidates for on-shore work because they have good presence and can represent the company better. I could be totally off-base on this comment as I’m really only basing this conclusion on about five teammates I’ve had over the years that left our team in an offshore capacity to find work onshore. I am pretty confident that a sample size of five is pretty strong statistically so I’ll stand by my argument.

Second is that I’ve found that many of my contractors took a position in consulting because they wanted the diversity of changing projects. That’s not what I want or need from my consultants. I need a consultant who’s going to stick with my team for many years and advance their career and pay on our team. I need someone who doesn’t get bored after two months on a project. Financially it’s still more cost effective for me to have this kind of model because I can cut overhead costs and still have a team member that can stay long with us. That doesn’t happen in this world of outsourced and offshore contractors. You really are lucky to have someone stick around for a year. If you are really lucky you can keep someone around for 18 months. If someone stayed longer than 18 months it has a negative affect on their resume and future job prospects. It’s like a budding young wannabe NBA start who hasn’t declared for the draft by the age of 4. By 5 years-old you over the hill. So you better declare for the draft by the time you know how to tie your shoes before you become stale and old. That’s the same deal here in this part of the world in the land of consulting. 

The third problem is something that me and my team created. Many years ago we started this automation project we called Fusion. We put a front-end UI on it called Galileo. It’s been a huge asset for our team. Maybe one day we might even open source the code and give this stuff away for free. As we were building this, I remember one of my DC engineers joked and named it “Automaton” to reflect how it could potentially make all of our teammates into robots. Awkwardly, I think he felt like it would open up the doors for us to replace staff with robots. That was never its intention. The intention was to make our business processes more reliable, timely and predictable. Most importantly it was designed to make our team scale without having to make loads of investment in resources.


 Galileo has been an incredibly successful project for my team. I am very proud of it and the team that has spent years building, maintaining and promoting the platform to others at my company. What has happened with my outsourced contractors is that they lost their way of contributing to the team in a meaningful sense. They used to be adequate performance engineers. They used to spend time digging into issues. They used to do more work sadly. With Galileo, the team has had a propensity to become push button operators. When Galileo has a problem they stop working like a bunch of office workers when the Internet is down. They have turned themselves into Mechanical Turks. 

“Bummer…looks like the Internet is down. Let’s go to Starbucks, get some coffee and smoke a couple of cigarettes before Phil in IT resets the switch and we have to get back to work!”


I’m not talking about Amazon’s Mechanical Turk program when I talk about my contractor team. Heck if I used Amazon it would be a whole heck cheaper, but all I would get are fake twitter feeds, email spam and blog comments. The term Mechanical Turk came out of the late 18th century in Europe. Someone had invented a fake chess-playing machine to impress some royalty in Austria. It was all an elaborate hoax based on a human chess player inside of the machine making moves via magnets. The robot itself was a lifeless puppet that would make the moves required by a master chess player hiding in the box. 


I’m not saying Galileo has become a hoax. It’s not at all. I am saying that the team (our contractors) who primarily interact with it have become mechanical turks in their own right pushing buttons and watching spinning wheels and status pages as they wait for tasks to complete. They completely lost their priorities. The whole vision behind Galileo was that it would do all of the repeatable, brute force work in an automated fashion. It would do all of the work that the contractors had historically performed years back. It would create “opportunities” for the team to become better chefs in our kitchen. They could assemble Galileo templates like recipes and do some cooking. While the cooking was happening, they could do more analysis of performance issues. Unfortunately that never materialized. Rather than becoming better performance engineers, our contractors turned themselves into pushbutton operators. They knew how to do one thing well, run a test. It didn’t matter that the machine was running it for them. 



One thought on “Why The Mechanical Turk Just Doesn’t Work

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s