Peter Clark's company started an offshore development team in India—it failed. Peter examines the underlying reasons for that failure.
In part one of this series, I discussed my company's first (failed) attempt to start a software development team in India. To briefly recap: We hired one of our competitor's software development managers based in India. He then visited the US for three months of informal training. Then he went back to India and hired a team of developers. We assigned him a project and received regular progress reports stating that everything was going well. When one of the developers that he hired came to the US to assist us with a project, we quickly learned that the Indian team had little or no prior software development experience. The team in India eventually quit. We then discovered that the system being built in India that was reported to be "nearly done" wasn't working.
So what went wrong?
Let me begin by saying what didn't go wrong. After part one of this series was published, several people wrote me about their impression that I was somehow blaming the Indian software industry in general and Indian programmers in particular. Nothing could be further from the truth. Indian software engineers are some of the best trained, hardest working software developers on the planet.
Several people also suggested that the root cause of the problem was a poor work environment or job insecurity. While these items certainly contributed to the team quitting, they were not the root cause of the problems.
The root causes of the team's problems were primarily found on this side of the Atlantic. They include supervision, team integration, training, and hiring.
When I hired the new manager, I paid insufficient attention to his training. Using the same techniques that I used in training all new hires, I assigned people to mentor him and gave him programming assignments so that he could gain experience with the application. This technique is adequate when the new hire will continue to have access to experienced personnel. But when that personnel is thousands of miles (and nine time zones) away, this system breaks down. The new guy can't just walk down the hall or shout over the cubicle to get an answer.
The method used to hire and train subsequent engineers was greatly flawed. The manager in India was trying to solve two big problems. The first of his problems was retention. Software turnover is a huge problem in India; talented people routinely jump ship after only a couple of years or months. The second problem the manger faced was the specialized application domain in which our company works. There just weren't that many software engineers, as a percentage of the engineering work force, with experience in industrial automation.
He decided to address these problems by hiring controls engineers and then training them to be software engineers. He believed that engineers who were trained at a company's expense would be less likely to leave for greener pastures, and that controls engineers already understood the application domain.
I believe that he dramatically underestimated the difficultly in training people with little or no computer programming experience. He made this problem worse by his training plan: he bought them some books on C++ and left them to learn how to program on their own. The trainees were given no real training on how to program.
Integration with the US team was a huge problem. The communication problems inherent in having teams nine time zones apart were made worse by resentment of the Indian engineers by the US team, who felt their jobs were threatened. This, in turn, made one of the Indian manager's tendencies, putting a "happy