7.3 Discussion

A number of themes relating to knowledge and its transfer were significant in shaping the trajectory of the GSA relationship. We draw on Blackler s (1995) ˜images of organizational knowledge which are useful to understand the different knowledge- related issues. These images include knowledge that is embedded into routines and systems or encoded into manuals, codes of practice and dialogue that are embrained and embodied within human actors and encultured in the norms and conventions of a culture. To analyse the case we draw on three of these images: encoded, encultured and embedded. Encoded knowledge is conveyed by signs and symbols and in GSAs they are realized in manuals, notations, standards and codes of practice, as well as information encoded and transmitted electronically using various ICTs. The debates around what constitutes encultured knowledge are complex but often simply defined as relating to ˜the way things get done , more theoretically due to the process of achieving shared understanding. It is reflected more broadly in the structures, policies, norms, traditions, rituals and values of an organization (see for instance Smircich 1983 and our discussions of culture in chapters 5 and 9). While some aspects of this knowledge are formalized in rulebooks and codes of practice, other aspects are less formal and are shared during informal socialization and are socially constructed through ongoing and evolving processes of negotiation. There is considerable evidence of programmers and analysts approaching the IS development process differently in different countries based on varying encultured practices (e.g. Ein Dor, Segev and Orgad 1993). Embedded knowledge is that which resides in routines, technologies, roles, formal procedures and methods . In the Sierra case, development methodologies and project management plans, where knowledge is embedded into the routines, would be key examples. The following discussion will relate these images of knowledge to the case and analyse some of the dynamics of the initiation, growth and stabilization phases of Sierra s GSA.

Initiation

In the initiation phase, Sierra had outsourced several projects to India. Based on these experiences, Sierra management believed that they could do the outsourcing internally and decided that they could achieve greater levels of control over staff and the culture of the organization with their own subsidiary. They opened the centre based on a rapidly assembled business case in early 1998. Almost immediately, a lack of encultured knowledge of the Indian context, such as local formal and informal recruitment networks, bribes and corruption, infrastructure, educational institutions and bureaucracy, caused great difficulties. Informal knowledge about bribes, for instance, tends not to be formalized in official documentation about outsourcing, but is nevertheless an institutionalized practice in many Indian public and private organizations. Mitra did not discover this until he arrived in India; he then had to engage with the various systems that directly affected the process of software development. For instance, telephones took considerably longer to be installed and repaired than in the UK, bribes were required to get equipment through customs . Far from the ˜ streets of Bangalore being paved with programmers , as Mitra originally thought, he quickly found Sierra was a very small company in a large intense market competing for the best staff with large MNCs. Many companies would deal with this issue by hiring a local consultant. However, because of the strong desire of ˜creating a little Sierra in India , Sierra started with a dominant UK frame of reference rather than a local one.

Sierra s early experiences with Indian outsourcing companies did not provide them with the necessary encultured knowledge to conduct business in India. This proved crucial to the lack of early success of the GSA. Owing to Mitra s lack of contextual knowledge, he created very high expectations from the UK side of what could be achieved in India; failure to meet these high levels led to discord and reduced trust from the staff in UK head office. Sierra initiated the GSA and attempted to transfer knowledge embedded into processes and products and believed that encultured knowledge could also be transferred by choosing the ˜right staff, benefiting from Mitra s influence and staging events like the holiday in Goa and evening drinks. Encultured knowledge was important at the macro level of the relationship as it provided background understanding and a framework for communication that could have been the basis for trust. Sierra management believed that their culture could be made explicit and manifest in the Bangalore centre.

The intention of taking control over the operations and culture through standardization , a theme also discussed in the Witech case, proved to be highly problematic . In the early stages, Sierra attempted to carry out a complex development offshore based on a strategy of standardization of knowledge systems. This strategy was quickly found to be wanting as software development work needed high levels of interaction with customers whose requirements were difficult or impossible to encode without face-to-face presence. When moving to the split-team model, physical separation still acted as a barrier to knowledge transfer between the Indian and UK teams . The UK development staff was closer to the customer and their informal interactions demonstrated the importance of the situated nature of development. This knowledge was impossible to transfer to India.

Growth and failure to stabilize

In the growth and failure to stabilize phase between 1999 and 2000, Sierra adopted three models of development. The first involved whole-life-cycle projects being taken by the India centre, including customer liaison armed with videoconferencing links.

This system was rapidly abandoned and development structured around a split-team model and an attempt at limiting interaction and replicating knowledge systems. Both models suffered from problems of knowledge transfer related to a number of technical and contextual factors.

Sierra s attempts to move to stabilization can be analysed from the perspective of their failure to create a community of practice, specifically with respect to issues of articulation of knowledge in practice or knowing in action and the importance of common cultural background. Brown and Duguid (2000) point out the importance of informal interactions, shortcuts and fixes to make the actors form of talk and work mutually intelligible. Creating, learning, sharing and using knowledge appear almost indivisible.

Such a dialogue did not emerge between Sierra UK and India. There was a constant need to check understanding that impeded spontaneous informal interaction. These problems were further accentuated by unreliable telecommunications. In a community of practice, knowledge travelling on the back of practice is shared. It is during practice, otherwise referred to as the act of knowing in action , where informal, tacit knowledge may be transferred. The Indians could not actively engage in such action owing to geographical separation, and the physical distance solidified the separate worlds of the developers situated in Bangalore and the UK. The UK developers who were closer to the client knew more than they could tell or specify formally in a reasonable manner short of completing the design in the UK. When they did complete the specifications they were often misunderstood.

Zuboff (1988) points out that knowledge encoded by decontextualized abstract symbols is inevitably highly selective in the representations it can convey. It is thus open to interpretation and can convey different meaning to different groups. At Sierra, poor interpretation of designs occurred owing to language and communication problems as well as differences in levels of shared technical and organizational knowledge. These differences were difficult for UK staff to detect. This led to some disastrously incorrect designs. For example, UK developers specified a workflow application and sent it via email for Indian programmers to develop. When they produced the specification they assumed that the Indian recipients would recognise basic workflow concepts and technology. For UK staff this knowledge was ˜taken for granted , but Indian developers did not share this assumption. It took several costly iterations before the workflow application was eventually withdrawn from India and completed in the UK. The UK developers were under high time pressure and were unable to monitor the Indian developers responses. They had no time to check understanding which at Sierra was a routine aspect of face-to-face interaction but difficult when mediated by ICT. If they tried, developers faced the time differential, the problems of making and sustaining a connection via phone or videoconference. Then there was the problem of telecommunications speech delay creating gaps in the ˜conversation and comprehension of accents. The problems were accentuated by a tendency on the Indian side to say they understood when they had not and discussion that lacked the informal tips, gossip about the customer needs and chat which was of such great importance in an evolving project.

In the Sierra case, the issue of encultured knowledge was important. It included an understanding of the levels of permitted deviation from methodology or other practices as well as the importance of time scales and quality, power and authority structures, levels of permitted informality, outside-work socialization, behaviour in meetings and in the working day. Cultural knowledge is related to history, habits, local context, role-related expectations and the prior disposition of individuals and groups (Tsoukas 1996). Like Polanyi, Tsoukas points out that all articulated knowledge is based on an unarticulated background of what is being taken for granted that is tacitly integrated by individuals. These particulars reside in the social practices and forms of life in which one happens to participate. For Tsoukas, it is when one lacks a common background that misunderstandings arise, in which case one is forced to articulate the background and explain it to others and to oneself. One knows the unarticulated background in which one dwells through having been socialized into it by others. This does not imply that individuals are all ˜cultural dopes caged by structural norms (Garfinkel 1967); although the individual retains agency, structural norms exist as tacit memory traces that are drawn upon in articulating action (Giddens 1984). The Gowing case described in chapter 8 also emphasizes the importance of background understanding. The Indian programmers working on social security systems had no conception of unemployment benefit or social housing. These were an unknown concept in the Indian system, but formed part of the taken-for-granted background knowledge in the UK.

The UK management style which celebrated informality, creative discussion and a relaxed atmosphere was difficult to transfer to India. At the same time the company was not able to foster a different kind of problem solving orientation for the Indians. The Indian practices were difficult to change in part because they were strongly rooted in the historical structures of the Indian technical education system. This tends to be relatively instructional: the focus is on learning techniques and methodologies. While this technical approach supports strong analytical thinking, it did not mesh with Sierra s ˜out-of-the-box approach to creativity.

Sierra management perceived informality, relaxed atmosphere and confrontation as being key to creativity. They found the Indians wanting in these aspects and were critical of the Indian approach to problem solving in the software development process. Sierra s creative conflict made little sense to Indian programmers; they tended to avoid open and direct conflict with the manager in meetings and preferred to send him an email raising issues after a meeting. By then, Mitra thought things had been resolved. Other writers have commented on stereotypical ˜Indian approaches to problem solving that emphasize group loyalty and cohesion, and trust and cooperation when trying to solve a complex problem (Badke-Schaub and Strohschneider 1998). The behaviour of the Indians was seen by Mitra to fit into the stereotype of Indians tending to be risk-avoiding and obedient, taking action only when some superior gives clear signals to go ahead. Mitra reported that the Indian programmers showed a greater reverence for hierarchy, rank and status: individuals were careful about expressing their opinions in a way that avoided disrespect for him as their manager. This tendency to value the positional role and hierarchy has been emphasized by other writers. Sinha (1984), for instance, comments that in Indian firms while obedience is expected from junior staff members , guidance is expected from senior leaders . Sinha and Sinha (1990) suggest that in many Indian firms there is a traditional differentiation of hierarchical relationships with the notion of ˜check with the boss as the crux of the decision making style. This shifts the locus of control into the highest position in the organization.

These issues of hierarchy had direct consequences for the development process and stalled the evolution of the GSA. Many aspects of the Sierra organizational culture had little if any connection with the background knowledge of the Indian programmers. Mitra s expectation that Indians would mirror the UK programmers was unrealistic . Initial face-to-face meetings are helpful to facilitate subsequent electronic mediation (Carmel 1999; Maznevski and Chudoba 2000). Achieving any position towards mutual understanding would require an appreciation of background and history of social practices and forms of life in which Indians and UK developers participate. Developing an appreciation of another culture requires extensive socialization, a genuine interest to learn and a strong investment of time and effort. For the UK side this would have meant an interest in Indian society, history, traditions and an attempt to understand Bangalore and India as a place rather than a space for software development, a theme discussed in chapter 6 in the MCI case. Sierra would have needed to adopt a process of bi-directional knowledge sharing rather than uni-directional knowledge transfer in order to develop a stronger encultured understanding. The Indian side would also need to attempt similar efforts to relate to the UK head office context, society, the customers, business, etc. Many large Indian outsourcing companies, such as Mastek, take this issue very seriously and run courses for customers and their staff so that they can aspire to a degree of mutual understanding.

The problem over ˜leakage shows the need to consider the broader context in which the Indian developers were working and how that context differed from UK conditions. ˜Leakage must be seen in the context of these differences and expectations must be realistic. Human geographers such as Massey (1995) point out the importance of place in the globalization debate. Some of the local contextual conditions of the place ˜Bangalore include the fact that it is subject to a strained, overcrowded infrastructure. During the monsoon season it can be extremely difficult to travel. Power cuts are common occurrences significantly affecting productivity. Differences in time zones between the UK and India and the relatively large number of vacation days in India also create issues in synchronizing team activities contributing to ˜leakage . Indian programmers often carry considerable family responsibilities that are quite different from workers in the UK, making the use of time quite different: late working at night or at weekends is quite routine for the Indians. Understanding such issues of working in India is fundamental to developing a place-based sensitivity to issues. Places contain existential significance for people living within them and form part of the tacit frames of reference that shape behaviour. For GSA to evolve , embedded knowledge needs to be viewed in the context of respective places and their structural conditions. In essence, companies like Sierra need to understand the culture of their foreign subsidiaries; their Indian employees need to understand the culture of their foreign clients .

Although the Sierra management faltered in their attempts to stabilize the GSA before finally deciding to close the centre, events show that knowledge transfer was not static. Various internal issues (e.g. communication problems of accents) and external events (e.g. a global and corporate shift to e-commerce) impacted and were impacted on by the knowledge transfer process over time. Communication problems led to a change in the nature of work conducted in the Bangalore centre that in turn reduced the need for communication. Corporate shifts to e-commerce caused a move to unstructured early life-cycle work that Sierra management realized could be done only in the UK.

We have adopted a broad sociologically grounded knowledge-based perspective to investigate the dynamics related to knowledge transfer. Three key areas have been identified to influence the process of growth of a GSA relationship “ encultured practices, encoded dialogue and knowledge embedded into processes. Encultured knowledge of Sierra UK informality, creativity and conflict was seen to make little sense in the Indian context. The tacit background knowledge of programmers in the UK and India reflected structural norms in their respective countries. The backgrounds of Indian and UK developers were not sufficiently similar to allow for effective transfer. Problems of interpretation of encoded designs were in part due to an inability to relate to background tacit assumptions that could be made within situated (UK-based) groups. In table 7.1, we summarize these three issues and the nature of their influence on the evolution of the relationship.

Table 7.1: Knowledge issues shaping GSA evolution

Issues of knowledge transfer	Initiation	Growth	Failure to stabilize
Encultured practices	Lack of informal knowledge of Bangalore context led to significant difficulties when engaging with systems and institutions (e.g. handling bribes, infrastructure, bureaucracy and recruitment networks) UK frame of reference for Sierra management	Sierra s practice of creativity, informality and behaviour in meetings made little sense in the Indian context where hierarchy, rank and status were important conventions Indian technical orientation was perceived as leading to a precise interpretation of methodology and unquestioning attitude to designs and specifications	Failure to transfer Sierra culture to India led to UK mistrust , dissonance and unwillingness to work in India centre
Encoded dialogue	Planned liaison directly with customers using ICTs failed owing to the location of UK facilities at Sierra London and the need for face-to-face presence to elicit requirements Telecommunication unreliability and accents caused problems of interpretation	Geographic separation led to misunderstandings owing to different unarticulated background of developers Indians could not engage fully in the act of knowing in a community through engagement in dialogue and problem solving ICTs were unable to bridge the Indian and UK communities of practice	Strategic moves to e-commerce required a shift to unstructured early-life-cycle work which could be done only in UK ˜face-to-face owing to the richness of interaction required Tacit background knowledge reflected different structural norms in India and UK which were not sufficiently similar to allow for effective transfer
Embedded knowledge	Standardization of knowledge systems in an unmodified form proved problematic owing to language and comprehension	Continued problems of standardization related to the Indian context ˜Place -related factors meant that replication of knowledge systems such as project management ˜leakage lacked relevance as a measure of success	The small size of Sierra made it difficult for standardization to be effective compared with large firms such as GlobTel