In my last column, I identified four primary areas where things went wrong when I first tried to start a software development group in India: supervision, team integration, training, and hiring. (To read more about these experiences, read "Lessons Learned about Starting a Development Group in India," Part 1 and Part 2).
The New Plan
The general outline of our revised plan is as follows: Create a liaison position here in the United States, who is responsible for the initial training of the offshore team in India. This person travels to India and participates in the hiring process. (Our goal the second time around was to hire four or five software engineers, assuming that we would be able to retain three or four).
Our liaison then stays in India for three months as the people who come onboard acquire US training visas, which takes about four to six weeks. Afterward, the entire team travels to the states for a combination of in-house and third-party training. Once that training is complete, the liaison travels with the team back to India, where he stays for six months to mentor the team as they work through their first project. Finally, he travels back to the states, where his primary responsibility becomes acting as the technical and business interface between the two development teams.
I've discovered several advantages with this plan. First, the liaison is largely dedicated to making sure that the needs of the team in India are being met by the team in the US. Second, this person works with the team for more than a year to ensure that the best practices established in the United States are followed offshore and that the team doesn't drift off the rails. What's most important is that the liaison has the technical, domain, and process experience necessary to mentor the team.
Prior to our trip to India, we reviewed several resumes and conducted several phone interviews, which was very difficult for several reasons. Language and accent barriers made communication difficult. This was compounded by phone problems, as there is often a pronounced delay or echo in phone calls to India. We attempted to improve this by having one of our engineers in India in the room with the interviewees to help smooth over communication difficulties, which had mixed results.
Behaviors of the Indian Job Market
We arrived in India in early August. This is the monsoon season, and I fully expected continuous torrential downpours. Instead, I was created by a climate like San Diego, with nightly rain showers. The streets were alive with a mix of motorized rickshaws, small motorcycles with a family of four aboard, buses and cars, mixed with the occasional cow. All honk their horns continuously (except maybe the cow), and managed to fit twice as much traffic in half the space as an American city.
When we reached our office in Bangalore, there was a large stack of new resumes for us to review. I was immediately struck by the amount of "job-hopping" that was going on amongst the applicants. The average stay in a job was a year or less. Repeated durations of six or even three months were not uncommon. Retention was going to be a serious problem, especially when it takes up to six months to train someone in all the specialized technology our products use.
Two-pronged Attack
I met with the engineering manager and discussed the situation. We decided to attack this problem in two ways: first, we would pay our personnel a salary equivalent to the top end of the local wage scale. Second, we rejected applicants with excessive job hopping and focused on applicants who spent at least one or two years in each position listed on his or her resume. He was also able to give guidance on applicant's schooling, rate their schools on a scale of one to five.
We used a two-stage interview technique: Applicants were given a quick technical screen on the key technologies of our product, and those who did well on the technical screen were given a longer interview to probe their knowledge and experience in key processes, especially testing and leadership. The face-to-face interviews were much more successful than the phone interviews, and our ears quickly became acclimatized to the local accent.
During my two-week stay, we developed a prioritized list of possible candidates and left the final salary and benefits negotiation to the engineering manager. Within a week of my departure, we had four confirmed candidates. They were to start four weeks after accepting the job (the typical notice given in the Indian software industry).
Both the liaison and I had a wonderful time in India. The people were incredibly friendly, and really went out of their way to make us comfortable. We were taken out to dinner, shopping, and site-seeing. I even got to ride an elephant!
Filling Time
While waiting for the engineers to start, the liaison obtained and configured a test server. He also purchased laptops and software for each of the engineers. The plan was to have these arrive prior to the engineers' start date. However, it took much longer than anticipated to get the hardware through customs, so in actuality they arrived about two weeks after they started.
While waiting for the visas, the liaison started the training process. He took them through all the different components of the system, explaining what the components did on a high level. He was also sensitive to finding gaps in their technical knowledge, so that we could schedule any required third-party training back in the states.
Coming to America
The engineers arrived in the states in late November. I am afraid that they had a more difficult time adjusting to the weather, with the winter being one of the worst in recent memory for snow and ice. A first priority was making sure that they all had adequate boots and coats.
We got them two furnished apartments in the same complex. We had hired two men and two women, so the men were in one apartment and the women in another. The liaison was given a mini-van to transport them in, so there were no issues with learning to drive in the states.
With the engineers and the liaison in the US, we started their training process in earnest. We first gave them a relatively simple programming assignment and used the results to assess their technical skills. Based on our findings, we decided to schedule them for further training in Windows and SQL Server administration, as well as a refresher course in SQL.
Training in the states was split into two parts. The first consisted of a combination of classroom training on various aspects of our systems, combined with practical exercises in configuring and testing our software. The second part consisted of creating a "fake" project for them to work on with minimal guidance from their mentor. This project was designed to replicate what it would be like if the team made actual modifications to all major aspects of the software.
New Leadership
Prior to the start of the fake project, we identified one of the team members as the future supervisor of the team. This person started one-on-one training on the supervisory process. We covered the project lifecycle, estimating, planning, and project tracking. When the fake project kicked off, the supervisor was given overall responsibility for the organization and execution of the project.
The mentor and I continued to meet thrice weekly with the new team supervisor for the duration of the project. During these meetings, we reviewed how to handle typical planning and tracking tasks. We also came up with a methodology for her keeping me informed of their progress on projects. This involves weekly updates on tasks, a monthly project review.
In addition to meeting with the supervisor, we instituted a daily "stand-up" meeting for the entire team. In this meeting we covered what they had worked on the previous day, what they were working on that day, and what problems or obstacles they had encountered. The supervisor was responsible for running this meeting.
There were several advantages to having the engineers in the states for a long stay. Other than the training they received, they were able to develop personal relationships with the rest of the staff, and learned who they should go to for particular technical questions. Communication also improved, both as the Indian engineer's English got more exercise, and as state-side team members got used to the accent.
When it was time for the team to return to India, the fake project was well underway. The team completed coding and integration and tested the system on the hardware they had previously configured. During this time, we supplanted the liaison with the supervisor.
Finally, we started giving the team "real" project work, which the supervisor was responsible for planning and tracking. We continued to have meetings three times per week to discuss progress. When it was time for the liaison to return home, the team was functioning well enough on its own.
Even now after much time has passed since the team was in the United States, there are still issues that we need to address. There is still a level of distrust on the part of state-side members. This seems to particularly affect those who had little contact with the Indian engineers. I believe that this will continue to improve so long as state-side team members aren't given reason to think that their jobs are going to India.
The first time we tried to establish an offshore team, I tried to handle the team creation process as "business as usual." I tried to use the same process I typically use to train new team members. I failed to realize how difficult it would be to train a team to be sufficiently independent, nor did I realize how difficult it would be to monitor progress from nine time zones away. The second time I planned for double the training than was previously done and made sure that there was a team member whose job was to make the new team successful. Putting a committed, caring person in this role made all the difference in the world.
