Outsourced Or In-House Developers?

So, you have a workload of software projects, a veritable plethora of projects to get off your plate. Or, maybe you are considering an expansion of your capabilities. Your current team is tapped out… hopefully not overworked and tired; you don’t want to break their backs.

WARNING: I will be using the word “outsourcee” to refer to any entity not in-house performing work on behalf of your company. There’s nothing wrong with the word itself, although it’s full of negative connotations of lost jobs, cheap labor and evil executives. But, if you are a die-hard isolationist or a nationalist, you will be unable to read further. You have been warned. 🙂

You’re looking at various reasons and wondering if you should hire more in-house developers, or farm out. Here’s the top-level factors I look at to help me decide when to farm the work out. Of course, this is all from an SMB point-of-view; larger companies have a completely different perspective and set of tests to check against.

• Niche/Esoteric Skills: If the project involves some fringe technology, or unique skill set that will not see much re-use in-house, then farm it out. Note that this could be an emerging technology, or an old one that would bore your in-house team to tears. Usually, hiring in-house for this is a big challenge anyways…
• Time-To-Market Pressure: If the project involves the need to get something out before competitors claim the territory, farm it out. You should seek an outsourcing shop that will properly staff up so as to get your project out in the time frame you set for it. You’ll pay through the nose, but that may be the difference between sick or swim…
• Overwhelming Workload: Obviously, one reason to consider farming out is if you have a large spike in the overall short-term workload. This is quite common in small businesses. Instead of slowing down and stretching thin, just bring in short-term, contract-based workers to shore up your team(s).
• One-off or Short-Term Project: If the project is a side-bar to a core project, or some “throw-away” task where ongoing maintenance is not going to be an issue, consider farming it out and don’t bog down your core, in-house team(s) with it.
• Experience Gain: You may want to consider randomly outsourcing the “easy, non-critical ones” just to gain experience with outsourcing options in your local area, or the broader market, simply so that you then know a little bit more about who to go to when it really counts.

There are undoubtedly more reasons, but I think these are the main, big ones. The more these reasons exist in any one project, the more you should consider farming out the work. Otherwise, don’t. It is better, and less costly, to go in-house. No really!

First, less face it, every dollar you spend creates/elevates talent in some individual, and it is generally best to keep that talent close to your vest rather than see it go to another company, especially a competitor.

Second, there’s more to developers than churning out code, even the so-called “boilerplate” stuff. Being able to effectively understand and translate requirements and interact with business users comes, in large part, from close familiarity with the people and the processes, a.k.a. the “ramp-up” or “learning curve”, and the short feedback cycle that comes from being in-house. These two have had a larger, empirical, hard-to-measure impact on any team’s performance than anything else. It doesn’t help the “super-awesome outsourced guru” if he has to wait two days for an email reply on a process issue from some department because they are swamped with some monthly peak of work. Every time you farm out, you’ll hit this over and over again. In-house is undoubtedly both a short-term and long-term investment. Treat it as such.

Lastly, contrary to the typical assumption I hear, farming out is usually not cheaper. A good, in-house team will simply cost less than an equivalent, good outsourced team, even if you consider all indirect costs. My off-the-cuff, empirical, “from-the-SMB” conversion factor is that outsourced is 2-4x more than in-house. One main problem is that because the outsourcing market, even post-dotcom bubble, has an incredibly high markup on IT work. Unfortunately, the perception that outsourcing is cheaper is because the comparison is usually between a bad, in-house team and a good outsourced consultancy.

If you are going to farm it out, the next question typically becomes who to farm out to. There are four general categories:

• Freelancers: These are the “unincorporated” outsourcees that cost on the low-end of my conversion factor. They usually don’t have much overhead to worry about because the job isn’t their primary source of income. Lots of developers from large, status-quo-loving companies want to expand their skills and so pick up work on the side. Or, out-of-work, between-job developers will take on short-term contracts to fill the income gap. The main and dominant problem is the lack of accountability on multiple levels, from the personal involvement to the legal ramifications if they drop out on you. If you don’t know any freelancers, consider shopping on websites like Rent-A-Coder.
• Local Outsourcee: The local outsourcee is a local, incorporated shop, usually with a smallish team or teams, that makes a living providing recurrent, happy IT service. They are usually not cheap, because of their business overhead. However, as a manager, if I can’t keep the capital in the house, I sure try to keep it in the neighborhood, because it eventually comes back to us. I’m not talking about “paying it forward” (although if that does happen, then great!), just that a vibrant local economy is indirectly good for my business. On a selfish level, it also helps me build out my local personal and corporate network of contacts.
• Remote Outsourcee: There are all sorts of levels of outsourcing here, ranging from neighboring states, to neighboring countries to full use of sweatshops in Central Nepal. If you are an SMB, you should really not go to this option, unless you have a direct reference to an active shop used actively by another SMB you know and trust. I have heard too many horror stories of SMBs burned by this kind of outsourcing. The problem is that lots of these big offshore consultancies are driven by big customers and you’ll simply get lost in the mix. The smaller, satellite consultancies that emerge in such areas are usually unable to serve you properly because the big shops drain the area of real talent. The former is exorbitantly expensive, the latter is expensive in terms of direct cost due to the inevitable mess-ups. You’d be surprised how not cheap offshore work in places like India has become.
• Internship: Don’t forget to consider using variants of the idea of internship. The concept is that you get some raw talent and let him/her beat his head on a project in exchange for a low wage and a great reference. Like farming out locally, there’s a lot of goodwill generated in this route. You may find your next hire in an intern; you certainly may find out who not to hire too. Each individual will hopefully go on to speak highly of you to other students or junior co-workers, generating potential future hiring opportunities. But, if you want to do this right, don’t hire just to stick a kid in the corner cube, and leave him or her to sink-or-swim. What you save in hard dollars will have to be spent in your own or senior developer’s hand-holding time.

This pretty much sums up how I consider outsourcing, short of a lengthier novella on the subject.

One last warning: Be open with the work and get your team’s opinion on farming out any work. Don’t let them hear about it indirectly and give them the opportunity to step up if they want and can deliver. Psychologically, from a morale point-of-view, keeping your team out of the loop is a big no-no.

What are your experiences? Do they match up with the above?