Tim on Leadership

Musings on Management and Leadership from Tim Parker

Why Outsourcing is Good

Outsourcing has been around for a long time, and while it has many bad associations for some in the technology field, it can be done successfully and result in much greater benefit than most people realize.  Typically, outsourcing is considered a way of moving jobs offshore to lower cost centers, and while that is true there are direct advantages to outsourcing.  A few quick examples will help show what I mean. 

First, for over fifteen years, I've worked with QA teams based in Vietnam.  There's approximately a twelve hour difference between  Vietnam and Eastern Time (plus or minus a few hours depending on where you are in North America and whether Daylight Savings Time is active or not).  While this may sound like a communications problem, with early morning or late night conference calls, it actually works out really well if you plan it properly.  Assuming you've got a good company to work with (more on that in other posts) I have found that the time difference is a wonderful thing.  In its simplest form, it lets my developers here in North American work through their normal day and check in code as usual.  When they leave for the day, builds are triggered and after a new build is completed, the team in Vietnam (mostly QA engineers) kick into gear and thoroughly test the new builds and post the results in the tracking tools we use (all monitored, reviewed and supervised by my QA team here in North America).  The developers walk in the next morning and have the QA results waiting for them, so they can tackle the problems quickly while the code is still fresh in their minds.  Contrast that to the internal QA department approach.  Developers finish code one day and check it in.  The next day QA tests it and posts results.  These are looking at by the developer one or two days after they have moved on to other code, and they have to loop back mentally.  It doesn't sound like a lot of an issue, perhaps, but over the years I've found this "code during the day and test at night" cycle to work wonderfully.  The developers are happy with the overnight results, things get corrected right away, and the code base is constantly under test.

A second example is a 24/7 monitoring system.  Before I outsourced to South-East Asia, I needed to have people watch our systems 24 hours a day, scanning for problems  on our systems and software.  This usually meant having to put people on rotating shifts throughout the night.  Needless to say the graveyard shifts were never popular and people often slept through their shift instead of working.  By moving our night-time monitoring to South-East Asia, I had a daytime-there set of eyes on our systems without having to have my team here stay up late and disrupt their normal rhythms.  Any issues were instantly conveyed through an escalation process that started with emails and texts and ended with live calls, all within a ten minute time span. 

Third, having a team of developers offshore also helped me break up the workload more effectively.  There are two approaches I used effectively.  The first was to send routine, almost boring, work offshore and have it done by developers there, leaving the more interesting bits for my team here.  This took away a lot of the drudgery and cost ineffective use of time (why pay a senior developer $50/hour when I could get good routine code done in Vietnam for $13/hour?) and my development team in North America was a lot happier about getting the challenging code, and leaving the framework and simple stuff for others.  Secondly, when I had faith in the developers offshore, I could run essentially two development teams in parallel.  I don't like having them work on the same bits of code (it takes too long to have the "other" shift learn what the previous shift did to the code), but it was fine to break up a project into many parts and let North American handle half, and Vietnam handle the other half.  Quality of developers offshore can be an issue, true, but with the right team all can be well.

Offshoring can save money, to be sure.  A typical Vietnamese developer with five years experience might be charged out at between $13 and $20 per hour.  A similar person in North America will cost several times that.  What that effectively means is that I can get more team for my buck.  Instead of hiring five junior developers here, I can hire ten (maybe more) senior guys in Vietnam.  I'll get more mileage from the offshore team and save money!  Sure, there are management issues with offshoring, but over the years I've learned how to select, remotely manage, and make an offshore team feel involved with the company, and that's the subject for other posts. 

The argument that offshoring costs jobs here is very true.  It does.  But, in many cases, it is the sensible thing to do both for productivity (as shown earlier) and cost perspectives,  and as any developer or QA engineer in North American will attest, there's not a lot of those folks without jobs right now.  The North American tech market is strong and there's no shortage of work, so I don't buy the "causing unemployment" argument against offshoring.  In the end, it all comes down to your experiences.  I've had very bad experience offshoring, but I've also learned how to do it right and had great experiences.