7.2 Case narrative

Sierra is a small but highly profitable and rapidly expanding software house with offices in London (the headquarters), Brighton, New York, California and Bangalore. Sierra specialize in the development of short-life-cycle custom-built client server projects with customers and projects in a wide range of domain areas. In 1998, they had particular strengths in visual interface design and in 1999 moved into e-commerce development.

In 1998, Sierra employed 80 staff worldwide and company turnover revenue was approximately & pound ;8 million. Like many other specialist software houses , Sierra management were striving to overcome skills shortages and capacity problems in the UK. Their response was through a GSA arrangement in the form of a wholly owned subsidiary in Bangalore, India. Sierra believed that they could not pursue their strategy of corporate growth at their desired quality levels if they depended only on the development resources within the UK. The primary problem was the high salaries required for qualified staff.

Sierra s first move into India was the outsourcing of small projects to Indian software companies and involved some degree of ˜body-shopping Indian staff into the UK. A key problem in these early attempts was the large variability of quality because of the frequent movement of developers. Another problem was that the outsourced staff was not integrated into the Sierra culture “ incentive schemes offered to Sierra staff were not offered to the Indian outsourced staff, for example. The differences were uncomfortable for actors in both organizations, and as time went on the development staff become factional.

Sierra felt that problems of inconsistent quality and cultural fragmentation could be addressed by opening up their own subsidiary in India. Following initial experiments with outsourcing, Sierra management was confident that the necessary skills to do software development were available in India, but to do it effectively there was a need to control the operations closely. A decision to open the India centre was taken very rapidly, based on a hastily constructed business plan. Within three months, a subsidiary was opened in Bangalore in 1998, with a modest growth plan from 10 to 24 people in 18 months. Early projects in Sierra varied in size and scope but all were short-life- cycle projects involving mainly data warehousing and interface design. We describe the process by which the GSA relationship between the UK headquarters and Indian subsidiary developed in two periods: a growth phase (1998 “9) and a failure to stabilize phase (1999 “2000).

Growth phase and attempts at stabilization (1998 “1999)

The manager of the Indian subsidiary (whom we call Mitra) was of Indian parentage, born in Kenya and raised in England. He had a computer science education. Mitra and a colleague of his, who had been involved with Sierra s earlier outsourcing attempts in India, were responsible for setting up the Indian centre. These earlier experiences seemed to have provided Sierra with very little local contextual knowledge and no subtle understanding about ˜the way things are done in India. Mitra s view of the easy transfer of knowledge embedded in processes, and of the organizational culture, was important in shaping subsequent project events. Mitra adopted a broadly ˜information processing view to knowledge transfer and believed that, armed with videoconferencing links, the Bangalore office could be made to mirror a ˜little bit of Sierra in India. Such a view reflected a gross underestimation of the complexities of bridging two diverse communities of practice in the UK and India.

The hastily conducted business plan justified the setting up of the centre on the superficial basis that the ˜ streets of India are paved with programmers , rather than on a deeper contextualized and realistic understanding of the complexities involved in attracting , retaining and motivating the programmers. Such insights would require an understanding of local nuances such as the nature of work practices of Indian developers. Maybe it was felt in Sierra that Mitra, with his Indian parentage, could bridge some of the knowledge gaps shaped by various contextualized processes. But Mitra had never really lived in India before and his frame of reference was very strongly UK-focused. The lack of understanding of local nuances and complexities led to great frustration in the early stages; for example, Sierra did not realize the need for a ˜middleman to negotiate with the Indian customs officials to release their videoconferencing equipment. The delays that resulted caused both shock and frustration and the starting of a realization that videoconferencing technology on its own would not be enough to connect India and the UK.

A significant issue in Sierra s initial plans was for the Indian team to take on whole- life-cycle projects including customer liaison. Unlike many outsourcing arrangements to India, Sierra s was innovative and willing to take risks by trying to establish a direct interface between the Indian developers and the end- clients in the UK. The belief was that distance could be made invisible under the assumption that the requirements could be easily encoded and transmitted using technology (such as videoconferencing, Netmeeting and email). As one person remarked, ˜geography is history , and the Bangalore centre could be made to operate in a seamless way, appearing to their clients as Sierra UK. Usual procedures in the UK which involve regular face-to-face meetings with clients every 10 days or so would be replaced by a telephone connection through a leased line so that customers did not have to pay extra, which in turn would encourage communication. This model of communication was innovative as it was contrary to typical outsourcing relationships. These relationships usually start with small projects on-site at the customer s premises until sufficient knowledge is built up of local products and processes, and then some part of the development is moved offshore. Nevertheless the two expatriates felt that the knowledge gained through their early outsourcing experience, together with the ICTs in place, could substitute for the need of a face-to-face presence. They felt that knowledge could be effectively transferred. The knowledge issue was also compounded by the departure of Mitra s UK colleague who had worked on the Indian outsourced projects before 1998; he took with him some accumulated experience of doing work in India over the previous few years .

By the end of 1998, the Bangalore subsidiary had engaged in some full-life-cycle projects but even in those instances videoconferencing had not offered the levels of interaction hoped for. Technical reliability problems with the Indian systems “ for example, frequent power failures “ were a problem. Also, the only videoconferencing link was to the Sierra London office. This meant that Sierra s customers, who typically did not have access to videoconferencing equipment, had to travel some distance for the conferencing session. This was inconvenient as Sierra s customers were often located in other cities. The effective use of videoconferencing with customers thus required a great deal of logistical coordination of activities in terms of both time (difference) and space (multiple locations). The Sierra management had underestimated this need.

Communication difficulties also led to further problems in the transfer of information and knowledge. The UK customers and Sierra UK development staff found the ˜strong Indian accent difficult to understand. The difficulty was not helped by the unreliable videoconferencing and audioconferencing and emails which provided limited clarifi- cation and supporting gestures. The Indian team was sent on courses in the evening to ˜correct their accents, a process not liked by some. During an interview, one developer would switch between an ˜English and ˜Indian accent when speaking to the British and Indian researcher, respectively. When asked about this, he replied that he has two accents, one for working with the UK clients and one for home.

In one ˜success story related to us, a majority of the early life-cycle work (analysis and design) was done by an Indian developer who travelled to the UK client site for a few months to facilitate the process of eliciting requirements. The developer felt that such face-to-face contact was needed to reassure the customer and relate to the richness of the requirements. The initial interactions provided him with a shared frame of reference with the UK side, which helped to continue effective technology-mediated communication on his return to India. Maznevski and Chudoba (2000) have emphasized the importance of such initial face-to-face meetings in establishing a ˜temporal heart beat based on which subsequent meetings can proceed, even in conditions of temporal and spatial separation.

In addition to the problems of dealing with the time “space complexities in enabling effective knowledge transfer (see also chapter 6), there were further issues arising from the UK staff s perception of the Indian approach to problem solving. Owing to the dominant technical perspective, Mitra felt that the Indians ignored the equally important aspect of business requirements. The UK staff felt that the Indians overestimated their technical expertise, often reinterpreting the design requirements incorrectly, and sometimes unilaterally changing and removing things to deal with ambiguities . A UK developer said:

He [the Sierra India developer] didn t think it was important that things had to work in a very particular way. If there was a grey area, it was his job to make it not grey any more by implementing it in a certain way that unfortunately was not aligned with the original design.

These issues of ˜incorrect reinterpretation were magnified by the cultural embeddedness of certain assumptions concerning knowledge. Given its orientation of a small, global, high-tech company, Sierra UK had strong cultural norms about creativity reflected in their perceived ability to ˜self-start and ˜think outside of the box . The Sierra UK staff were expected to be able to use the software analysis and design techniques flexibly and think independently largely without supervision. They took pride in this ability. Mitra s and the UK-based senior managements perspective was that such creativity was absent in the Indian developers who lacked a ˜spark , and were unable to ˜self-start or formulate ˜self-directed learning . In the words of a senior UK manager:

It is a sweeping statement, but in India they don t tend to think outside of the box, they do what they have been told to do. And what that means is that if you miss something or something doesn t quite add up, they won t see it as a problem. They ll take it as read that that is what to do. So you have to be aware of that problem. I think that they will see there is a problem, but think that it is all sorted out. We want to encourage the developers to think outside of the box and to raise questions and issues.

Sierra s expectations, based on their previous experience in the UK and the USA, were that the Indian staff would be able and willing proactively to access and develop their knowledge of the technical products and user needs. Instead, the Indian staff was perceived as complying with methodology in a mechanistic, unquestioning manner. This was regarded as being an outcome of an emphasis on technical skills in the Indian staff as opposed to the lively, independent thinking, intensively questioning UK and US employees . In India, Mitra took particular measures in an attempt to remedy the problems by tightening recruitment with UK-style personal qualities overriding technical skills as a first requirement. In Mitra s view the Indian staff approach to problem solving might be questionable but Mitra s approach to evaluating creativity was also questionable. It was based on a ˜Western frame of reference. Mitra himself could be regarded as being uncreative, and not ˜thinking out of the box to understand the local norms of creativity.

The UK management believed Sierra India should mirror the non-hierarchical, freethinking, informal and creative organizational culture of the other Sierra offices. Inter- views conducted in the UK revealed the office to be laid out for ˜hot-desking and senior people would normally dress informally and share desks with junior staff. Mitra had high expectations of this informal, non-hierarchical structure being replicated in India and was very disappointed with the lack of success of his efforts to transpose the ˜Sierra culture and mirror this in the India operation. There were continuing problems with staff relationships and communication as Indian staff behaviour was seen to contrast starkly with the UK style of operation:

The London office is much freer. A typical example from the UK might be when someone joins us we open a bottle of champagne . People casually mill around, say hi and move on. Here in India I am expected to make a speech. 20 per cent drink, 80 per cent don t. We have some soft drinks for them to get people to loosen up. In the UK everyone drinks.

In a continuing effort to facilitate transfer of the Sierra UK organizational culture, staff from both locations were taken on a trip to the seaside resort of Goa in late 1998. However, this rather ˜synthetic attempt to create a relaxed atmosphere overall was difficult to translate into the reality of the office. Sustaining it in day-to-day office work was difficult because of the deeply culturally embedded nature of the work practices. Attempts at socialization between UK and Indian staff through informal talk (as in the case of Orr s Xerox technicians during their breakfast meetings) was limited in the ICT-mediated settings. The time difference between India and UK also meant that Indian staff felt excluded from the everyday activities of the UK staff. High staff attrition, a characteristic of the local context in Bangalore, also meant that a lot of energy was expended on constantly building new relationships and trying to repair the loss experienced in the knowledge base through staff departures. The UK staff working with Indian split teams indicated that communication problems were further compounded by the tendency of the Indian developers to avoid saying ˜no , asking few questions and saying they understood when they might not have clearly done so.

The strategy of raising the technical expertise level by recruiting graduates from the more elite educational institutions also faltered because Sierra, being a small firm, could not hire a full-time HR manager. Mitra had to handle the personnel functions together with an Indian senior technical person. As a result, they could not invest adequate time actively going out to recruit from the major Indian university campuses where they faced competition for developers from the larger and more glamorous software houses of the MNCs. Sierra was thus left recruiting graduates from some of the second- and third- tier colleges where the primary focus is often on building technical skills rather than on broader education, emphasizing a ˜technical rather than ˜business kind of focus. Also, the skills of these graduates were rather outdated , with a majority of them having had their programming courses on COBOL, with little or no experience with newer languages like Java and Visual Basic. These outdated skills of graduates, coupled with their perceived inability to self-start and engage in self-directed learning, led the Sierra staff to believe they were spending far too much time on building the knowledge base of the Indian developers, which should have come as a given in the relationship.

The perceived continuing inability to transfer the Sierra UK ˜relaxed working environment had direct effects on the software development process. In Sierra UK, power relations were based on technical knowledge rather than hierarchical position in the company. It was considered legitimate for highly volatile ˜creative discussion to take place in meetings that were an integral part of problem solving. In these meetings a junior developer would feel they could openly contradict a senior member of staff. Mitrafelt that in India the hierarchical position or ˜tag and related issues of status, title, rank and position were more important. Thus for the Indians hierarchy and position was relatively more closely related to knowledge: an older, senior manager s knowledge would have greater importance than that of a colleague or junior. Mitra s and the UK developer s view was that hierarchy was absolutely unimportant when problem solving: Mitra told us that he was uninterested in titles and rank and only in what ˜someone brings to the table in terms of direct contribution to solving the problem or issue at hand. This different status on knowledge had knock-down effects in the managing of ˜creative meetings both face-to-face and electronically mediated. Mitra repeatedly complained that in India he did not witness similar types of ˜creativity, and the nature of power relations was very different:

We are not allowed to enter into their [the Indians ] comfort zone. I am the manager: they will not let me talk to them, and they will always agree with me. In meetings the staff will often stay quiet and then I will get a lengthy email maybe an hour later when the meeting is over. And I have to start the thing all over again. And I think, well why not bring all that up in the meeting? It ends up taking twice the time. They will not confront me in meetings. The spark is missing.

The UK staff found it difficult to make the Indians explicitly reflect creative behaviour in the UK style. However, this form of creativity made little sense to the Indians. The reluctance of the Indian staff to follow UK practices of becoming informal with Mitra and to disagree followed by ˜making-up with after-work drinking, led Mitra to frustration:

It is really annoying. Sometimes I tell them something that is wrong. I want to hear ˜I don t agree with you . Here they are all interested in the ˜tag . I am more interested in what you bring to the table, not the tag you bring.

Another problematic area concerned the transfer of deeply embedded management processes that the Sierra management believed could be exported to India in the form of best practices, programmes and policies, including the language in which it was stated in the UK corporate Intranet. One form used for personnel appraisal in the UK contained the criterion of ˜bollocking ability . The term has a strong sense of meaning in the UK context “ the ability to sternly discipline an employee when necessary “ but had little meaning in India. While the Sierra management found this amusing in hindsight, the use of this term in the official personnel appraisal form was strongly indicative of a lack of sensitivity to contextual differences. Another example concerned the regular strategy meetings in London being filmed on videotape and played to the Indian team so they would understand the strategy process and plans for the organization. Indian staff found difficulty in understanding the accents, and were also deeply perplexed and confused by the UK team s supposedly volatile ˜creative discussion, which often had even senior people swearing and shouting at each other.

At a more macro level, new kinds of knowledge required for the e-commerce industry were placing pressure at the micro level of the India centre and the GSA. This need for heightened institutional reflexivity and Sierra s response to it is discussed in the next section.

Failure to stabilize and closure (1999 “2000)

In early 1999 after several (mostly unsuccessful ) attempts at whole-life-cycle projects being undertaken in India, it was felt that the model of work distribution should be moved to two discrete models, depending on the type of application. Model one, which had been in use prior to 1999 envisaged more interdependent work and used a split UK and Indian team. Teams were comprised of Indian and UK staff varying in size but usually small groups of 4 “5 developers in the UK working with 2 “3 Indian staff. Indian and UK staff either travelled back and forth or a local UK liaison offices was used to elicit requirements and deal with ongoing customer interaction. As well as the difficulties of communication related to the growth phase, lack of physical proximity was identified as a key problem with this model. In particular there were many difficulties relating to knowledge encoded into dialogue. Effective interaction with India needed instantaneous feedback and informal dialogue for informal, tacit knowledge transfer: Mitra described this need for interaction: ˜When building software, a rapport is built up. Sitting next to each other passes on a lot of understanding.

We develop this analysis further in later sections. In model two, the India team would assume responsibility for an entire module but the UK team would do most or all of the customer liaison. In this case, specifications would be sent to the Indian team and the code returned for testing and aggregation into the completed application. A mirror of the application as built was maintained at both sites. Videoconferencing, email and telephone as well as technologies such as Microsoft Netmeeting were used to facilitate communication between developers and, to a limited extent, customers. File Transfer Protocol (FTP) was used to deliver completed portions of code. Most work would be done with the latest World Wide Web application-building packages, JavaScript and database applications.

In model two, the strategy was one of replicating knowledge systems and minimizing interaction between the UK and India while model one emphasized replication and the development of knowledge transfer bridges through travel and the use of ICTs. Sierra management and development staff considered model two to be more effective owing to the modularization of work done in India, it could be self-contained and required relatively low interaction with anyone in the UK. This modularization and low level of interaction was seen as key to success but the replication of knowledge continued to cause problems.

Although Sierra management considered the strategy of replication of knowledge systems more successful, it was not without problems. India was perceived in the UK as having difficulty keeping up with the required pace and speed concerning time deadlines and the different manner in which these deadlines were interpreted. All of the Sierra group companies measured project management success based on efficiency reflected through ˜leakage . The UK management was constantly unhappy with the Indian developers who were seen to be ˜leaking on project deadlines. The Indian ˜leakage of 25 per cent was seen by the UK manager to be significantly higher than the UK office rate of less than 5 per cent. However, when the Indian developers were confronted with this concern, they were surprised that ˜leakage was an issue since they believed they had been delivering projects ˜in time . Further exploration showed that the main reason for the conflict was that the Indian and UK staff had very different time assumptions by which they measured ˜leakage . The UK office measured ˜leakage based on the number of hours worked on a project and not on whether or not a deadline was met. The Indians, on the other hand, measured ˜leakage based on whether they met a deadline or not. So it was quite typical for the Indians to work late in the evenings or over the weekend to make sure they met the deadline. However, the UK management still perceived this as ˜leakage , as it was greater than the number of hours that were assigned for the project.

To analyse the reasons for these differences and problems in replicating knowledge systems more closely, we need to understand the different assumptions of time that shape social life in the different contexts. In Sierra UK generally there tends to be a relatively clear separation between home and work. A UK respondent said that when a developer comes in to work, he or she would not respond to a personal phone call or run out to do some domestic errand during work hours. The situation was different in Sierra India operating in a developing country context where work and home lives were more tightly integrated. Some developers had aged parents living at home and it would be quite common to take some time off in the middle of the workday to take a relative to the hospital. Or, since telephone bills cannot be paid by mail but only by physically visiting the office, it would be common for employees to take off some hours to pay the bill or to complete a transaction in the bank or post office. India has a relatively higher number of religious holidays and in the monsoon season it can be extremely difficult to travel. Further delays were caused by telecommunications failures. This ˜lost time was compensated by working late hours or in the weekends. Trying to apply the same criteria of ˜leakage based on assumptions of the UK work life context to India thus became problematic as each other s differences were not well understood or accepted. The result was that the India centre was consistently deemed as relatively less efficient than the UK, contributing to the lack of trust UK staff had of India operations and discouraging UK commitment to building a community of practice.

Further evidence of the problematic nature of replication of knowledge embedded in routines was experienced with respect to software development methodologies. Methodologies were in place but they amounted only to guidelines that were not rigidly adhered to as opposed to highly prescriptive structured methods . The Indian developers seemed happy with this freedom, but their interpretations of these routines were often to the letter and did not take account of UK cultural norms of permitted deviation from the standards. From the UK perspective, Indian staff was seen to use the guidelines in a mechanistic process rather than to question the validity of statements or stages.

In both models one and two, telecommunications delay and unreliability contributed to the reported difficulties in what was described to us as ˜building a shared mental model of customer requirements as the system was being built. One response under these conditions was to increase the level of formalism in design and communication processes and to have regular structured videoconference meetings. However, interviewees in both UK and India complained that there came a point when it became easier to do the job in the UK than specify it in the detail necessary to do it in India. A Sierra developer in the UK had the following opinion:

We have project status meetings and the only communication which takes place is asking things like ˜Why are you slipping? rather than discussing ˜How are you getting on? , ˜How are things? , a kind of conversation. When you do get through to India it is all ˜What did you get to? ˜What have you done this week? , ˜What about next week? . We miss out on things like ˜I ve just found this good bit of code which you might find useful.

Informal ˜corridor conversation seemed important in transferring knowledge, especially for certain types of knowledge, and this was not possible in separation. A UK developer said:

We would have formal videoconference meetings with the India developers but a lot of the details would be worked out in an informal way between people. Only a small part of what you actually do gets written down and communicated through. This [informal knowledge] was important because we were closer to the customer.

Frequently Indian developers were seen to make incorrect assumptions about design documents. In some cases a UK developer found it quicker to complete the job himself rather than attempt to encode it or ask for clarifications. Misunderstandings were reported as being related to language, ˜inferences and ˜base-level understanding. Another UK developer said:

The communication, whether written or verbal, would be less rich because of language. The Indians speak good English, but you get the feeling that they are only getting say 70 “80 percent and are missing out on any subtle points that might be inferred between people. If you describe something you often leave quite a few things unsaid that are assumed to be the case, whereas you have to be much more explicit with India. There is less of a base-level understanding.

By mid-1999, Sierra s business direction was being reoriented towards providing e- commerce solutions, as was becoming a norm in the industry, and being standardized through processes of globalization. The e-commerce area itself was so fuzzy that the clients themselves were not sure of what they wanted. As a result, Sierra saw the opportunity not only to implement solutions but also to define the problems. Sierra as a company consequently needed to pay greater attention to the business, to understand the ICT and information strategy needs of their clients, rather than just to provide technological expertise. This implied different knowledge requirements. There was subsequently a complex negotiation and rethinking of Sierra s strategic thrust . There was a general consensus that for the highly complex and early life-cycle projects which e-commerce applications entailed, the developers would need to be on-site with the customer. From the customer perspective, there were concerns about IP, especially in a new and uncertain area like e-commerce where ideas seemed to be valued more than the product itself. This was the primary concern which led Mitra to believe that Sierra customers would be fearful of outsourcing their e-commerce ideas and plans, as they might be stolen in remote outsourcing locations.

To deal with the new strategic need for on-site work, and the ongoing problems of running the Bangalore office, Sierra decided to shut down its India operations and relocate the staff to the UK or US offices. Contributing to this decision was the fact that if the Bangalore centre continued, there would be difficulties in obtaining work permits for the Indians, and in trying to motivate the UK- or USA-based people who had worked on the first phase to come to India. Another personal and unexpressed reason was that Mitra by this time had become personally frustrated with the Indian situation and was keen to move back to the UK. Thus, at a macro level, a global shift towards e-commerce-type applications contributed to the need for the company to shift its operational emphasis. In Mitra s view this made the position for the Indian centre untenable as the early life-cycle work, conception , strategy and requirements for e-commerce applications required face-to-face presence.