Is Outsourcing Right for Startups?

A friend wrote to me and asked me should he outsource or not. Turns out a number of startups confront this question in the early days. Especially if there are concerns with respect to delivering software on time and within estimates. My answer doesn’t vary much and is shared below.
Its unrealistic to expect an outsourcing team to have the same level of ownership and I believe that most conflicts arise out of mismatched expectations. Which is also why startups seldom choose to go down the outsourcing route if they have a choice to put together their own team instead. Writing software is a creative pursuit; its pretty challenging to get precisely what you ask for due to the lossy nature of communication.
I will always recommend putting together the best team over outsourcing. Let’s assume we’re going down the outsourcing route:
Do they want the business – yes? I’ll only recommend an outsourced company if I’ve either worked directly with them, or if a colleague I know well has worked with one. I don’t think an outsourced company will go out of the way to scam you on the project or anything like that as it will make an obvious impact on their ability and reputation to deliver to west coast customers.
Due to the language barrier / discomfort with western professional environments – you might find that when a project begins to fall behind schedule, some engineer will nod his head saying that a crucial task is complete, when in reality it isn’t. This has been known to happen and I don’t believe it is always indicative of malicious intent. Its more to do with our cultural make up. Here in India, professionals try to be over-sincere and don’t know when to say “no”. This attitude leads to icky situations where teams overcommit and under deliver. I don’t intend to sweep it under the carpet; but I can recommend that you need to watch out for this and proactively take steps against it.
Can an outsourced team make the difference between success / failure for a startup company? Success maybe. Failure – definitely not.
What you can do to mitigate some of the problems that can arise,
1. Start small (1 or 2 people) and build 1:1 relationships with the people on your team so that they have the freedom to focus on being productive.
2. Stick to an agile discipline with 2 week or 4 week cycles so that you don’t go astray and can get back on track when you do.
3. Be aware at the code-level as to what is being checked in, why, who, … . Peer code reviews are a great idea if you can get involved at that level. Hook your git repository to send out notifications on every check-in.
4. Keep communication voice-based as far as possible; this way you can bypass the language barrier and create healthy, direct communication lines between you and each member of the team. Try avoiding the tyranny of email if you can.
Over time, you can ease back on some of the above practices.
Finally, it pays to become the CTO for your product. I doubt if junior developers can help point out some of the larger arcs that could actually play a crucial role either in,
1. your product, the technologies used and eventually the ability to deliver on your business goals.
2. your team’s productivity, the tools used internally to help foster collaboration and efficiency.
If on the other hand you don’t have the bandwidth for the above. I’d say put your time and energy into creating clear specs and if stuff does go wrong I’d go back to what I said earlier that it isn’t the outsourced vendor who will determine success / failure of the startup. You always reserve the option to move on. That’s the nature of the relationship.
A side note, I have heard of people having better success with hiring talented freelancers from the odesk / elance crowd. Again this is anecdotal and your mileage can vary … wildly :).