During my job search, one of the questions I often got from prospective employers – especially VC firms was – can you help us reduce development costs by offshoring to India? For most of them, I advised to exercise caution. It was not the right time for all of them. Here I will write down my learning from offshoring work to India.

This is based on my personal experience of having offshored work to my India organization for the last 8 years. The peak size of my team there was around 250 in product development and 350 in services. Other than this, I had about 100 partner resources working in India too. China and Hungary were the two other offshore centers (although much smaller in size) that I had. (Rest of my team and I were based out of US).

What I am very impressed by is the quality of people in India. My experience there (as well as in China and Hungary) is that there is a huge supply of highly intelligent people. They are typically very hard working. The work culture seems to be oriented towards putting in long hours. With the proper guidance and leadership, and a little encouragement, they have moved mountains for me. All this at about one-fourth my cost basis (compared to US).

Two different types of work

Having said that, I need to add that I saw great success with one kind of work and only mixed results with another. Let me explain the two different types of software work that I have seen in all companies. First you have the project oriented development. These are typically turnkey projects. Requirements are nailed down upfront once and for all. And as changes happen to the requirements, you have a rigorous change management process to deal with extra money and time. After the development is over and the software is “live”, usually, it gets into maintenance mode with small incremental changes over time. Most importantly, such software is targeted for one customer and typically one target IT environment (operating system, database, UI technology etc.).

I have found that India is very good in this. For the last 35 or so years of offshoring experience that India has gathered has been almost entirely in these kind of turnkey projects (if you take out the body-shopping aspect of the industry). Which is why, Indian companies have been in the forefront of adopting project-oriented processes like SEI CMM models and such.

The second kind of software work is product oriented development. This is where you have a “continuously” worked-on piece of software. There is no one big completion date and then ongoing maintenance model. Typically you have many completion dates (called releases). And there is no final list of requirements. Through the life of the product as the market and customers evolve, new requirements are generated. You don’t budget the activity as a project. Instead, typically, you have a fixed capacity to deal with – and now you figure out how to prioritize your requirements to fit the next release capacity. All software product companies have this model.

I am rather unexcited by my experience with India on this front. Since this is where most of my learning was, let’s try to understand why IT companies in India don’t excel (yet) in this. Before I get into that, I must hasten to add that there were 2 companies – both very small – who absolutely stood out in their ability to understand and deliver to the product oriented development. And I had the opportunity to partner with them both. But that is 2 out of probably 100 companies that I have had the chance to interact with.

What explains the difference?

First and foremost, the nature of work is very different in the two models. In the project oriented environment – typically a lot of things are spelt out and the development engine in India is focused on “doing it”. You basically code to the customer’s stated requirements. But if you are writing a product, you have to think a lot more. Good software architects become good not by designing to a requirement but being able to think thru what else might be required in the future and therefore design today such that anticipated future requirements can be put in easily. You don’t get a chance to say – “None of my older customers had required this – now I have to totally redesign the architecture”. This means the key developers need to be much smarter and more importantly understand business domain. Most of the people I have interacted with in India – are great developers – but not what I am talking about here.

And that is not all. Remember, we talked about the target environments? When you are writing a product, you have to design it such that it can work with multiple languages (think double byting), on multiple platforms and multiple middleware choices. That requires far higher level of abstraction in your thinking and design. That is not the experience typically people have in India.

Finally, don’t forget the people angle. India (like China, Japan and other countries in Asia) has a background of hierarchical society. The social ethos of what is important and what is not important is very different from what you may be used to in the US. Typically, for any average person, being a “manager” is the immediate goal in India. After that is “how many people report to me”. Being a country with a very large population and much fewer resources, the DNA is built in the people to be very competitive and fight hard to rise up the hierarchy. Most of the software developers I have interacted in US don’t want to be managers – often have a healthy level of cynicism towards them – think Dilbert! In India therefore, it is very difficult to have people work on the same piece of code year after year. Their career motivation continuously makes them look for a “development manager” job or move to offshore services work to be a “project manager” or even better international assignments. Being a great architect is hardly ever a career goal for them – and I do not blame them for it – given what their peers, market and society values. (Just look at the compensation numbers between the top technology person and the manager in any team). On the other hand, how can you be good product developers developing great products if you don’t stick to the code for a long time and have the knowledge and history of why certain design decisions were made?

What can I offshore then?

First, you should not pass up on the opportunity to leverage the great tool offshoring is. The price arbitrage and quality of people is too high not to think about it. Just make sure you are offshoring the right parts of your operations, though. While the cost difference is great, there is additional cost you take in terms of more rigidity in process of communication and handoff between teams separated by a couple of oceans, training costs, attrition (and therefore re-training) and the like. Do not focus on how many dollars you are spending in either scenario – focus on what will you get for a dollar. “n” people in a team often outperform “4n” people in another team – especially as “n” tends to be smaller. (4 represents the cost multiple).

Look at which aspects of your software development are more commoditized than others. If you are a typical enterprise software development company, start with the services side. Your usual customer implementations exhibit all the characteristics of a project based execution. Requirements are nailed down early on; you typically have a “go live” date and then move on to maintenance. There are a large part of this work (especially between post-requirements and customer site testing phase), that can easily be packaged and moved. As an example, a lot of custom development, data work, model building work, testing work can be easily done from India.

If you are a services company, obviously, this is a no-brainer. I suspect you are under enough price pressure and customer pressure that you are doing this already.

For the software development teams, I strongly advocate against doing this till you are about 15 people (development team) strong or so. After that, you start looking at those parts of the work which are easier to package, are reasonably commoditized, and can be managed even if the team members change every 2 years or so. Examples of these are bug-fixing teams, internationalization teams, quality testing teams etc. Also, if you have a long list of nice-to-have features which need smaller changes but you never get a chance to prioritize them high enough – they would be a good candidate too. It is very important to point out here that it is highly desirable to ensure that you have a source code control system and regression testing framework that can work across multiple sites – or else you are going to have a lot of fun merging work of multiple teams and then coming up with errors too late in the game.

After you have reached a size of 30 or so, you should think a little more ambitiously. If you have a portfolio of products, pick out the ones that have reached reasonable amount of maturity and most of the development are incremental development. If you have one product, identify the modules that don’t need a lot of understanding of domain or day to day handholding – e.g. framework layers. Finally, if you are thinking of doing next version (new architecture – not next release) of products, move the old product to India and do all the new product in one location (even if you bring people from outside) rather than trying to do some part of the development from offshore from the very beginning. I saw a few teams succeed with this model (right from the beginning split work between India and US) but my opinion is it has been a far more costly and slow.

In essence, the size of the team and the nature of the work will drive your decision.

Those were my learnings. Feel free to add in your comments or learnings…

Rajib