For a couple of years, it was de rigueur for Silicon Valley software startups to offshore their product development, often at the insistence of their venture capital investors.
The goal was more developers for less cost, and for that, at least, it worked – small software companies could boast, “We have 80 programmers in Bangalore!”
But then the software industry giants (Microsoft, EDS, IBM, Oracle, SAP, etc.) opened huge development centers in India, with the goal not of saving costs, but to increase the size of their global development groups. So they sucked up the best talent with globally-competitive wages and their prestigious brand names, significantly driving up both wages and turnover among software developer talent. Wages for senior developers in some Indian cities rose 50% in 2004 over 2003, and there are now reports of an Indian tech-labor crunch.
Meanwhile, smaller software developers also discovered that working with offshore development teams involves a lot of overhead for oversight and communication that eats away at the cost savings, and slows things down considerably.
In a SandHill.com editorial earlier this summer, Michael Fields, CEO of KANA, gave a very lucid case explaining why his company “back-shored” software development, from India back to the United States.
In it, he explained that they had been working with an offshore software development partner, and they examined the real economics and software delivered from the partnership. They discovered that for the same total cost, taking development back in-house in the U.S. would improve time to market and allow them to regain control of their intellectual property.
KANA ended up hiring 1 American programmer for every 3 to 4 programmers in India, while achieving the same productivity. The perceived cost advantage of Indian developers was offset because they “had little control over who was working on [their] projects” and they had to employ a program manager for every five offshore engineers, including costs of multi-week travel to India every quarter.
In addition, one cost that Michael Fields didn’t mention but that we have discovered: When working with an offshore development partner, you’re also paying for their sales costs and management overhead.
A couple of years ago, we evaluated growing our development team through an offshore partnership. I looked at all the costs and found that, at best, we could save about 5% versus hiring here in Denver.
“Five percent, that’s all?” Yep, and here’s why:
- For a 3-5 years-of-experience Java developer in Denver, total cost is $120,000 per year including benefits, work space, tools, etc. (building software in the middle of America is a lot less costly than on the coasts).
- Rates through our partner for an offshore Indian developer with similar tenure was $20/hour ($40,000 per year).
- For a twelve-person offshore development team, we needed an onshore coordinator at $60/hour plus expenses (another $10,000/year per offshore developer).
- From past experience, we knew we needed several dedicated people on our team to provide requirements detail and clarifications for the offshore team, and to perform design and code reviews of their work (this added another $26,000/year per offshore developer).
- Also from experience, we knew that the twelve-hour offset in communications and the many clarification questions would result in rework and lost time by the offshore developers. We had seen up to a 2:1 difference in productivity on other projects, but I assumed only a 1.5:1 productivity ratio due to better communications and oversight.
The net-net was that an onshore developer was $120,000 per year, and the total cost of an offshore developer was $114,000 – a five percent savings. The wage inflation since then in India has more than erased even this small advantage.
Now, there are ways to make offshoring software development more workable – namely by 1) bypassing the partner’s markup and opening a wholly-owned offshore subsidiary, and 2) giving the offshore group complete ownership of a portion of the product that doesn’t require much customer interaction or onshore design interdependencies. Even with this approach, however, attracting and keeping good talent with the current feeding frenzy in India is, for a small software developer, a nigh-impossible task.
Which brings me back to the core topic: What does this have to do with Building SaaS?
Well, beyond the false economies, offshoring SaaS development simply doesn’t work. In my next post, I’ll review how our offshoring experiment ended up, and what we discovered that makes SaaS un-offshorable, in my view.
Look at this challenge from a Human Capital Management viewpoint. How will the offshore team affect your US workforce? The 'human' aspect while not as easy to quantify, plays a key long-term role beyond the success of your project, at the company level.
The impact of even a 'successful' offshore development project creates internal burdens and risks extending outside the project. Your current development team and those who interact with them (Marketing, Support) will also be negatively affected by:
* altered work hours
* communication delays
* additional travel
What is the formula for productivity loss by proxy?
Work frustration leads to burnout, feeds employee churn cycles and can result in key US developers leaving. When/If that happens, you have created a third party dependency based on offshoring, on a workforce that is even more unstable. That won't sit well with future US replacements, the investors who seek stability in resources or with HR having to cover the $50k+ cost of replacing the average employee.
What happens when the offshore expenses result in a loss? What is exposed and at risk with bringing it back into the US?
At a large company where economies of scale can make even the 5% savings look good on paper, it also pays to study the long-term viability of solution.
Posted by: Dave | September 15, 2006 at 05:43 PM