Having worked on offshore development teams and on onsite teams in America, I have experienced the dynamics and the obvious challenges on both sides of the fence. Many companies that are dealing with offshore development teams today are experiencing similar challenges, so it will help to understand specifically what those challenges are and how to at least try and alleviate them even if some are too daunting to be fixed outright. This article has a strong India tilt since I have lived there before immigrating to the USA. However, I have also worked with offshore teams in other Asian countries as well as Europe. A lot of the challenges that I have experiences dealing with India based teams are ones I have experienced with teams in other countries as well so the lessons here are pretty universal.
Starting my software engineering career in Bangalore back in 1997, I used to occasionally ride past the Texas Instruments aesthetic campus in my motorcycle. With contemporary buildings and lush green lawns the campus stood in stark contrast to the drab commercial structures housing mainly government offices sprinkled around the city. TI was the first global company to set up an offshore engineering center in India in the mid 1980’s. Faced with explosive growth in business and consequently its need to hire engineering talent, it ventured into India looking to address this need when no other global company recognized the country back then as a host for engineering talent. With more than 700 patents today and the footprint of the Bangalore team in a lot of its products, TI is entitled to feel vindicated for that decision. Once TI paved the way other multinational firms followed suite eager to benefit from the technical education combined with English language skills of a young workforce. At that point the low cost of hiring engineers was a pleasant secondary advantage but not the primary reason to offshore that it would later become.
Shift to a cost saving philosophy
Back in the day when IT offshoring started in India it was a manpower scaling model rather than a cost saving model. That is, companies that either sought out offshore partners or opened their own offshore development centers were mainly looking to fill the shortage of USA based engineers with Indian counterparts to design chips, write code for internet startups and enterprise software, maintain databases, perform medical transcriptions etc. In the 1980’s and 1990’s the cost and ease of setting up an offshore development center in say Bangalore wasn’t as cheap as today. Yes the salaries were much cheaper compared to an engineer in the US but there were offsetting factors. For example office space was limited and therefore expensive, telecom infrastructure was just beginning to get spruced up and in one interview Bill Gates even said he may need to get an airstrip built before establishing an offshore development center in Hyderabad because the air transportation infrastructure was inadequate. But over time air transportation (and connectivity) and telecommunication infrastructure improved and office space increased thus significantly lowering the cost and ease of incubating a development center. As costs lowered in India, US went into an economic recession during the internet bubble era. That’s when American and to a lesser extent European companies increased offshoring with cost as the primary motive. That was the point at which in my opinion quality issues experienced an increase. A number of issues and challenges that I outline below in my view are due to this change in incentive to offshore to lower IT expenses.
High employee attrition and turnover
When I say attrition, I am referring to employees voluntarily and frequently changing jobs after short stints. A lot of managers I talk to here in US refer to high turnover as the number one cause for concern. It’s obviously an issue for the company that offshored if employees get trained on a product and leave before making any meaningful contribution and new employees have to be retrained all over again. But it is a major handicap for an offshore employee too in terms of advancing their skills. When so much focus and time is spent on looking for a new job even before settling down in the current one, it leaves little time and motivation to hone existing skills and learn new ones.
Causes of voluntary employee attrition are partly cultural. In Asian society there is a trend of keeping up with – or even surpassing – the Joneses. Employees freely exchange personal compensation details among themselves and if a coworker or a buddy gets a higher compensation even if it’s only by a handful of dollars, there is instant compulsion to match or exceed usually by seeking a change of employers. While deep rooted cultural habits are difficult to overcome, the primary reason for attrition is really something else. In my view the main reason people change jobs is that they are not emotionally invested in the company or project they are working for. In other words they feel detached.
Feeling of detachment
It is much easier to break ties when those ties are weak in the first place. Offshore teams residing in a different continent usually share a loose bond with the parent company due to the geographical distance and the lack of face time and physical interaction. Video conferencing tools can go only so far. Additionally, the different time zones further complicate matters. If the parent company is in USA and the offshore team is in Europe there is a time difference of around six hours. If the offshore team is in China or India it is around twelve hours. Time differences and physical separation will instill a feeling of detachment in offshore teams and obviously not much can be done about it but there is another more important reason for an offshore worker feeling detached that is a result of the cost model I referred to earlier.
When I worked in Bangalore on offshore projects early in my career, at the commencement of any new project I was provided with the name of the customer, description of the task and some existing code and documents (if applicable depending on project state). Never was I ever briefed on the business need of the product/application I was working on or its importance to the customer. Often times it was a struggle to even acquire the functional specifications. When you are simply an hourly worker provided with piecemeal requirements and expected to deliver some working code every once in a while, it offers no incentive to develop a feeling of ownership. Offshore employees (for that matter onsite workers too) must be made to feel like they are part owners of the product/application and be invested in its success. If managers leading offshore employees are unable to create a sense of ownership among their cross-continent workers, it will lead to those workers cherishing compensation and benefits over technical challenges and accomplishments. In reality, creating a feeling of ownership in offshore teams is easier than solving the cultural or the geographic separation issues I discussed earlier, so it is surprising so many managers with offshore responsibilities fail to see this point. Even if it is less, offshore workers still do cost money and it’s in a manager’s best interest to make offshore workers feel part of a bigger goal. Something as simple a message as telling these engineers how critical the success of the project is to the parent company or organizations bottom-line may help. Quarterly or half-yearly visits by high ranking managers from the parent company and having one-one conversations with offshore employees (especially the stars) will go a long way in diluting any feelings of detachment.
Lack of mentoring
Whether it is software engineers in India or factory workers in China, salaries are gradually increasing thus chipping away at the cost advantage that companies enjoyed so far. To compensate, companies are resorting to hiring younger and less experienced engineers. It’s a universally known fact that lesser the experience, the more mentoring is needed for a worker to obtain adequate competency over time. Universally that is except in India, China, Malaysia or other Asian offshore teams that I have worked with. Traditionally, mentoring is an unknown concept in those parts.
If you are an offshore manager, insist on establishing a mentoring program especially for junior employees and ensure they are paired with more senior skilled developers. Reality is – some hand-holding is necessary for junior engineers regardless of their college education and aptitude.
Failure to employ competent architects on both ends
The Golden Gate Bridge in San Francisco (as any suspension bridge for that matter) has two massive towers on both ends of the bridge. Suspended cables that hold the road deck are secured to the towers and continue to run to the ground where they are attached. The cables transfer the weight to the towers which in turn transfer it to the ground. The towers are extremely important to the integrity of the bridge. If the towers have integral weakness, the entire bridge will cave in. There is no redundancy when it comes to the towers.
So why is this lesson on a suspension bridge relevant here? Because just like a suspension bridge needs strong towers on both ends, any project with an offshore team also needs strong architects on both sides of the continental divide. This is not easy to achieve but it is integral to a project’s success. The onsite architect will need to know the strengths and weaknesses of the onsite as well as the offshore team. He also needs to be aware of the cultural differences. Further the onsite architect needs to interpret requirements from the business/program managers and articulate in a language that the offshore architect clearly understands. Conversely, the offshore architect needs to be on the same page as the onsite architect, be able to translate requirements to rest of his offshore team and technically be responsible for the quality of delivery. In terms of skills both architects need to have relevant technical skills and experience, have good functional knowledge of the product/application, have excellent communication and leadership skills. It is touch to get all these competencies in one person but good architects have the ability to compensate for inherent weaknesses of a team so paying top dollar to recruit such an architect is entirely justifiable. Unfortunately, too many teams ignore this very important fact that really could be the difference between a projects success and failure.
Lack of proactive participation from onsite stakeholders
I need to begin this section with another personal story. Back when I was working in Bangalore in late 90’s, there was a project that was well into six months of execution but wasn’t going well. It was revealed that the customer basically punted the project to my employer and proceeded to take a hands-off approach. Six months into the project, after encountering missed deliverables and quality issues, a very exasperated customer flew down to Bangalore, fired the entire team of ten or so developers from the project and personally interviewed and installed a team of just four developers including a rock star architect. From that point on it was a phenomenal turnaround of fortune. The product that this new team churned was a spectacular success and won a few US patents (this was a web product back when web was in its infancy) and industry awards along the way.
Lesson learnt. If you go to a car dealership to buy a car, you pay the money or finance it and drive the car home. You don’t participate in its design or manufacturing process. Unfortunately, this approach of selecting an offshore vendor, paying the money and taking a backseat rarely works in IT. The dynamics of software development combined with cultural idiosyncrasies of offshore teams places the onus on the stakeholders to take more than a passing interest in their offshore development.
Undefined or poor processes and methodologies
Offshore companies especially those based out of India have traditionally been high on unproductive methodologies like ISO and SEI-CMM which are documentation and process heavy. Time and again it has been proved that simply possessing a SEI-CMM certification does not guaranty a quality deliverable. Even if it did, ISO and SEI-CMM are difficult to implement across physical boundaries and distributed teams. What is needed is a process that binds both the onsite and offshore teams and that which can overcome the time difference and physical separation. Also needed is a process that encourages partitioning requirements into small digestible tasks and which encourages code reviews and testability between both teams. Adopting a methodology like Agile with suitable tweaks to suit both teams may help. Using a robust tool like TFS that supports a distributed architecture which will help with the implementation of the selected methodology/process may also be a smart decision. Time differences and geographical distance are issues that cannot be solved completely but can be managed via a good process.
Offshoring and outsourcing of software development is here to stay for a while so these lessons that I compiled from personal experiences and talking to other developers, architects and managers should help improve the quality of your offshore teams. A lot of these lessons should come handy regardless of the country that your offshore teams reside. Actually, some of these lessons should apply even to near-shored/outsourced teams that reside in the same country or even in the same office.