COORDINATING EXPERTISE ACROSS KNOWLEDGE BOUNDARIES IN OFFSHORE-OUTSOURCING PROJECTS: THE ROLE OF CODIFICATION

The coordination of effort within and among different expert groups is a central feature of contemporary organizations. Within the existing literature, however, a dichotomy has emerged in our understanding of the role played by codification in coordinating expert groups. One strand of literature emphasizes codification as a process that supports coordination by enabling the storage and ready transfer of knowledge. In contrast, another strand highlights the persistent differences between expert groups that create boundaries to the transfer of knowledge, seeing coordination as dependent on the quality of the reciprocal interactions between groups and individuals. Our research helps to resolve such contested understandings of the coordinative role played by codification. By focusing on the offshore-outsourcing of knowledge-intensive services, we examine the role played by codification when expertise was coordinated between client staff and onsite and offshore vendor personnel in a large-scale outsourcing contract between TATA Consultancy Services (TCS) and ABN AMRO bank. A number of theoretical contributions flow from our analysis of the case study, helping to move our understanding beyond the dichotomized views of codification outlined above. First, our study adds to previous work where codification has been seen as a static concept by demonstrating the multiple, coexisting, and complementary roles that codification may play. We examine the dynamic nature of codification and show changes in the relative importance of these different roles in coordinating distributed expertise over time. Second, we reconceptualize the commonly accepted view of codification as focusing on the replication and diffusion of knowledge by developing the notion of the codification of the “knower” as complementary to the codification of knowledge. Unlike previous studies of expertise directories, codification of the knower does not involve representing expertise in terms of occupational skills or competences but enables the reciprocal interrelating of expertise required by more unstructured tasks. 1


Introduction
The coordination of effort within and among different expert groups is a central feature of contemporary organizations (Carlile 2002;Majchrzak et al. 2007). Indeed, support for such coordination is viewed as one of the most important contributions that information systems can make to organizational performance (Aral et al. 2012;Kellogg et al. 2006). Such systems achieve their coordinative effects not only by enabling expert groups to become better connected through improved communications, but also by reducing the dependencies between them through the codification of knowledge (Leonardi and Bailey 2008;Levina and Vaast 2006).
Within the existing literature, however, a dichotomy has emerged in our understanding of the role played by codification in coordinating expert groups. In one strand of literature, studies emphasize that codification supports such coordination by externalizing knowledge (i.e., by making it more explicit and accessible through improved storage and ready transfer). In this view, where knowledge can be codified, the effect is to reduce the need for close, reciprocal interactions between different individuals and groups as they are able to follow the same defined procedures, apply shared tools, and draw on the same centralized knowledge stores (e.g., Espinosa et al. 2007; Kanawattanachai and Yoo 2007;Kankanhalli et al. 2005). Thus, codification supports coordination by spreading common knowledge and reducing dependencies between groups .
In contrast, work within another strand of the literature emphasizes the limitations on the role of codification in coordinating expert groups. Studies here question the coordinative benefits of the ready storage and transfer of knowledge. They highlight instead persistent differences between expert groups, and the boundaries they pose to the sharing of knowledge (e.g., Leonardi and Bailey 2008;Levina and Vaast 2008). The coordination of different groups is, therefore, seen as much more reliant on the intensity and quality of their reciprocal interactions (Vlaar et al. 2008).
These dichotomized views in the literature provide an important impetus for research to help resolve our contested understanding of the coordinative role played by codification. The need for such research is also driven by growing evidence that the dichotomy in current work may be based on too rigid a conceptualization of the different roles that codification may play in coordinating expert groups (Leonardi and Bailey 2008;Vaast and Levina 2006;Zollo and Winter 2002). The overarching theoretical concern for our study, then, was to deepen our understanding of the implications of codification for the coordination of expert groups, exploring both its limits and its coordinative effects.
An appropriate arena in which to ground these concerns is provided by the spread of offshore-outsourcing and its impact on the distribution of expertise between different organizations. Offshore-outsourcing 2 raises important new questions for Information Systems theory and practice concerning the ability of organizations to manage the handover of their business activities from in-house to outsourcing vendors based at offshore locations (e.g., Srikanth and Puranam 2008;Tiwari 2009), particularly where the activities involved are not simple and repetitive tasks but high-value, knowledgeintensive services (e.g., Levina and Vaast 2008). The inhouse to offshore handover involves a significant coordination effort between multiple expert groups, including, typically, client employees, onsite vendor staff, and offshore vendor staff (Srikanth and Puranam 2008) to allow the vendor organization to rapidly acquire the ability required to take over client systems and maintain continuity of service (Vlaar et al. 2008).
In our study, we applied the theoretical lens of expertise coordination to offshore-outsourcing as a way of addressing our overarching research concerns (Faraj and Sproull 2000;Faraj and Xiao 2006;Majchrzak et al. 2007). This lens highlights the way in which knowledge-related interdependencies are managed among groups. 3 Much of the previous work on expertise coordination has focused on the dynamic interactions in collocated teams where mutual awareness and adjustment of different individuals' expertise is developed informally through a shared history of interactions and copresence (e.g., Faraj and Sproull 2000;Hollingshead 2000). Compared to the teams highlighted in previous work, the expertise coordination in the groups involved in the offshoreoutsourcing setting is distinctive in a number of ways, including their geographically distributed character, the implications of organizational boundaries, and the impact of national and cultural differences between teams (Cummings et al. 2009;Espinosa et al. 2003;Espinosa et al. 2007;Levina and Vaast 2005). One result of these distinctive features is that expertise coordination in this setting typically lacks the informal mechanisms present in collocated teams, and is highly reliant on the use of communication and storage tech-2 Offshore-outsourcing implies contracting with a third party (vendor) based at an offshore location (which usually means in a developing country and separated from the client by an ocean) to accomplish some work for a specified length of time, cost, and level of service (Oshri et al. 2011). 3 In line with Faraj and Xiao (2006), we conceptualized expertise coordination as "managing knowledge and skill interdependencies" (p. 1159). This takes place over time through various coordinated actions "enacted within a specific context, among a specific set of actors, and following a history of previous actions and interactions that necessarily constrain future action" (p. 1157). nologies to support the codification and transfer of knowledge between sites (Oshri et al. 2008;Vlaar et al. 2008). This makes offshore-outsourcing an extreme case, providing opportunities for theory development centered on the role of codification in coordinating of expertise (Eisenhardt and Graebner 2007).
In addressing our overarching theoretical concerns, we developed the following research question to guide our empirical study: What role does codification play in the coordination of expertise within the offshore-outsourcing setting, when knowledge boundaries are present?
A number of theoretical contributions flow from the analysis of our empirical study, helping to move our understanding beyond the dichotomized views outlined above. First, our study adds to previous work where codification has been seen as a static concept by demonstrating the multiple, coexisting, and complementary roles that codification may play. We examine the dynamic nature of codification and show the changes in the relative importance of various codification roles over time when coordinating distributed expertise. Second, we reconceptualize the commonly accepted view of codification as focusing on the replication and diffusion of knowledge by developing the notion of the codification of the "knower" and highlighting its complementary role to the codification of knowledge within the offshore-outsourcing setting.

Theoretical Background
The dichotomous view of codification outlined above reflects a major epistemological divide in existing literature on the nature of knowledge and expertise. In broad terms, this can be summarized as a divide between an epistemology of possession, which views knowledge as something that can be "abstracted, explicitly represented, codified and accessed" Sproull 2000, p. 1555), and an epistemology of practice, in which knowledge emerges through situated learning from the patterned interactions and practices within particular groups or communities (Cook and Brown 1999). These epistemological positions are echoed and elaborated, with some variation, by many accounts, including work in the field of knowledge management as well as IS (Leonardi and Treem 2012;Levina and Vaast 2005;Orlikowski 2002). In line with Cook and Brown's (1999) analysis, we sought to reconcile the competing epistemologies at play by distinguishing between the knowledge used by an individual or group, and the learned expertise of that individual or group (the "knowers" in Polanyi's (1962) terms). In line with this view, expertise is defined here as a "knower's capacity to act," and is differentiated from knowledge, which is viewed as a tool used by knowers to solve problems (Cook and Brown 1999), or to transform their own expertise (Gherardi and Nicolini 2000).
In the following sections, we build on the contrasting views outlined above in developing our understanding of expertise coordination in the offshore-outsourcing setting.

Expertise Coordination and Knowledge Codification
In the existing literature, we find a close affinity between work on codification and the epistemology of possession outlined above. Put simply, codification, defined as "the compression of knowledge and experience into a structure, involving the use of codes and models to translate rules and actions into procedures, guidelines, specifications, and documents" (Whitaker et al. 2010, p. 19), is widely seen as the means by which knowledge is made explicit and hence readily stored or transferred between groups. Hansen et al. (1999) exemplify the dichotomy in existing views by differentiating between a codification strategy, which allows people to search and retrieve codified knowledge without having to contact the person who originally developed it, and a personalization strategy, which is associated with the sharing of knowledge through personal contacts (Boh 2007;Hansen et al. 1999;Scheepers et al. 2004). These are viewed as alternative not complementary strategies. Thus, firms that adopt a codification strategy are able to make knowledge an organizational resource by depersonalizing it and making it readily available, either as a transferrable object or through storage in centralized databases. With this view of expertise, codification is seen as helping to significantly reduce the challenges of coordinating expertise by reducing any knowledge-related dependencies between groups. It gains support from, for example, Faraj and Xiao's (2006) study of expertise coordination in an emergency trauma center which found that the codification of knowledge or knowledge externalization helped to reduce information-sharing problems.
A further aspect of the codification of knowledge emphasized in existing work is the routinization of actions and roles. Nelson and Winter (1982) describe the coordinative benefits of such organizational routines, as follows: While each organization member must know his job, there is no need for anyone to know anyone else's job. Neither is there any need for anyone to articulate or conceptualize the procedures employed by the organization as a whole (p. 105).
The effect of such routines on the coordination of expertise is further evidenced by Faraj and Xiao's (2006) study which found that trauma protocols-standard operating procedurehelped to streamline work and reduce process uncertainty.
There are, however, strict limits on the role of codification in supporting expertise coordination. Some studies argue at a practical level that the tacit knowledge which resists codification may need to be transferred through face-to-face interactions (Hansen 1999;Rottman and Lacity 2004;Santhanam et al. 2007). Other studies, though, identify more profound limitations arising from the situated or practice-based nature of knowledge and learning . Even in the seminal work of Nelson and Winter, the notions of tacit and explicit are not presented as distinct forms of knowledge in an absolute sense, but rather as relative to their context. It follows that attempts to codify knowledge into an explicit form may not succeed in making it universally accessible or usable (Bechky 2003), but rather risks decontextualizing it (Majchrzak et al. 2005;Vlaar et al. 2008). As a result, individuals who later retrieve the knowledge may struggle to apply it appropriately and to integrate it into their actions (Leonardi and Bailey 2008). Indeed, even codified protocols and standardized training programs need to be fully learned by the individuals concerned, if they are to be applied effectively (Faraj and Xiao 2006;Hansen 1999).

Knowledge Boundaries and Expertise Coordination
The studies discussed above suggest that the role of knowledge codification in expertise coordination can only be fully grasped by relating it to the formation and distribution of expertise among the different groups involved. In particular, it involves acknowledging the difficulties of transferring knowledge across what Carlile (2002) terms "knowledge boundaries," by which he means differences in knowledge that is localized, embedded and invested in different practices, 4 and which inhibit coordination between expert groups possessing different forms of expertise (Majchrzak et al. 2012). It follows that coordination between such groups may involve the creation of shared understandings (Vlaar et al. 2008), and the transformation rather than the transfer of knowledge (Bechky 2003;Carlile 2004).
A further implication which emerges from these more practice-oriented studies is the distributed character of expertise: that is, expertise cannot be readily centralized as an organizational resource because it emerges from the practices in which groups and individuals engage (e.g., Jarvenpaa and Majchrzak 2008;Majchrzak et al. 2007). The implication of this distributed character, as argued by Tsoukas (1996), is that the key to achieving coordinated action does not so much depend on those "higher-up" collecting more and more knowledge as on those "lower-down" finding more and more ways of getting connected and interrelating the knowledge each one has (p. 21).
In some studies, this interrelating of knowledge and expertise is described in terms of the relationships within and between communities of practice (e.g., Faraj and Xiao 2006). In other work, the emphasis is rather on social networks or virtual professional networks (e.g., Faraj et al. 2011;Jarvenpaa and Majchrzak 2008). In all of these instances, however, the social or electronic links between groups and individuals provide an important means of accessing certain forms of expertise.

The Role of Codification in Offshore-Outsourcing
Much previous work in the offshore-outsourcing setting has highlighted the capacity of the codification of knowledge to mitigate the lack of easy interpersonal interaction in this setting and reduce knowledge dependencies between groups (Kanawattanachai and Yoo 2007;Leonardi and Bailey 2008;Vlaar et al. 2008). Within that emphasis on codification, a number of studies highlight the importance of externalizing knowledge by embedding it within artefacts such as application manuals, descriptions of systems architectures, functionalities, presentation slides (Chua and Pan 2008;Leonardi and Bailey 2008;Vaast and Levina 2006;Vlaar et al. 2008), and other documents that would capture knowledge that could be explicitly put on paper (Chua and Pan 2008). In addition to this embedding of knowledge, a further aspect of codification encompasses routinization. This has been seen as especially relevant to the offshore-outsourcing arena since it helps to establish clear rules and responsibilities for the specification of services , encompassing relationships between onsite and offshore teams that rely on a well-specified division of work and a predefined workflow (Carmel and Tjia 2005;Kotlarsky et al. 2008;Oshri et al. 2008;Vlaar et al. 2008).
In contrast to these benefits ascribed to codification, however, other studies of this setting highlight the limitations on its role 4 Carlile distinguishes three "progressively complex boundaries" (2004, p. 555), which are rooted in Shannon and Weaver's (1949) fundamental theory of communication: syntactic (differences in lexicon), semantic (differences in interpretations), and pragmatic (differences in interests) boundaries. in expertise coordination. Vlaar et al. (2008), for example, argue that "the exchange of documents is generally insufficient for making the rationale behind a code transparent to others" (p. 231). In this vein, a number of studies suggest that the value of codification is limited by the knowledge boundaries that arise between teams distributed between onshore and offshore sites that are likely to have varying levels of attainment within the same domain of expertise (Espinosa et al. 2003;Espinosa et al. 2007). These differences may not only encompass different levels of competence between client and vendor personnel (Levina and Vaast 2005), but may also arise within the vendor organization itself as a result of asymmetries in the expertise of onsite versus offshore team members (Carmel 1999;Oshri et al. 2008;Vlaar et al. 2008). Leonardi and Bailey (2008) note, for example, that a disparity in expertise between technical experts at the home site and less experienced individuals offshore "raises the strong possibility that individuals who receive work offshore may not be able to interpret the knowledge embedded in artefacts by their expert and distant colleagues" (p. 415).
While routinization may assist in coordinating expertise between onsite and offshore locations, these coordinative efforts are also subject to the emergence of knowledge boundaries between groups. Under such contrasting conditions, in the following section we examine the role that codification played in coordinating expertise in one offshore-outsourcing project. In the case study, we examine how the expertise coordination process unfolds over time, as different parties (onsite and offshore team members, and client personnel) interact during the period when client systems are handed over to the vendor. In the light of our research question, our focus was on studying the connection between expertise coordination and codification practices.

Design and Case Selection
In line with past studies suggesting that case studies can be used to advance understanding of a particular phenomenon (e.g., Eisenhardt 1989;Lee and Baskerville 2003), we based our qualitative and interpretive research approach on an indepth case study of an offshore-outsourcing project. In order to explore major challenges for the coordination of expertise in the offshore-outsourcing setting, our primary case selection criterion was the size and complexity of projects. As a result, a key project of TATA Consultancy Services (TCS) was selected for in-depth study. This project involved the offshore-outsourcing of the IT infrastructure support for a major European bank-ABN AMRO-and the concurrent development of new systems within TCS. While the outsourcing contract between TCS and ABN AMRO lasted five years, our study focused on the transition stage as it is considered to be the most challenging phase in the offshoreoutsourcing project in terms of expertise coordination between onsite and offshore groups (Srikanth and Puranam 2008).

Data Collection
Evidence was collected during the period 2006-2008, mainly from interviews and internal documents (Yin 1994). Interviews were conducted with members of the onsite-offshore team at both sites: at the onsite location in Amsterdam (The Netherlands) and the offshore location in Mumbai (India). Interviewees were chosen to include (1) team members working closely together from these remote locations, and (2) diverse roles such as executives, top and middle managers, team leaders, and developers. Data was triangulated through interviews with team members based both onsite and offshore. In particular, team counterparts onsite and offshore were asked to either confirm or challenge the patterns emerging from the data. We started by interviewing onsite staff, and as our understanding of the organizational structure of the project developed, we moved to interview team members based offshore, and managers from supporting functions. While the main effort to collect data was in 2006 during the transition stage, we went back to the onsite location in 2007 and 2008 and conducted additional interviews with key personnel for additional information. In total, we interviewed 52 individuals (including three ABN AMRO executives and managers); their roles are included in Appendix A. Interviews lasted on average one hour; they were recorded and transcribed in full. A semi-structured interview protocol was applied to allow the researchers to clarify specific issues and follow up with questions (see the interview protocol in Appendix B). The unit of analysis is a globally distributed project team that involves members both onsite and offshore. We focused on understanding how expertise was coordinated between client, onsite, and offshore specialists.

Data Analysis
Data analysis followed several steps. It relied on an iterative reading of the data using open-coding techniques (Strauss and Corbin 1998). Codes, which are chunks of text that are partial or complete sentences or expressions describing specific activities (Strauss and Corbin 1998), were associated with categories, subcategories, and concepts. Atlas.ti qualitative data analysis software was used for coding and grouping these codes into themes (Weitzman 2000).
Data was analyzed by the first and third author independently. The interpretation of selective codes (those that seemed to have dual meaning), the consolidation of codes into categories and subcategories, and the examination of empirical findings (in particular, new categories or subcategories that emerged from the data) against the literature were performed by all researchers together.
During the first step in our data analysis, we examined the concepts of expertise coordination and codification in the onsite-offshore setting. This involved reading through the interview transcripts and coding the statements that illustrated activities related to (1) expertise coordination between client, onsite, and offshore members, and (2) codification efforts that took place.
The initial coding stage was followed by an analysis of the coded statements and involved looking for themes emerging from the data, and revising these themes through the theoretical lens. Themes that emerged from the data were compared with predefined categories, subcategories, and concepts. New themes that described (1) expertise coordination and (2) codification were added as new categories or subcategories to the relevant concepts (Miles and Huberman 1994). In Appendix C, we use grey-scale to differentiate between the literature-driven (predefined) themes and those that emerged from the data.
Through the analysis of TCS experts' actions in acquiring knowledge and solving incidents, we found that two modes of expertise coordination emerged from the data: a structured coordination mode that relied on roles, routines, and protocols, and an improvised coordination mode that relied on ad hoc (as opposed to prescribed) ways to find and apply relevant expertise (Faraj and Xiao 2006). 5 As we illustrate later (in Figure 2), the first part of the transition relied on structured coordination, while problem-solving at the later stage relied on improvised coordination. Figure C2 and Table C1 in Appendix C present evidence in support of the two coordination modes.
When analyzing codification, we distinguished between two different codification practices: first, knowledge codification, which corresponds to the notion in widespread use within the literature on knowledge management reviewed earlier (e.g., Hansen 2002;Kogut and Zander 1992). And second, codification of the knower, which involves codifying links to individuals by documenting their characteristics. As evidence of various codification activities emerged from the data, we turned back to the literature to deepen our understanding of the concept of codification (in line with the principle of dialogical reasoning suggested by Klein and Myers 1999). Through the iterative cycle between literature review and data analysis we confirmed that the traditional view of codification as seen in the IS and knowledge management literature corresponds with the knowledge codification practice we observed taking place in the offshore-outsourcing project, while codification of the knower is a new category of codification that emerged from the data (both are depicted as categories of the concept "codification in an onsite-offshore team" in Appendix C, Figure C1).
The analysis of our data presented a challenge in as much as we needed to relate our detailed analysis of codification and expertise coordination between different actors involved in the transition to the wider process of expertise coordination that spanned the boundaries of the two organizations. To address this challenge, we adopted the data analysis method developed by Nicolini (2009) which involves zooming in to certain practices while pushing others to the background, and zooming out to capture links between the practices within a wider context. This allows us to simultaneously explore particular practices at a detailed level, while allowing us to "see the connection between the here-and-now of the situated practicing and the elsewhere-and-then of other practices" (Nicolini 2009(Nicolini , p. 1392 In this paper, zooming in involved studying expertise coordination in the different settings 7 that constitute the offshoreoutsourcing endeavor. Zooming in allowed us to examine, through the use of vignettes, how expertise is coordinated between counterparts and the role that codification played in this regard. Zooming out involved mapping the connections between coordination and codification practices by following 5 Structured coordination, encompassing a range of predefined formal mechanisms, has long been the focus of coordination theory (Okhuysen and Bechky 2009). Recent work has questioned the relevance of this established theory to knowledge-intensive work in high-velocity environments, suggesting that new forms of coordination are required (e.g., Kanawattanachai and Yoo 2007;Majchrzak et al. 2007). However, a study by Faraj and Xiao (2006) suggests that these modes may continue to coexist within such settings. As they observe, "The empirical record shows that formal modes of coordination do not melt away in favor of more improvised ways of coordinating" (pp. 1156-1157). 6 Nicolini described several alternative approaches for zooming in and zooming out. In our research, we followed Nicolini's "re-presenting practice through foregrounding the active role of tools and materials" (p. 1402) for zooming in, and his "following the associations between practices" approach (p. 1408) for zooming out. 7 Different settings in our context refers to different combinations between client, onsite and offshore experts. We distinguished the following settings in which expertise coordination took place: client-onsite; onsite-offshore; client-offshore; client and onsite-offshore, as shown in Figure 2. them in space and time. We developed a temporally ordered view of the expertise coordination process as it unfolded and changed over time across the client, onsite, and offshore experts (as depicted in Figure 2). Zooming out enabled us to trace how the role of codification has changed over time during expertise coordination (depicted in Figure 3).

Case Background
The outsourcing deal between ABN AMRO Bank (hereafter, the Bank) and TCS was announced in late 2005. In this €1.8bn contract, the Netherlands-based bank contracted five vendors, among them TCS, to provide support and application enhancement services for hundreds of applications. Under this contract, TCS was contracted to provide such services to the Bank's business unit based in The Netherlands from its offshore Global Delivery Center in Mumbai. (Appendix D shows schematically the organizational structure of the project.) The project was divided into two major phases: transition followed by steady state. The transition stage 8 involved the transfer of applications from ABN AMRO to TCS and was planned to be completed in three waves 9 within three months (as depicted in Figure 1).
The focus of the transition was on learning about client systems and services. By the end of this stage, TCS was expected to develop sufficient expertise to be able to support client systems and applications in the future. Toward the end of the transition stage, TCS staff observed how Bank personnel resolved incidents. This was followed by TCS assuming the primary support role whereby onsite and offshore experts jointly engaged in solving incidents and providing support, under the observation of the Bank experts, until they were confident that TCS employees could support applications without help from the Bank. This signaled the completion of the transition stage and a shift to a steady state, which meant that the Bank was running "business as usual" with TCS resolving all incidents (e.g., when the Bank's systems stopped working or malfunctioned causing disruptions to the Bank's business processes), and providing maintenance and enhancements for the Bank's systems. In this paper, we focus on the transition stage.
As this offshore-outsourcing project required TCS to take over hundreds of applications from the Bank, developing the expertise required to support these applications appeared to be a critical issue to the TCS team. TCS management was challenged by the extent of the gap in expertise and experience between the Bank experts and the TCS onsite-offshore project team. The transition plan was to acquire hundreds of applications from the Bank within a three-month period. To be able to accomplish this task, the TCS onsite-offshore team had to demonstrate great efficiency in coordinating expertise, both when learning about the client's systems, and later on when solving "dummy" and real incidents. In the following section, we present TCS's approach to expertise coordination throughout the transition stage and we use vignettes to convey a rich account of what activities were carried out during these specific episodes, and the role of codification in supporting these activities.

Findings and Analysis
Given the high level of uncertainty regarding the knowledge that TCS needed to acquire from the Bank's subject matter experts (SMEs), TCS initially adopted a structured approach to managing the knowledge interdependencies between the Bank's SMEs and the onsite and offshore staff. During the earlier stages of the transition, expertise coordination relied to a great extent on formal and well-structured mechanisms such as roles, routines, and protocols. However, when it came to resolving dummy and real-life incidents in the later stage of the transition, onsite and offshore experts came to rely to a much greater extent on an improvised mode of coordination (Donaldson 2001;Faraj and Xiao 2006;Majchrzak et al. 2007). Before exploring expertise coordination in detail, Figure 2 figuratively represents how different settings between client, onsite, and offshore personnel are connected, thereby helping to zoom out to the temporally unfolding process of expertise coordination.

Structured Coordination Mode
All TCS employees, onsite and offshore, were familiar with its transition methodology, which was a highly codified, canonical body of knowledge that was widely applied and followed by the offshore-outsourcing project teams. This methodology defined the workflows for the process of the transition that included high-level steps, deliverables, and quality measures, as well as corresponding fine-grained routines that defined the sequence of interactions between remote parties. Specific TCS templates (e.g., TCS standard 8 In the outsourcing literature, the transition stage is associated with transfer of processes to an offshore location (Srikanth and Puranam 2011). 9 Because of the scale of the outsourcing project (large number of applications to be transferred to TCS), applications were divided into three groups, so that the transition of each group would be managed separately, as a wave. The term wave is an industry term referring to chunk of work (here, a group of applications). forms to capture application specifications) and protocols (e.g., for quality checks and structuring interactions with client personnel) were part of this methodology. The transition methodology also established as an organizing principle that the organizational structure of the onsite-offshore team should "mirror" the client firm's structure at both the onsite and the offshore locations (see Appendix D). In accordance with this principle, TCS mirrored the Bank's three portfolios of applications by allocating separate subteams for each. Within this organizational structure, explicit correspondences were established between the roles of Bank, onsite, and offshore personnel.
In following the TCS methodology, however, it was clear that TCS employees were not simply seeking to replicate or copy the knowledge of the Bank's SMEs. Only rarely did the TCS onsite and offshore experts seek to document knowledge exactly as it was communicated to them by the Bank's SMEs.
As one onsite expert explained, "We hear what they say, but for us it is like-what does it mean?" In particular, onsite experts typically rephrased the information provided to them by the Bank SME and put it into TCS terminology, as this helped them (and other TCS staff) to understand it. Documenting existing knowledge involved interactions and negotiations between the different groups to ensure that what was being codified was also understood and agreed. As Amit, an onsite portfolio manager, put it: We had some [face-to-face] sessions with Bank SMEs and business managers. Some of the sessions were even video recorded. That's where you start gaining knowledge, because we first checked with the Bank SMEs and they told us, "that's OK," then we checked with business managers, and they told us to correct this and that. We went back to the Bank SMEs and they said, "yes, that is correct." These face-to-face learning sessions between onsite members and Bank SMEs were driven by the onsite members who led SMEs to focus on specific aspects of the applications that it was important to capture, based on the protocol intended for capturing relevant client knowledge. The knowledge acquired was also reorganized to suit TCS templates, which sought to capture application specifications, as well as identify and capture interdependencies and interfaces between multiple applications. TCS experts then documented the information in the relevant templates based on the fields required, such as business functionality, technical functionality, and programming language.
Below we present five vignettes that describe expertise coordination from the point of view of two counterparts, Sreekrishna (based onsite) and Shilpa (based offshore), who were involved in the transfer of several applications from the Bank to onsite and then offshore. Each vignette zooms into different settings under which expertise coordination took place: between the Bank SME and the onsite team member (vignette 1), between onsite and offshore members (vignette 2), between offshore staff and the Bank SME (vignette 3), and between offshore and onsite staff and the Bank SME (vignettes 4 and 5).

Vignette 1: Client-Onsite
Sreekrishna, a TCS onsite module leader, was responsible for acquiring the knowledge of six Bank applications. Although he had previously implemented the TCS transition methodology several times, the start of the transition process put him in a difficult position. He knew little or nothing about each application while the Bank SME brought with her extensive knowledge (over 20 years experience) of the applications, as well as an understanding of their relevance to the broader context of business services. Sreekrishna had had six years of experience in similar offshore-outsourcing projects at TCS before being selected to join the TCS-ABN AMRO onsite team.
Sreekrishna began the learning process to perform his role by following the steps in the TCS transition methodology. First, he requested and received from the Bank numerous documents that described the applications' functionality and other technical aspects. Sreekrishna spent several days going over these documents. As the next step, he arranged for a face-toface session with the Bank SME in order to get a better overview of the applications. TCS refers to these as "learning sessions"; they rely on TCS protocols. One portfolio manager stated: One of the very important things that we've learned during transition is that TCS associates ask a lot of questions; they drive the ABN AMRO SMEs into giving knowledge because the SMEs are not really aware as to where they should actually start out first. I mean, "Do I start from the technicalities, is it business, is it the risks involved, is it the users?" ....So ABN AMRO SMEs have all the applications knowledge but getting it out in the right fashion is something that is driven by TCS.
Following the face-to-face session with the Bank SME, Sreekrishna prepared summary documentation to capture what he had learned so far. He filled the TCS template forms with what he learned about his applications. There were several types of media that Sreekrishna incorporated in the documentation, including screenshots of application functionality, the text which was taken from the Bank's applications documents (after they were translated from Dutch to English), and his own description of the business purpose and technical functionality of the applications.
While Sreekrishna used TCS terminology to fill the templates based on what he had learned from the Bank documentation and SME, he also drew on his own expertise based on past projects to enrich the codified applications documentation. We sought clarifications from Sreekrishna about what he learned from the Bank SME. An example follows: S: There were many details that she [Bank SME] shared with me, but at some point I was thinking, hey, this is exactly like the system I was working on before. Sreekrishna sought to include additional information in the application documentation that linked his own expertise with a possible behavior of the Bank's application.
However, Sreekrishna was not intending to capture all the knowledge held by the Bank SME. According to him, only "the most critical concepts of the applications" were captured. In addition to the business and technical aspects, other critical elements captured by Sreekrishna were interfaces or interdependencies with other applications and the future roadmaps for the applications. The summary documentation was then shared with the Bank SME to be checked and approved.
Once the Bank SME approved the summary documentation, Sreekrishna uploaded it onto CASCADE, a configuration management tool that offshore experts could access. [End of vignette 1.]

Vignette 2: Onsite-Offshore
Shilpa was the offshore team member in Mumbai whose responsibility was to capture the applications knowledge from Sreekrishna. In response to the high attrition level that many IT vendors experience in India, each application was assigned both a primary and secondary expert to ensure that application knowledge was retained. Shilpa was a secondary expert for the four out of six applications that Sreekrishna was responsible for as a primary expert. Shilpa joined TCS seven months before joining the ABN AMRO project and had 3.5 years of work experience in similar offshore-outsourcing projects for another Indian IT vendor. Shilpa spent three months in Amsterdam (during wave 1 of the transition) prior to starting the transition of applications with Sreekrishna on an assignment where she transferred a different set of applications from onsite to offshore acting as the TCS onsite expert.
As she returned to Mumbai, the transition of four applications from Sreekrishna had started. At that point, Shilpa's knowledge of the four applications was limited, but she had handson experience with the TCS transition methodology from working on her previous assignment in an onsite role. She had also acquired business and technical knowledge of other applications when she acted as an onsite expert. Shilpa's interactions with her counterpart began when Sreekrishna informed her that the applications documentation was ready for her to review on CASCADE and arranged for a telephone conversation with Shilpa in order to "walk her through" the details. During this telephone conversation, Sreekrishna explained to Shilpa the business and technical functionality of the applications, using images included in the documentation.
Offshore experts, such as Shilpa, typically echoed the onsite experts' view that the maintenance of an application does not require extracting all of the in-house knowledge from the Bank SMEs. However, as they were remote from the SMEs, their ability to assess whether they were acquiring the critical knowledge was more limited. Shilpa's manager, who was a portfolio manager, explained: It's really just an act of understanding rather than transferring the tacit knowledge… because you're going to change the maintenance and the development processes anyway.
Shilpa's challenge was, therefore, to understand the basic functionality in order to allow her to deal with incidents and make changes in the application in the future. After the first walk-through, Shilpa was given the opportunity to further examine the documents, engage with the "live" application site (source code), see how the application reacted to inputs, and examine how the source code behaved as a result of changes in input. According to Shilpa's portfolio manager,

Vignette 3: Offshore-Client
While Sreekrishna developed a sufficient understanding regarding Shilpa's knowledge of the applications, the Bank SME did not have the opportunity to test the knowledge of the offshore expert (e.g., Shilpa). To demonstrate to their client that the offshore team had developed a sufficient level of expertise to support the Bank's applications, TCS offered a "play-back" session to the Bank SMEs. For TCS employees, the concept of such sessions was not new as it was one of the procedures in the transition methodology. A video conference was set up between Shilpa and the Bank SME (accompanied by Sreekrishna) during which Shilpa explained to them the functionality, technical aspects, and business purpose of the applications. In doing so, Shilpa was using the application documentation she and Sreekrishna developed over the course of numerous interactions. Once the Bank SME was satisfied with the level of knowledge demonstrated by Shilpa, the transition process moved to the following stage, where Shilpa and Sreekrishna were assigned to solve the dummy incidents that were engineered by the Bank SME. [End of vignette 3.]

Improvised Coordination Mode
The applications that TCS acquired from the Bank had varying levels of stability. Applications where the Bank's own maintenance had involved few changes or incidents were classified as stable applications, while applications that had experienced a high number of changes or incidents were considered unstable. An unstable application was actually considered to be more helpful to the transition process because, first, the application documentation that the Bank had developed was usually up to date, including records of the latest changes. Second, the Bank SMEs' recollection of the business and technical functionality of the application was still fresh. These factors were highly relevant to expertise coordination, because having demonstrated to the Bank their ability to acquire and retain application knowledge offshore, the team now needed to demonstrate its ability to solve dummy incidents in these applications. Thus coordination was no longer about playing back the acquired knowledge, but rather demonstrating the ability to integrate the knowledge developed onsite and offshore so as to derive expert conclusions with regard to the source of the incident, as well as possible means of fixing it. In effect, solving these dummy incidents tested TCS's ability to respond in a timely manner to the problems that the client would be facing in the future, during the steady state period, after transition.
In the following two vignettes, we describe how Sreekrishna and his offshore counterpart, Shilpa, dealt with incidents in both unstable (vignette 4) and stable (vignette 5) applications and the implications for expertise coordination. Both vignettes zoom into the client and onsite-offshore setting within which expertise coordination took place.

Vignette 4: Solving Dummy Incidents in Unstable Applications Using Codified Knowledge
The Bank SME started the incident phase by sending across a dummy problem. In unstable applications, a dummy inci-dent is a problem that the team has experienced in the past. Three of the four applications that Shilpa acquired offshore were considered to be unstable. The messages about dummy incidents were not sent directly to Shilpa or Sreekrishna but rather to head of the transition stage, who needed to (1) identify which specific application(s) were affected by the incident, and (2) identify and contact the primary and secondary experts of the affected application(s) and notify them about the incident. In the case of an easy incident, if one of the applications that Sreekrishna and Shilpa were responsible for was affected (e.g., an application was not functioning as expected), the head of the transition stage notified Shilpa and Sreekrishna. Their names and contact details were recorded in the knowledge base portal of the project and linked to the applications documentation stored in the same portal. Shilpa and Sreekrishna initiated a problem-solving web session (using text-and voice-chat online). Both Sreekrishna and Shilpa used the updated documentation stored on CASCADE when discussing the root cause and when considering the effect on the system. As they gradually realized the scope of the incident and identified the problematic application, the application's documentation became central to their subsequent actions. They needed this documentation to assess which other applications might be affected by the incident, as well as to identify in the portal the primary and secondary experts for these applications and notify them. As they worked their way through the solution, understanding the implications for the system and contacting colleagues to warn them about the implications for their applications, Shilpa and Sreekrishna successfully completed the dummy incident test.

Vignette 5: Solving a Real Incident in a Stable Application by Bringing in Expertise
The only stable application that Shilpa and Sreekrishna acquired (hereafter, ST application) posed additional challenges for them throughout the transition and in particular during the problem-solving phase. For one, the documentation for the ST application that the Bank shared with Sreekrishna was outdated, and the SME had very little to add about this application from her experience. As a result, to develop meaningful documentation that would enable her to understand the functionality of the ST application in full and play it back to the Bank SME, Shilpa had to go back to the application source code and document her understanding of the application's functionality (using the standard TCS template form). However, even a reading of the source code could not account for some of the issues that the applications documentation needed to capture, such as business functionality and interfaces with other applications. In consequence, the documentation for the ST application created by Shilpa and Sreekrishna was incomplete.
Dummy incidents provided by Bank SMEs were typically based on real incidents that the Bank SMEs faced in the past. But, as ST applications lacked such incidents, Sreekrishna's and Shilpa's problem-solving expertise could only be tested by solving real incidents. One example of this came when Shilpa and Sreekrishna were contacted by a pair of experts, Ravi (onsite) and Manish (offshore), who were analyzing an incident in their application (hereafter, RM application). Ravi and Manish's efforts had identified the ST application as a possible source of the incident. Sreekrishna and Shilpa received information from Ravi and Manish about the nature of the problem and, following this, started looking for the root cause of the incident in their application. However, the documentation of the ST application was somewhat limited, and examination of the source code was proving to be timeconsuming and futile. As this was a real incident, there was a sense of urgency to resolve it quickly.
To resolve the problem, Sreekrishna and Shilpa decided to seek help outside the onsite-offshore team. In seeking the most appropriate person within TCS who could help, they were guided initially by the way their documenting efforts had classified the ST application's specific technology. Using this information, Sreekrishna and Shilpa were able to use the TCS knowledge portal tool to identify and contact an expert from one of TCS Centers of Excellence 10 (CoEs) that specialized in this technology. Working together with this external expert, Shilpa and Sreekrishna (as well as Ravi and Manish) were able to resolve the incident and get the RM application working again. As a result, Shilpa and Sreekrishna enhanced their understanding of the ST application and could augment the documentation with additional characteristics of the application and its interfaces with the RM application. The incident itself and the way it was resolved (including the identification of specific individuals involved) was then documented in the knowledge portal. [End of vignette 5.] On this occasion (vignette 5), the use of the codified artefacts, such as documentation and the source code, enabled Ravi and Manish first to find the link between the failure of their RM application and the ST application. Second, information linked to the ST application in the knowledge portal pointed Ravi and Manish to the primary and secondary experts of the ST application, so that they contacted Shilpa and Sreekrishna directly. Later on, as Shilpa and Sreekrishna could not solve the incident, they used information about the relevant technology to identify the appropriate expert from the relevant CoE. This link between the ST application and the specific technology was captured in the standard TCS template used to create specifications for these applications.
Vignettes 4 and 5 describe the typical patterns of expertise coordination as onsite and offshore members engaged in problem-solving. As we observed, onsite and offshore experts responded to real incidents by initially having recourse to the application documentation they developed. Failing this, they drew on their own expertise, or, if necessary, accessed the expertise of primary and secondary experts responsible for other applications that they suspected might have been affected. As a last resort, they identified and involved appropriate experts from the relevant CoE.
In the following section, we zoom out to the temporally unfolding process of expertise coordination (as depicted in Figure 2), aiming to understand how the codification practices we have described in the vignettes above changed over time, and how they supported expertise coordination efforts.

Zooming out to Understand the Changing Role of Codification
As the multiple actors involved in offshore-outsourcing (client, onsite, and offshore personnel) coordinated their expertise, they engaged in various codification activities that helped them deal with knowledge boundaries and geographical distance. First, in the efforts made by TCS staff to acquire and document the knowledge possessed by Bank SMEs, their codification efforts encompassed translation across knowledge boundaries; that is, translating the Bank's knowledge into a form and language meaningful within the terms of TCS expertise, and thus helping to overcome both syntactic and semantic differences between the groups involved. As we noted, the knowledge acquired from SMEs was reorganized by onsite staff into the TCS templates. Then, these templates were used by onsite and offshore counterparts who engaged in a back-and-forth interaction aiming to synchronize their knowledge and reach an agreed understanding of what was being codified.
Focusing on Sreekrishna's interactions, first with the Bank SME and then with Shilpa, we observed how, initially, TCS's codification efforts supported learning, thereby transforming expertise and reducing the knowledge asymmetry between Sreekrishna and the Bank SME, and then between Sreekrishna and Shilpa. This learning benefit highlights the way in which codification, by, in effect, externalizing knowledge, allows individuals to rearrange, manipulate, and examine symbols and symbolic relationships in order to transform the underlying knowledge represented in such systems (see Foray and Steinmueller 2001). As we noted, this symbolic manipulation also enabled individuals like Sreekrishna to draw on 10 In TCS, Centers of Excellence are formal networks of experts with advanced knowledge in several domains related to specific technologies (e.g., Windows-based technologies, Java-based technologies), industries (e.g., human resource management), services (e.g., service practice) and other areas.
their own expertise when codifying knowledge, thus making it more accessible and relevant to others. Furthermore, during these codification efforts, the TCS team captured links to experts who developed codified artefacts (e.g., source code, documentation). Later on, when solving real incidents, these documents were consulted in order to identify the person with relevant expertise.
These observations based on zooming into specific settings suggest that codification efforts may play a variety of roles in supporting expertise coordination. However, when zooming out and relating these different roles to the mode of coordination, we find a shift in emphasis in both (1) codification practices and (2) how their outcomes are supporting coordinative action. As outlined in Table 1, in the structured mode of coordination, the codification of knowledge (we refer to such efforts as knowledge codification practices) supports the spread of common knowledge and hence the implementation of routinized practices between onsite and offshore members. In the improvised mode, however, this body of codified knowledge is deployed more as a tool or resource to enable individual experts to address dummy and emergent problems. In a similar vein, in the structured mode, we see the establishment of codified links between applications and identified individual experts. Reflecting on our previous discussion of expertise, this group represents the knowers whose expertise-localized and situated in practice-transcends the substantive content of the codified knowledge contained in these artefacts. We refer to the codification efforts that focus on codifying the characteristics of individuals as codification of the knower practices. 11 In the improvised coordination mode, we find that these practices are activated by the need to draw on more widely distributed expertise in resolving emergent or dummy incidents.
As outlined in Table 1, knowledge codification and codification of the knower emerge as complementary practices from our study. But, while knowledge codification practices were central to expertise coordination during the transition process as a whole, we found that the codification of the knower practice emerged as particularly significant to improvised coordination, when unanticipated problems (i.e., not encompassed by existing canonical knowledge) needed to be addressed. These observed changes in the relative importance of different codification practices prompted us to carry out a further phase of data analysis, aiming to understand the dynamics between codification, knowledge boundaries, and transforming expertise, which we discuss below and link to our theoretical contributions.

The Multiple Roles of Codification
The shifts in codification practices across coordination modes can be understood by tracing the emerging relationship between the transformation of expertise and the coordination task at hand. As evident from the vignettes associated with the structured coordination mode, the codification of knowledge was initially deployed in the service of establishing routinized actions. Individual experts were following a prescribed methodology, and were heavily reliant on codified knowledge in the form of routines, protocols, and templates for applications documentation. Through the development and use of this documentation, however, TCS employees were also learning and transforming their own expertise, as they were integrating the knowledge of Bank applications with their own experience from previous assignments.
When the mode of coordination became more improvised in order to address unpredictable problems, as with the need to solve dummy and real incidents, the limits of codification as routinized action were reached (Nelson and Winter 1982), and individuals were required to apply their transformed expertise in a flexible, improvisational fashion. This enabled them, as outlined in Vignette 4, to move beyond the enactment of routines, and to use the codified knowledge of such applications as a tool to solve problems. Where it was possible, the onsiteoffshore team sought to solve these problems themselves. As outlined in Vignette 5, however, the more intractable problems could not be resolved by this combination of codified knowledge and local expertise but required access to the wider expertise of the TCS organization as a whole. At this point, the practice of codification of the knower becomes important as the identity of relevant individuals emerges as critical to accessing relevant expertise.
This relationship between the transformation and distribution of expertise (i.e., between client, onsite, offshore, and the wider TCS organization) on one hand, and the role of codification on the other is summarized in Table 2. It is important to note, however, that this table cannot capture the dynamic nature of the interplay between expertise and codification observed in our study. As we have outlined, codification efforts supported learning by individuals, and thereby enhanced the expertise of teams and the wider TCS organization. This expertise was, in turn, represented in the codified knowledge, 11 Our distinction between the two types of codification efforts as representing different approaches to the object that is being codified is consistent with the distinction that Okhuysen and Bechky (2009) make in their synthesis of coordination literature, which, as they observe, has a variety of approaches to the object of what is being coordinated through coordinative action (p. 481). track changes • Use of protocols to guide specific knowledge acquisition activities (e.g., how to structure learning session with SME) • Use of multiple images in the application documentation (e.g., text, images, parts of the source code) • Video recording some sessions with client personnel

Purpose of these practices: , Reducing knowledge inter-dependencies between
Bank SME, onsite, and offshore personnel , Reducing knowledge asymmetries between onsite and offshore personnel , Serving as a reference point when translating client's knowledge and cocreating understanding of the client applications and systems • Application documents were consulted to look for a root cause of dummy and real-life incidents • Central database was used to access most updated documents • Relevant documents were updated after an incident was resolved

Purpose of these practices: , Serving as a source for updated information about the applications to find a root cause of an incident
Codification of the knower practices • Reliance on formal roles linked to specific individuals to drive development of expertise in a specific area (e.g., roles captured in the mirror organizational structure of the project team, primary and secondary experts) • Capturing information about specific individuals in documents they have written (e.g., applications specifications) • Capturing information about individuals that made changes in the source code (e.g., via "ownership" of parts of the source code that was tracked in the configuration management tool)

Purpose of these practices:
, To create links to specific individuals who were involved in the development of specific expertise, capturing changes in their involvement with different applications over time • Links to specific individuals (roles and responsibilities) were used to find those who were responsible for applications that were affected by the incident • Links to specific individuals captured within applications documentation and source code were used to solve an incident • Links to experts within CoEs were used to get help from experts outside the project team

Purpose of these practices: , To identify and bring together individuals with expertise in relevant functional domains and understanding of the context to jointly find a root cause of an incident and resolve it
which TCS experts developed to support the transition process by incorporating links to individuals in the development of documentation (as shown in Table 1). It was made more visible and representable by being acquired through a codified methodology, and by being applied within an explicit structure of roles and responsibilities, which mirrored the client organization. These cumulative developments thus enabled teams to relate the problems they were experiencing to the expertise developed by specified individuals at an unusually fine-grained level of detail.
As shown in Table 2, our analysis suggests that codification plays multiple roles in expertise coordination; that is, the outcomes of codification practices (summarized in Table 1) support expertise coordination in different ways. In playing these different roles, codification helped the TCS team to overcome the different knowledge boundaries and asymmetries encountered at different stages of the transition. The relationship between such codified knowledge and the expertise of TCS staff was a dynamic one, as the codification efforts themselves, and the subsequent use of codified knowledge, not only helped to create shared understanding, but also contributed to the transformation of team members' personal expertise. Onsite-offshore members were thus able to bring to bear (Faraj and Sproull 2000) such expertise to solve problems during the final stages of the transition. Furthermore, as Codification as formulating rules (i.e., TCS Transition methodology) that capture knowledge in the form of canonical practices (Brown and Duguid 1991).
Codification as externalizing client's knowledge and embedding it in artefacts such as documents.
Codified documentation as enabler of storage and transfer across time and space (Foray and Steinmueller 2001).
Codified artefacts (documents, visual representations, record of queries, source code) as a tool to facilitate translation of client's knowledge (Carlile 2004;Levina and Vaast 2005) and cocreation of understanding (Vlaar et al. 2008). Rearranging and examination are some of the activities enabled by codified artefacts.
Codified artefacts (documentation and multiple visuals) as articulation of knowledge (Zollo and Winter 2002).
Codified links to knowers as enabler to mobilize distributed experts.
Codified artefacts as a source for examination and manipulation to facilitate transformation of expertise (Foray and Steinmueller 2001).

Transformation of expertise
Learning in collocated setting.
Learning in distributed setting.
Articulation of understanding (Zollo and Winter 2002) to demonstrate credibility of expertise (Lewis 2004).
Transformation of understanding through decontextualization and recontextualization (Bechky 2003) when working jointly with other experts resolving incidents.
TCS experts encountered the limitations of codified knowledge for various reasons (e.g., lack of implicit knowledge embodied in codified documents/source code received from the client (Leonardi and Bailey 2008), and lack of tacit knowledge and documentation about some stable applications), it became imperative to quickly find relevant experts or knowers. Faraj and Sproull (2000) term this aspect of expertise coordination "knowing expertise location." While the multiple roles of knowledge codification have been previously identified in the literature, although often in non-IS domains (e.g., Brown and Duguid 1991;Prencipe and Tell 2001), an important theoretical contribution of this paper is to highlight the link between the distributed expertise arising from knowledge boundaries, and the multiple roles that codification plays in supporting the coordination and transformation of expertise over time. In a high-velocity environ-ment, such as offshore-outsourcing, codification practices enable teams of dispersed experts to learn and transform their expertise over a short period of time, between the start and completion of the transition. As presented in Table 2, the coordinative role of codification evolved during the transition, from a guiding role through canonical practices, to enabling remote collaboration, facilitating translation of the client's knowledge through written and visual representations, and, finally, to enabling the mobilization of dispersed expertise through links to experts. Figure 3 12 depicts (schematically) how these multiple roles of codification rely on and reinforce each other over time in the efforts to coordinate distributed expertise.
Here, our attention to the practices of codification, and not simply their observable outcomes, help to show their multiple and dynamic effects on expertise coordination. Thus, while the different roles of codification have been acknowledged in past research (we refer to specific roles and the major sources that have highlighted these roles in Table 2), such studies have shed little light on the dynamic nature of codification as expertise evolves. Our research extends the previously common view of codification as a static concept by demonstrating the multiple, coexisting, and complementary roles that codification may play, as well as the changes in the relative importance of various codification roles when coordinating distributed expertise.
The multiple codification roles supporting expertise coordination took place through two codification practices, knowledge codification and codification of the knower (depicted in Table 1). The distinction between these two complementary practices is the core of our second theoretical contribution, as discussed below.

From Codification of Knowledge to Codification of the Knower
This contribution involves reconceptualizing the commonly accepted view of codification as facilitating replication and diffusion of knowledge (Nonaka 1994;Winter 1987;Zander and Kogut 1995). While past research considered knowledge to be the main focus of codification efforts, the role of the codification of the knower represents a novel contribution to the literature on codification, and expertise coordination.
In our analysis, codification of the knower emerged as an important mechanism for the coordination of expertise as it provided links to knowledgeable individuals (experts) in situations when tacit and personalized expertise was required. This refers to the standardized representation of expertise that enables it to be identified and accessed remotely by a range of organization members. In practical terms, it involved developing representations for the following features that were associated with specific individuals in the onsite-offshore team and wider organization: identity, area of responsibility, role within the organizational structure of the project team, area of expertise for individuals recognized as formal experts in specific area, and a contact link to the expert for ready communication. In Table 3, we summarize what was codified about the knower (i.e., the combination of which characteristics), and how it was codified (e.g., in what type of artefact or by which organizational mechanism). Furthermore, this table illustrates how this information about the knower enables expertise coordination processes.
At one level, the codification of the knower highlighted above may not be viewed as qualitatively different from the codification of knowledge, in as much as it produces lists of objects with defined attributes. However, these practices can be distinguished if we focus not on the way knowledge is being embedded in an artefact, but rather on how it is to be used. Codification of the knower in this sense does not provide a guide for action, or a tool to be immediately applied to solving a problem. It identifies a person with expertise relevant to that problem.
The importance of making this distinction is amply underlined by the problems organizations have experienced in seeking to develop more elaborate directories in which the generalized expertise of individuals is represented (Alavi and Tiwana 2002). For example, experts may seek to stage-manage the information that is given about them to achieve personal goals (Leonardi and Treem 2012). Equally, as a study of a competence directory at Volvo found, attempts to impose standardized competence definitions may be found wanting for being too generic, and based on past experience or qualifications rather than current performance. As one manager at Volvo observed, If I search for competence, the system should support me in identifying the appropriate person. Such features are missing in the system. Instead, I have to talk to someone who is familiar with the employees (Lindgren et al. 2004, p. 450).
What these experiences show is the difficulty of codifying expertise in a meaningful way when its embodied and dynamic 12 The diagram in Figure 3 is based on the case study findings, and is complementary to Table 2, which describes changes in knowledge boundaries and transformation of expertise over the transition.  • TCS templates used to document application specifications included information about team members who worked on the document, including their role, contact details and changes they have made in the documents. • Using the configuration management tool, onsite and offshore experts found information regarding (1) who owned a particular revision in the application document, and (2) who made changes in the source code and when.
Codifying these characteristics of the knower made it possible to contact this person (or his/ her substitute in the same role) if there were queries relating to the specific application when dealing with an incident (improvised coordination mode).
Codifying management roles in organizational structures onsite and offshore, and contact details.
• TCS adopted a formal organizational structure that replicated the client's organizational structure at both onsite and offshore locations.
Adopting an organizational structure at onsite and offshore locations that is identical to the client's structure ensured that client personnel, onsite and offshore experts could easily identify and contact their corresponding counterparts regardless of geographical distance (structured coordination mode). Codifying identity, areas of responsibility, and contact details.
• Instituting a primary and secondary expert for each application at each location (one onsite and another offshore). These areas of responsibility (and contact details of the experts) were recorded in the project portal and linked to applications documentation created by TCS.
(1) By allocating area of responsibility (primary and secondary expert) to team members TCS ensured a symmetric development of expertise at onsite and offshore sites (structured coordination mode).
(2) Knowing who the primary and secondary experts in each application were enabled onsiteoffshore members to find relevant experts when solving dummy and real-life incidents (improvised coordination mode). Codifying where expertise resides within as well as outside the offshore-outsourcing project team through a database of recognized experts: their identity, areas of expertise (e.g., technology/ industry), and the contact details.
• Capturing in project portal and TCS-wide expertise management systems information about formal networks of experts, such as CoEs (TCS-wide CoEs and ABN AMRO CoE).
The database of formally recognized experts and their association with specific CoEs made it possible for members of onsite-offshore team to find relevant expert outside their project to get help with resolving incidents (improvised coordination mode).
dynamic qualities make it resistant to elaborate forms of codification. At the same time, it underlines the value of the approach at TCS of codifying the knower, whereby the identity of individuals is linked to codified knowledge around specific applications. This has the practical advantage of better representing the expertise of individuals as it was transforming over time. For example, any changes in roles were reflected in the relevant documents. Similarly, any changes in the source code were tracked in the configuration management tool and could point to the individuals who made the relevant changes.
More importantly, however, by viewing this practice through the lens of expertise coordination, we can see that codification here is not in the service of explicitly representing expertise in terms of occupational skills or competences. Rather, it is seeking to support the interrelating of expertise (Tsoukas 1996) by providing information about the knower associated with a particular element of codified knowledge. In effect, this allowed TCS employees such as Shilpa to reassemble the codified knowledge and the knower, thus supporting reciprocal interactions and ensuring the appropriate coordination of expertise required by more unstructured problem-solving situations. In pursuing the trail created by codification of the knower, TCS staff were not looking for professional competencies but for access to the learned and embodied expertise, which was specifically relevant to an application-the finegrained level of detail we observed previously.
The different roles played by codification here can be related to wider theoretical debates. As Nelson and Winter (1982) observe, the scope of codification is defined by a particular context. Thus, codified knowledge supports structured coordination in those contexts where it serves as a guide and a shared tool for action. Such contexts are shaped, however, both by the knowledge boundaries between groups and by temporal boundaries (as with breakdowns in routine and incidents in our study) (see Bechky 2003). Beyond these boundaries, and faced with unstructured problems, we observe that expertise coordination becomes more reliant on reciprocal interactions between knowers. Unlike the dichotomized views within the existing literature, however, we find that codification does not become irrelevant at this point, but may continue to support coordination as codification of the knower builds on and complements the codification of knowledge.

Practical Implications
In questioning existing dichotomized views of the role of codification, our study also provides valuable insights on its application in practice. Thus, it helps to explain why a narrow focus on codification as simply externalizing or depersonalizing knowledge may prove to be counterproductive, especially when it limits rather than supports the necessary interactions between knowers. Some of these counterproductive effects are highlighted in Vaast and Levina's (2006) account of an organizational redesign initiative in which "codification erased…unique value-add which was based on interpersonal relationships, and led them to seek external IT service providers to replace the 'faceless' internal provider" (p. 199).
For the offshore-outsourcing setting specifically, our study shows how the importance of the effective management of expertise is increasing inexorably. For the vendor, this represents a key competence, and for the client, an important criterion in their vendor selection list. Indeed, the findings from this offshore-outsourcing project may also be relevant to other globally distributed projects engaging in knowledge work across more than one site.

Implications for Vendors
Almost any offshore-outsourcing project will involve a transition phase in which the vendor team will need to develop expertise in the client's systems and services in order to maintain and further develop these services from the offshore location. In doing so, vendors should consider investing in the codification of knowledge, as well as incorporating links to experts to facilitate access to distributed expertise across the organization. This is particularly relevant to the contemporary vendors' challenge to maintain high margins in such offshore-outsourcing projects (Gopal and Sivaramakrishnan 2008). As described in this case, the transition methodology applied by TCS resulted in a limited need to exchange personnel between onsite and offshore locations during the same wave of the transition, and as a substitute the team mainly relied on technology-mediated communication to facilitate expertise coordination processes that relied on codification practices.
Second, as the coordination of expertise across multiple locations has become a challenge to organizations, several of the practices reported above can be considered by other vendors for incorporation into their transition methodology. For example, the use of TCS templates during learning sessions between the Bank SME and the onsite specialist in order to translate the Bank's application knowledge into TCS language and terminology enabled the organization of the knowledge according to the TCS codification scheme, which also included links to information about the knower. The organization of the onsite and offshore staff according to the organizational structure of the client firm (termed here mirroring) was reported to improve coordination by codifying the roles. Similarly, the use of primary and secondary specialists for each application also contributed to expertise coordination, in particular during problem-solving, as these roles and ownership of changes made were codified in the applications documentation. In this regard, we do not argue that IT vendors should revamp their transition methodology; however, we see opportunities to include some of the practices reported above in their existing methodology.

Implications for Clients
We also see opportunities for client firms to benefit from the practices reported in this paper. First and foremost, as the client firm's service reputation is in the hands of its outsourcing vendor, it becomes rather concerned with the vendor's ability to rapidly absorb system and services knowledge to the extent that the vendor is able to provide the same level of service and in the future improve the functionality and performance of outsourced services. Thus, the detailed account of how one vendor coordinates expertise can inform client firms about the resources and processes involved in expertise coordination between onsite and offshore locations.
In this regard, based on the practices reported above, client firms should pose questions to IT vendors regarding their transition methodology and the firm's ability to learn about the client's systems but also retain and further develop this expertise over time. Client firms should consider including play-back and dummy incident sessions as part of the transition methodology to ensure that vendor personnel at the offshore location reach the same level of expertise as at the onsite location. By engaging in the detailed planning of the transition methodology, client firms become more committed to allocating the resources needed, such as the availability of their SMEs, but also better understand the effort and, therefore, the costs borne by the vendor during this critical phase.

Limitations and Future Research
Our findings are based on one case study and, therefore, by definition, only meet to a limited extent the criterion of generalizability. In this research we generalize (1) from data to description and (2) from description to the theory that is generalizable within the case setting (Lee and Baskerville 2003). In order to generalize from our theory to descriptions of other settings, further research needs to be conducted in other settings. In particular, our findings reveal a need to rethink the implications of codification for coordination within and between expert teams, which we suggest as a focus for future research. Our initial definition, drawn from the literature, presented codification as the "compression of knowledge and experience" (Whitaker et al. 2010, p. 19). However, as our study has shown, attention to the detail of codification practices suggests that this definition may conceal a multitude of roles that codification may play in coordinating expertise within organizations. Further research exploring such practices may better address the interplay between the codification of knowledge and the transformation of expertise in a way that relates this more systematically to particular organizational or industrial settings.