Offshoring best practices


Recently I’ve met a lot of start-ups asking me about offshoring because of my freelancing model. For those of you who aren’t aware of what I do, part time I freelance for start-ups and other companies developing Drupal sites (because Drupal is amazing and can do everything!) Because I wanted to keep it part time I decided to go for an offshore model with my self providing the in-depth onshore expertise and project management (and getting the work) and then offshoring to a firm in Pune, India, that I met the founder of (very cool guy) while I was working in India a few months ago. It also has the additional benefits of working out much cheaper for the start-ups as their rates are about 1/6 of mine!

A lot of people are nervous about offshoring, and understandably, there are a lot of horror stories out there. But I believe with some best practices I’ve learnt over the past 2 years offshoring in both Thailand and India, it is a very viable route to go, especially when cash is tight, just as long as you follow a few simple rules.

First of all you have to appreciate the cultural differences when offshoring. Not only is it a difference in mannerisms, its also a difference in exposure to the same things we get here in the UK. For example, you may go to a developer in the UK and explain your really cool idea for an eCommerce site like, but then go to India and find half the people have never used or even heard of This makes a big difference when working offshore, and generally the test when picking an offshore firm/developers to work with is ask them to list both the sites they’ve developed but also more importantly the sites they use daily for themselves! You know if a developer says he uses Twitter everyday, this is a proper web geek who’s immersed in the Web 2.0 culture, because while we may hear about Twitter or similar services everyday, its basically unheard of in the rest of the world! This is the main reason why people find it hard working with offshore developers, because they just don’t “get” the concept of your site, and as a result take longer getting up to speed and also find it hard to add any value to your service like some of the creative London developers can who understand your concepts and come up with great ideas to make it better! I’m hoping with my freelance model, to get the best of both worlds, with me providing the insight and creativity, and India doing what they’re good at – developing quality code cost effectively! Saying that, you may be surprised how versed some of the firms out there are, definitely the firm I’m using is exposed on a daily basis to cutting edge sites and understands the space we work in, so look hard and you will find diamonds in the rough…

The second cultural differences are mannerisms. One thing that is common in most Asian countries, is hierarchy. You’re the client, so you are king, and they have to make you happy even if its impossible. That means when they say Yes, it doesn’t always mean yes, you have to figure out if they really mean “yes we can do it by tomorrow” or “yes we’ll try our best”. Usually you can tell I find by how positive the response is, really positive (definitely yes) means yes, not so positive (sure, we’ll do our best) means you’ll have to give them more time. While different countries vary, what is common among all these countries is if you get them to explain back to you what you just said and they say it back perfectly, you’re probably OK.  (see how I said probably, which means good but chance it may not be, that’s what you have to look out for!) Don’t expect them to be direct like we are in the west and just say NO!

Another thing to take into account is time-zones. While India and the UK is an acceptable 4.5 hours time difference, if you offshore to the far east (where the developers are excellent!) you will have a less acceptable 8-12 hours time difference. Basically when you start work, they finish! Without overlap you won’t be able to chat and sort out any questions or issues in real time. Also you have to think about time zones in everything you plan other than meetings, like deliverables. If you have to provide an urgent design spec for Thursday, you actually need to finish it Wednesday night, as by the time you wake up on Thursday and send it over, even if first thing, India has just wasted half a day waiting around for you to send it! Unproductive time that adds up over the project and causes delays! Fortunately most offshore firms understand they have to work around the onshore team (client) rather than the other way around so most will stay late in the office to have meetings and overlap. Another thing to solve this issue is work in a closer time zone, Eastern Europe also has some very low cost developers who are only 2-3 hours and an £80 flight away if you need to visit. Something to bear in mind if this is a real issue for you!

So when setting up an offshore project this is all the things I require to ensure the project runs effectively:

  • An offshore project manager to mirror myself onshore. That way there is a point of contact and more importantly responsibility to make sure the project stays on track if shit hits the fan!
  • An online workspace to share documents such as Basecamp or Huddle so that you’re not emailing back and forth documents between the onshore team and offshore team. Also some of the other collaboration features of these solutions allow you keep track of tasks, deadlines and conversations the team has had so there is always accountability (essential for any projects success!)
  • A publicly accessible code repository (I prefer SVN) so you can do code reviews, and issue tracking software (we use Mantis) so you can monitor and add bugs you find.
  • A public place to host the site as it’s being developed so that the onshore team can see features as they’re being developed to give immediate feedback and even get some advanced UAT testing done to save time down the line.
  • Get all the developers Skype/MSN user-names and add them to your contacts so you can talk ad-hoc during overlap hours.

The most important two things to take away from this is accountability and transparency. You need to make the offshore team accountable by setting CLEAR expectations upfront and having a point of contact who can make things happen if things screw up, and also transparency so you can see everything the team offshore is doing to catch issues early. I usually ask the developers to first do the basic configuration and templating for Drupal, so the client can see the site as it will look as soon as possible and then add the development on top of that as it becomes ready. This allows for a semi-Agile development process that keeps things on track and even saves time on testing and bug fixing later down the line. While it can be risky to show the client things before they’re ready, as long as you set their expectations clearly that they’re seeing it as-is and untested, most clients would prefer to see the status of development visually just by going to the development site.

Lastly, status reporting. We use daily status reports from the developer saying what was done that day, any issues, what is planned for tomorrow and any questions about the work itself (like how some feature is supposed to work). Followed by daily chats on Skype/MSN, and weekly/bi-weekly conference calls, you can keep a track on whats going on, close issues fast, and most importantly actually feel like you’re working together instead of two anonymous parties who’ve never met! Some of the offshore developers are actually very cool and you may even become friends!

Anyway, I think that sums it up for now. Overall its like anything “new”. I’m comfortable because I’ve done it for 2 years now, seen it work and know the mistakes that can happen. Other people just can’t imagine working with people in another time zone, country and culture, and for that there’s people like me to provide the best of both worlds and hand hold them while they take their first steps into offshoring…once you start you’ll never go back! 🙂