 |
Software Testing & QA Online Community > Detail: Lessons Learned about Starting a Development Group in India, Part 2
| A StickyMinds.com Original |
|  | |
Lessons Learned about Starting a Development Group in India, Part 2
By Peter Clark
   
Summary: Peter Clark's company started an offshore development team in India in 2005. It failed. In part two of this three-part series, Peter examines the underlying reasons for that failure. To get a better understanding of where the failure occured, he focuses his retrospective on the proceedures he had in place for hiring and supervising his off-shore team, for integrating that team with his US team, and how he trained the off-shore team. | | |
|
|
 |
 Hear more about this topic in the StickyMinds SoundByte podcast interview with Peter Clark.
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 face" on everything, worse. When he ran into problems, he didn't share them with the team in the US, but tried to fix them himself. All the while, the trainees that he hired had no contact whatsoever with the team in the US. They had no personal relationship with the US developers, which just increased their sense of isolation.
The greatest problem was supervision. Not the supervision of the Indian manager for his team, but my supervision of the team in India. Even though the manager and I spoke regularly, I had no idea of the problems that he was having or of what was going on with his team--how he hired them, how he trained them, or what they were doing. While I had some knowledge of the integration issue, I took few steps to mitigate it.
The single most important thing I learned from this episode was that geographically dispersed teams require much more supervision than co-located teams. This need only increases when you factor in language and cultural issues.
When I talk about supervision, I am not saying that I should have micro-managed the team in India. That would have just created a different kind of disaster. Managing a remote team in another country requires both a different quantity and quality of supervision than managing a co-located team. It is necessary to structure things so that you naturally get accurate visibility into what is going on without micro-managing the team.
In short, the failure of the team in India wasn't primarily a failure of the team; it was a failure of management. I did not properly gauge the risks or creatively ensure that I had an accurate picture of what was going on. The greatest failure wasn't the team's or the manager's; it was mine.
In the final chapter, I'll explain what I did differently the next time.
Click Here to Read Lessons Learned About Starting a Development Group in India--Part 1.
Click Here to Read Lessons Learned About Starting a Development Group in India--Part
3.
About the Author
Peter Clark has twenty years of experience in industrial automation. He currently manages teams working in materials handling, especially baggagehandling systems. A regular columnist on StickyMinds.com, Peter can be reached at pclark@jerviswebb.com.
Back to Top
|
