Captive vs. Outsourcing?

Yesterday I attended the Boston TiE organization’s panel discussion on this subject. I was impressed (again): The moderator, Sandeep Kaujalgi, did a nice job of soliciting and comparing the views of the panelists; the panelists spoke from their real-life experience (not sales pitches); and there was a big turnout, with lots of interesting comments and questions coming from the audience, too.

Given the audience and the panelists’ experience, the discussion mostly concentrated on the software development needs of small software or high tech companies, who are offshoring development teams of perhaps 10-100 people — obviously a different set of needs and solutions than Fortune 500 companies looking to outsource their applications maintenance. Most of the panelists had worked with both captives and third party vendors, often in both India and China (and one in Israel, too).

It was striking to me how many different factors went into the decisions about whether and how to set up an offshore team, and whether to do so in India or China. In the popular media and business press, the focus is almost all about how to reduce costs, but the factors discussed here only started with lowering costs, and then ranged to the availability of specialized skills, whether the technology involved is core/proprietary or non-core/context, relationships of executives to individuals in India or China, interest and desire of key team members to return to India or China (more about that later), size of the team, availability of capital, need for flexibility/scalability, existing quality processes, and relative need for speed/reducing time to market. The key point, which Gil Kaufman made explicitly, is that there is no formula, no checklist that a business can use that magically points the way. Every company needs to design the solution that’s best for their situation.

What also came through over and over again is that the biggest success factor is not any specific initial decision, but how the organization implements its offshore strategy. My impression was that all of the panelists had had some successful (and some not-so-successful) experiences working with both captives and and third party vendors; some also had experience with hybrid and multi-vendor models. The big difference, cited repeatedly, was execution.

So what advice can we glean from their experiences? Here are a few thoughts based on my notes from the session:

• Think through the factors behind the decision to go offshore, and develop (and execute) a strategy that meets your specific objectives. If the biggest concern is finding a specific skill set, find a team that has that skill set first, don’t decide to go to India or China on the basis of some broad country evaluation. If the biggest concern is protection of your IP rights, don’t assume you shouldn’t go to China, think instead about setting up a subsidiary rather than working with a vendor, and then evaluate the best locations for your company to establish a subsidiary.
• Create a bridge between the cultures (both country and company cultures). This can be a current employee in your company who wants to move back to their home country (whether India or China or elsewhere) to lead the offshore team. It can be someone from the vendor who acts as an intermediary for all projects, helping US-based employees get introduced to the cultural nuances and understand how best to work within the distributed team model. It can be individual onsite and offshore team leaders who develop a relationship and maintain open communication channels.
• Focus on the relationships between the teams. Build trust, and work as partners. Get a visa, and meet your offshore team face-to-face! Dan Proskauer made the point that you’ll get the greatest value out of your offshore work if you are able to leverage each other’s strengths, such as the onboarding, training and quality processes typically found in Indian outsourcers, combined with the core domain knowledge of your onsite team. He also noted the onsite project manager’s skills with relationships, partnering, and cultural awareness are critical to the success of the offshore work.
• Plan clear, measurable outcomes. Check back and review progress often along the way. Don’t even imagine for a minute that you can send your requirements across the world and get your deliverables back in a few months!
• Understand the demographics and drivers of your offshore team (and your onsite team) and work with them. Indian developers typically have three to four years of post-university experience, while American IT employees are often older and more experienced. Figure out growth and career paths for both locations, and try to structure the work to help all team members meet their own personal goals. Steve Baron pointed out that if you give someone only dull maintenance work, you’ll get grouchy behavior, whether it’s the next cube or 6,000 miles away. In China, you’ll need to do more teaching, because it’s a relatively immature industry, and you’ll need to work harder to overcome the language barrier.
• One of the biggest destroyers of productivity is turnover. Understand what motivates your key players, and keep them engaged. Challenging work, onsite assignments, increased domain knowledge? One company negotiated with their vendor to pay a bonus directly to their team, if certain goals were met. Don’t underestimate the importance of company culture and reputation, too, and encourage team spirit and pride.
• Implement defined multi-site processes, whether you’re working with a vendor or a captive. Using common tools and methodologies that support collaboration is critical to getting productivity and value out of the relationship. However, as Anand Krishnamurthy pointed out, software development often requires creativity, and the factory approach used in the biggest IT services companies may not be appropriate for your project.
• Be realistic. It typically takes 6-8 months to set up a captive center in India, and perhaps 18 months to really see results. Build in time for management overhead and turnover when you estimate your costs, and plan accordingly.