A Dialogic Perspective on Managing Knowledge Differences: Problem-solving while building a nuclear power plant safety system

Abstract

To manage knowledge differences, existing research has documented two sets of practices: traversing and transcending knowledge boundaries. What research has yet to explore, however, is the dynamics through which traversing or transcending practices emerge in response to a particular problem situation. Using a qualitative, inductive study of the problem episodes encountered by groups of experts working on a large-scale project to build the safety system for a nuclear power plant, we observed that the emergence of traversing or transcending depended on how experts interpreted problems and initiated dialogues around specific problems. Our work provides insight into the condition through which knowledge integration trajectories may emerge.

Integrating knowledge across functional experts working together on projects like R&D, software development, and large-scale engineering designs is challenging. Problems emerge throughout cross-functional collaboration (Ben-Menahem, von Krogh, Erden, & Schneider, 2016; Faraj & Xiao, 2006; Tsoukas, 2009) because knowledge is deeply rooted in domains with distinct values, interpretations, norms, and beliefs so that experts need to overcome gaps between their individual ‘thought worlds’ (Dougherty, 1992), different ways of conceptualizing focal issues (Bechky, 2003), divergent interests (Carlile, 2004), and different perspectives (Carlile, 2002; Majchrzak, More, & Faraj, 2012) to integrate expertise. Research has revealed practices through which experts negotiate those knowledge gaps. We borrow Majchrzak et al.’s (2012) terminology to label two approaches to overcoming knowledge gaps as ‘traversing’ and ‘transcending’ knowledge boundaries. Traversing involves investing time and effort to identify, clarify, and negotiate deep-level differences and establish common ground (Bechky, 2003; Faraj & Xiao, 2006; Okhuysen & Bechky, 2009), creating bridges between knowledge domains. Transcending involves integrating knowledge without directly addressing differences (Berends, Garud, Debackere, & Weggeman, 2011; Majchrzak et al., 2012). That can create new scaffolds or frameworks that combine expertise from multiple domains (Harvey & Mueller, 2021).

In addition to being rooted in deep domain differences, knowledge is also embedded in the dialogic encounters through which experts experience knowledge integration (Collins, Evans, & Gorman, 2007; Hibbert, Siedlok, & Beech, 2016; Tsoukas, 2009). The dialogic perspective argues that interactions between experts give rise to the practices through which they work together and the way that knowledge develops (cf. Pyrko, Dörfler, & Eden, 2017). That suggests that when and whether traversing or transcending practices emerge may depend on the dialogic encounters between experts when they attempt to work together to solve a problem. Yet, relatively little is known about the dynamics through which traversing or transcending practices emerge in response to a particular problem situation, or how engaging in those practices shapes the trajectory of integrating expertise in different ways (Barley, Treem, & Kuhn, 2018; Majchrzak et al., 2012; Siedlok, Hibbert, & Sillince, 2015).

This oversight is important because, in their seminal work, Collins et al. (2007) proposed that actors are likely to use different practices as they engage different types of problems over the course of a project. For instance, research has shown that orchestrators sometimes use top-down practices to bridge differences between stakeholders in an innovation network, but other times rely on building more emergent, consensus-based collaborations to connect stakeholders (Reypens, Lievens, & Blazevic, 2021; Siedlok et al., 2015). Prior work also hints at such differences by showing that the context of integrating expertise matters; the traversing approach to overcoming knowledge gaps may be more likely to develop on structured tasks (Bechky, 2003; Carlile, 2004), whereas the transcending approach may be more likely to emerge during novel or fast-paced situations (Faraj & Xiao, 2006; Majchrzak et al., 2012). Thus, traversing and transcending may not be mutually exclusive within a project as experts navigate a continuous stream of emergent problems.

The importance of experts’ dialogues became apparent to us during our study of a large-scale cross-disciplinary engineering project. We observed that initial dialogues around problems substantially shaped the development of knowledge and relationships between engineers. To explore how interactions between experts develop and shape the trajectories of knowledge integration, we focused on the micro-level episodes (e.g. Jarzabkowski & Lê, 2017; Metiu & Rothbard, 2013) that experts engage in as they work together. Specifically, we present a qualitative inductive analysis of 122 problem episodes faced by teams of engineers as they designed and built the safety system for a nuclear power plant. Engineers on the project required different training and certification, and worked in teams with different priorities, deadlines, and resources, so problems occurred frequently. Yet, due to the extreme need for safety in that context, overcoming those problems was essential. This makes it an ideal site to address the question of how teams navigate alternative approaches to integrating expertise. A critical insight of our work is that the way experts viewed a new problem framed their initial dialogic encounters, which then set in motion a trajectory for integrating expertise around traversing or transcending practices. Our study further implies that experts engage in both traversing and transcending approaches to integrating expertise in the course of navigating complex project work because these practices are deeply embedded in experts’ interactions around problems, in addition to their knowledge domains.

Managing Knowledge Differences

We ground our emergent findings in prior literature by reviewing past work on the practices associated with integrating expertise. Integrating expertise is a process of transforming distributed knowledge into collective understanding through interaction (Faraj & Sproull, 2000; Okhuysen & Eisenhardt, 2002). That requires cross-functional experts to draw on and contribute their unique knowledge to a collective problem, and to overcome differences with other experts whose knowledge is deeply rooted in the norms, language, and beliefs of a different domain (Dougherty, 1992). This is challenging because, while groups tend to be effective at breaking tasks down into subparts and completing those components, they are less effective at considering how their work relates to others and coordinating (Heath & Staudenmayer, 2000). Thus, experts may not see their knowledge as relevant to other collaborators. Moreover, experts often have different interpretations of the problem and different beliefs about how to resolve it (Carlile, 2002, 2004; Cronin & Weingart, 2007; Hibbert, Huxham, Sydow, & Lerch, 2010). That can create conflict and reduce communication (Williams & O’Reilly, 1998), amplifying the challenge of bringing knowledge together.

Traversing and transcending approaches to managing knowledge differences

Prior literature reveals two approaches for managing differences (Majchrzak et al., 2012). Traversing knowledge boundaries involves bridging differences. A core practice of traversing is building common ground by identifying, clarifying, and ultimately resolving differences in underlying assumptions, values, and beliefs, so that experts share a background understanding (Bechky, 2003; Faraj & Xiao, 2006; Okhuysen & Bechky, 2009). Traversing knowledge boundaries facilitates coordination between experts (Okhuysen & Bechky, 2009) by helping them to contribute their uniquely held information to collective work and building routines for working together (Bechky, 2003; Laughlin, 1988). For instance, studying work among engineers, assemblers, and technicians, Bechky (2003) found that misunderstandings often occurred due to their unique problem interpretations. To overcome this, engineers used tangible or physical representations of the problem like boundary objects (Carlile, 2004) to articulate their own understanding and shared routines and protocols to build common ground (Faraj & Xiao, 2006; Kellogg, Orlikowski, & Yates, 2006).

At the same time, however, the traversing approach can be difficult and time-consuming. It directs experts’ attention towards domain differences in interests and priorities, but at the same time asks experts to minimize their differences and puts on them the heavy cognitive load of learning and understanding one another’s knowledge (Berends et al., 2011). It also creates path dependence in collective knowledge that may make it challenging to develop solutions when new problems arise that require the group to adapt or generate a new response (Carlile, 2004).

In response to those challenges, another stream of research proposes integrating expertise by transcending knowledge boundaries (Majchrzak et al., 2012). That work highlights how, in some cases, groups of experts may not need to negotiate their differences prior to integrating expertise (Berends et al., 2011). Rather, they can transcend their differences by developing a framework that connects yet maintains divergent understandings, without directly addressing differences (Harvey & Mueller, 2021; Majchrzak et al., 2012). A core practice of the transcending approach is scaffolding, which involves constructing loosely shared structures through dialectic discourse that provides a flexible, but not comprehensive, framework for generating new solutions (Biscaro & Comacchio, 2018; Majchrzak et al., 2012; Tsoukas, 2009). For example, Kamoche and Cunha (2001) suggest that minimal structure allows for gradual improvisation, providing room for flexibility. Similarly, dialectic models of team performance and creativity (Harvey, 2014) argue that maintaining and preserving differences is necessary to generate inconsistencies and fissures between different group members’ perspectives, and move the group process forward. Using familiar objects also allows experts to work together while maintaining their own distinctive interpretations of the use of the object (Star & Griesemer, 1989). At the same time, the transcending approach may only provide partial relief to problems overcoming knowledge boundaries when experts continue to work together over time, as their underlying differences remain and may resurface. In particular, the persistence of differences may make it difficult to coordinate and execute tasks quickly and efficiently when time and resource constraints arise (Okhuysen & Bechky, 2009).

Whereas a substantial body of work about the different approaches has developed, it is less clear how and why one approach emerges and how both approaches may coexist in the course of ongoing work (Barley et al., 2018). This is important because prior research shows that experts are likely to adopt both approaches to leverage the benefits and tradeoffs of each as they encounter different types of problems (Collins et al., 2007). For example, studying a hospital trauma centre, Faraj and Xiao (2006) found that doctors and nurses rely on standard protocols to coordinate their expertise in routine contexts but adapt with a more flexible approach to integrating expertise when a patient’s life is hanging by a thread. Jarzabkowski, Lê, and Van de Ven (2013) showed that organizational members constantly update their understanding of embedded tensions when organizations underwent restructuring. In sum, traversing boundaries may sometimes be more appropriate, while at others, transcending is preferable. Traversing may help experts coordinate but they may struggle to adapt; transcending may help deal with novelty, but make coordination difficult.

A dialogic perspective on managing knowledge differences

Traversing and transcending approaches grew out of the need to overcome deep-rooted domain differences. From that perspective, differences are relatively stable and experts are likely to primarily exhibit an orientation to one approach or the other over the course of a project. Beyond deep-rooted differences, the dialogic perspective recognizes that knowledge is also embedded in practitioners’ experience of the situation in which it is created. Considering the specific situation in which knowledge emerges is necessary to explore the question of how experts use both sets of practices to navigate a continuous flow of emergent problems. That is particularly true in contexts where experts may already possess an overarching understanding, such as a strong organizational culture (e.g. Chatman, Polzer, Barsade, & Neale, 1998). In the context of a nuclear power plant that we studied, for example, the high priority given to safety acted as a high-level heuristic that compelled experts to engage in problem-solving efforts as soon as issues arose.

From the dialogic perspective, as experts negotiate their different interests and perspectives on emergent problems, they have dialogic encounters (Hibbert et al., 2016; Kellogg et al., 2006; MacIntosh, Beech, Antonacopoulou, & Sims, 2012) that shape knowledge. As Hargadon and Bechky (2006, p. 491) describe, encounters consist of ‘moments when participants in social interactions make new sense of what they already know’. Tsoukas (2009) shows how meaning is created during dialogue only when someone responds to information provided by another. Thus, interactions between experts are more than a setting for exchanging knowledge; they are where experts’ knowledge is brought together to create new bridges or new integrating frameworks.

The dialogic perspective reveals how knowledge and relationships change and develop as experts overcome knowledge differences (Barley et al., 2018). First, it suggests that interactions shape what knowledge is built and how it subsequently evolves because, as experts interact, they create new understandings of their work that can shape what is and is not known. For example, Bowman and Wittenbaum (2012) and Kelly and Karau (2016) find that team discussions tend to disproportionally focus on some aspects of a task, so that during interactions, some information becomes more salient while other information may be lost. Tsoukas (2009) further shows that new meanings are created when someone responds to an initial statement or question. Similarly, Hibbert et al. (2016) showed how the interpretive frame brings people to collaborations and shapes their learning from the interaction.

Second, the dialogic perspective suggests that interactions shape how relationships evolve. Newell, Tansley, and Huang (2004) found that a clear division of labour de-emphasized the need for close collaboration, making it difficult to see shared purpose. Interactions can thus shape how experts view the relevance of their contributions to others, changing collaborative dynamics. Participating in an interaction signals experts’ level of engagement, with greater frequency leading to more engagement (Metiu & Rothbard, 2013; Siedlok et al., 2015). The process of managing differences in response to emergent problems is also likely to incur emotional costs that affect relationships. Task-related disagreements are often misattributed in teams, creating conflict, and people are likely to fear that they will be rejected by the group as a result of their mistakes (Edmondson, 1999). Those not invited to a meeting could feel left out (Majchrzak, Malhotra, Stamps, & Lipnack, 2004), fear blame (Faraj & Xiao, 2006), and experience harm to their reputation.

From a dialogic perspective, the interactions of experts as they respond to problems may shape how knowledge boundaries are managed; and because those interactions influence both what knowledge develops and the relationships between experts, using one practice or the other may also shape the trajectory for further expertise integration. In this paper, we therefore use a problem-based approach to understand how traversing and transcending emerge from the interactions between experts and how each approach shapes ongoing attempts to integrate expertise. We examine 122 problem episodes in which experts had to integrate expertise to solve a focal problem. We followed the episodes from the point at which they arose, through the practices that developed, until a resolution was reached. This allowed us to track the process of integrating expertise, and to uncover the practices through which expertise was integrated in response to specific problems.

Research Setting and Method

We explored our research question by studying one project (which we call NCP) at a North American office of an international engineering company (EngCo ¹ ) that specializes in designing and building safety systems in high-hazard industries. NCP’s task was to design and build the safety control system for a nuclear power plant. During our study, NCP was approximately one year into what EngCo described as the implementation stage of the project, which involved transforming client specifications into control system software design and corresponding hardware components. It followed a three-year design stage, in which a small team worked with the client to develop their requirements, identify the land for the plant, and secure the necessary licences, etc. The combination of complexity, novelty, and the need for experts to coordinate that problems emerged daily, so that many instances of the phenomenon of interest to our study surfaced during our work at the field site. That makes it appropriate for exploring our research questions (Glaser & Strauss, 1967).

During the research period, NCP included about 200 personnel organized into three work packages (WP1, WP2, WP3), further structured into 11 functional groups. The groups represented different knowledge domains. Each WP included software I, II, III and hardware groups, and three support groups (finance, human resources, and quality assurance). The average group size was 12 members, and engineers were generally familiar with each other as they had worked together on NCP for one year and shared proximity, either in the same open-plan offices or within walking distance (approximately 30 metres away). Engineers in each functional group specialized in their domain, with bachelor’s or master’s degrees and at least five years of work experience. Even the three software teams were not interchangeable; they used different applications to implement designs, requiring different technical backgrounds and training. Teams may be more interchangeable across work packages (e.g. software I in WP1 and WP2 would have the same technical background and training); however, their actual work at any given time was not the same. Schedule pressure meant that shuffling manpower across WPs may occur, but it was difficult in reality. Although experts were highly specialized, many of the problems that occurred required engineers from different WPs to work together.

Because of the critical nature of designing nuclear controls, engineers were extremely motivated to resolve problems and nearly always came to some conclusion on problems that had been identified. The potential for a mistake to create significant hazard meant that achieving a high-quality design was the number one priority of the project, more important than meeting schedules and budgets. Deliverables would not be sent out to customers before rigorous checks were completed. However, that did not necessarily mean that solutions were successful. For example, some solutions were identified but not implemented and other solutions proved ineffective in the longer term so that problems reappeared. In our data, we classified an episode as ending when a proximal solution had been decided on, but some of those cases were subsequently classified as failures because problems recurred or were incompletely implemented.

Data collection

We worked with EngCo for over one year to get clearance for the project, define project boundaries, gather data, and provide feedback to the organization. The first author collected data primarily during an intensive one-month period onsite, supported with initial meetings and observations, formal and informal interviews, and subsequent follow-up interviews and observations over an additional four months. Three types of data were collected: (1) semi-structured interviews, (2) non-participant observation, and (3) archival material. Multiple sources allowed us to corroborate informants’ perceptions with our observations of the process (Jick, 1979).

Interviews

We conducted 44 semi-structured interviews with engineers and managers at all levels (e.g. WP directors, engineers, administrators). The general manager nominated interviewees to enable a representative sample across levels, disciplines, and tenures (Miles & Huberman, 1984). We also asked the resource manager, who allocated engineers to the project, and initial interviewees to recommend others who could offer further insight.

Interviews focused on an engineer’s role in the project, approach to sharing and using knowledge, the nature of relationships within the project, and the facilitators or difficulties of integrating expertise with others. The interview protocol also evolved systematically as we came to understand the project. For example, we shifted from broad questions about knowledge sharing practices and organizational culture to examining stories that related incidences of integrating expertise across knowledge boundaries. We continued to interview informants until additional interviews failed to reveal new relationships and insights (Strauss & Corbin, 1990). Interviews lasted between 45 and 60 minutes and were audio-recorded and transcribed.

Non-participant observation

Before going onsite at EngCo, the first author participated in 10 NCP conference call meetings to understand the project and its progress. This also enabled project members to become familiar and comfortable with her presence and research role. Calls usually lasted one to two hours and included discussions of project progress, resource forecasting, and foreseeable problems from every component team. While onsite, the first author attended 13 additional formal meetings and was able to shadow individuals and hold informal conversations in cubicles and hallways. Detailed field notes were taken following meetings or informal discussions. Some formal meetings were recorded and transcribed.

Archival material

Project process documents, charts, procedure manuals, and working instructions were also gathered during fieldwork. Meeting agendas and minutes were collected when available. These documents informed us about project context and progress.

Analysis

Phase I

In the first phase, we drew on grounded methods to abstract themes that were theoretically relevant to the question of how practices emerge for integrating expertise (Glaser & Strauss, 1967; Miles & Huberman, 1984). To develop the data structure, we first focused on understanding situations in which experts worked collectively on a problem. We searched the interview transcripts and observer’s notes to identify any instance where engineers described how experts worked together. The data structure therefore integrates insights from both the interview data and the field notes. We then drew on Miles and Huberman’s (1984) principles for categorical analysis to move from codes grounded in the data to more abstract, theoretically relevant categories. We mirrored language used by informants in interviews and interactions to label first-order codes (Glaser & Strauss, 1967; Van Maanen, 1979). The first-order codes offered insights into individuals’ descriptions of expertise integration when individuals face task problems. We then used axial coding to search for common themes among first-order codes (Glaser & Strauss, 1967; Miles & Huberman, 1984) to abstract higher-order categories that were more theoretically meaningful for our research question (Van Maanen, 1979). We searched for links between the first-order codes and grouped them into second-order themes. Using this process, for instance, we found the two practices for transforming knowledge that have been identified in the literature: building common ground and scaffolding. We then grouped similar themes into aggregate dimensions by iterating the emerging structure with theory on integrating expertise (e.g. Bechky, 2003; Carlile, 2004). At this point, we observed that the episodes could be grouped into traversing or transcending approaches to integrating expertise. We revised the theoretically meaningful themes until they fit well with both the data and the literature. This data structure is illustrated in Figure 1.

Figure 1.

Emergent Data Structure and Supporting Evidence from the Data.

Phase II

In the second phase, we examined how the codes we identified in the first phase related to one another. We paid particular attention to relationships between concepts that emerged from our data during the coding (Nag & Gioia, 2012). That analysis suggested that the themes we observed related to one another over time. Specifically, we built on recent studies that identify ‘episodes’ of theoretically relevant phenomena (e.g. Metiu and Rothbard’s 2013 study of ‘work interaction episodes’, Jarzabkowski and Lê’s 2017 study of ‘humor episodes’) to identify 122 problem episodes in which experts worked together to integrate their expertise. Episodes acted as cases for comparing processes over time (Langley, 1999). An episode began when a problem was identified and ended when a problem was resolved according to the engineers involved. An episode thus constituted a string of interrelated tasks or work behaviours that involved interactions between a network of experts.

This approach treated problems that arose during the course of a project as independent from one another. Since problem episodes were compiled from both interview and observational data, we do not have information on their precise ordering. This was appropriate for exploring how dialogues around problems shaped the way that experts navigated knowledge boundaries, but it did not allow us to directly explore with our data whether one problem was caused by or led to another. In the findings section, we explore those rare situations where problems were not resolved to provide some insight into the possible linkages between problem episodes.

Treating each episode as a case study of the process of integrating expertise (Langley, 1999), we then compared instances in which a traversing approach to integrating expertise arose with one another and compared the cases in which a transcending approach arose within one another to identify commonalities. Specifically, within an episode, we applied our coding scheme to identify the order in which processes occurred (for example, what preceded the emergence of traversing or transcending) and other relationships between the codes (for example, did codes co-occur with one another?). We then looked for similarities in the order and relationships we observed to induce a consistent pattern within each of the transcending and traversing approaches. Finally, we compared the processes associated with the emergence of traversing to processes associated with transcending with one another to identify key differences that informed how the sets of practices arose.

Findings

We observed that emergent problems characterized everyday life on NCP. Engineers had to meet delivery deadlines with limited manpower, and they had to coordinate their work because the overlapping nature of different systems that were part of the power plant design meant that one team’s output was another’s input. Some problems, such as following a protocol for abbreviations from a previous document, seemed trivial and insignificant, but the size of the project meant that anomalies quickly escalated. All of our informants emphasized the need for consistency.

We observed 81 episodes in which traversing practices emerged and 31 episodes in which transcending practices emerged. ² Figures 2 and 3 illustrate the problem episode that corresponds to the emergence of traversing versus transcending practices. We organize our findings around the two processes. A key insight was that how experts recognized and constructed their understanding of a problem shaped their response, and therefore how they elaborated the problem, leading to the emergence of either traversing or transcending practices. Specifically, we found that engineers described problems in two different ways, as either problems or gaps, and that the way they perceived those problems led to different dialogues around how to integrate expertise.

Figure 2.

Emergence and process of traversing knowledge boundaries in a single problem episode.

Figure 3.

Emergence and process of transcending knowledge boundaries in a single problem episode.

We describe the process of integrating expertise as involving four integrating practices – recognizing problems, dialogic encounters, boundary management, and ongoing interaction. After recognizing problems, integrating practices were accompanied by developing knowledge and relational dynamics. We elaborate each practice below.

Emergence and process of traversing knowledge boundaries

The emergence of the traversing approach to managing knowledge boundaries that we observed at NCP is illustrated in Figure 2. It began when a problem emerged that engineers recognized and described as a problem that they attributed to a failure to coordinate. That led to searching for task expertise, which triggered task dialoguing to identify underlying causes and impact of the problem and resulted in building common ground around the problem. However, that process highlighted differences between expertise, which ultimately led engineers to adjust their relationships to work more independently.

Recognizing problems

We observed that engineers described problems that initiated traversing knowledge boundaries as being relatively clearly structured and having a solution that could be found. These problems arose because of the complexity of the work. Such problems, for example, missed deadlines, failed handoffs, unexpected design changes, or communicating with the wrong people, presented engineers with a clear issue to resolve, an understanding of who had the relevant expertise to help, and often a roadmap for fixing the problem. For instance, if a deadline was missed, it was clear who was responsible for meeting the deadline and that those people should help to solve the problem. In one instance, a software engineer detected a coding mistake in some hardware. He commented that there was ‘a list of things that . . . has not been verified and not been correct’. The engineer notified relevant colleagues and held meetings to discuss the problem and obtain expert input. In other cases, problems could arise due to interactions between engineers, teams, and clients. A software engineer provides one example:

Something came up in the meeting with our customers . . . they did not like the way we did the task. They told our group to do it in this way, and we said OK . . . It required a lot of hardware changes from the hardware group. I brought it up several times to my manager . . . I submitted a change tracking form [to the] change control board who approves all the changes . . . I told them the customers want all these changes and this is the impact, this is the time to design the software, this will be a big hardware change.

The quotation shows how the client’s request to change the direction of the task required new hardware to be developed, and shaped the engineer’s interactions (e.g. with his manager and the control board). However, the problem had a clear structure, because the client told the team how they would like the task to be completed. When engineers recognized and viewed problems this way, they searched for others who were directly connected to and had expertise in the task, using the project structure as a map for whom to speak to.

Task dialoguing

When engineers recognized a problem and reached out to those directly involved to help resolve it, it was followed by task dialoguing – an intense problem-focused discussion between experts to gather problem details after engineers identify mistakes. During task dialoguing, engineers diagnosed a problem by sharing facts and raising concerns from different perspectives to understand the problem’s scope. As the following example illustrates, task dialoguing often originated when engineers exchanged information about a newly discovered situation. In this example, a problem was discovered during a meeting, which started with a member of the hardware team highlighting the challenge of testing 200 hardware cabinets:

Tony (hardware):

³ There are around 200 items to be tested. It is 1.5 million for all this. One of the managers, Helen, in software II was on a business trip.

Helen (who joined the meeting by phone):

Some of the (200) items are only for assembling. They [the outsourced workers] do not need to freak out when they see the 200 items. Within the timeframe we have, we need to start somewhere. I am not saying we cannot redo a form but they [the outsourced workers] might not have the relevant knowledge and skills to do this. That’s why it is left there.

Roger (project manager):

I know that . . . just I want to make sure we know where the risk is and that we do not need to redo the deliverables.

Tony (hardware):

Some of them don’t even know what the phrases mean . . .

(Observation note from daily project meeting in WP1)

The example shows that during task dialogues, engineers shared everything they knew about the problem: hardware manager Tony raised the concern about hardware equipment, Helen – who was working at the client site at the time – added contextual knowledge about the outsourced workers, and the project manager Roger wanted to know the risk. Task dialoguing, therefore, built problem-specific knowledge, showing the problem from all angles. In another meeting, a hardware engineer was asked to generate a list of topics around which experts would need to coordinate, including task ownership, timeframe, and resourcing.

The information shared by engineers reflected their different expertise and roles in the organization (e.g. hardware versus client management versus project management). Thus, task dialoguing implicitly highlighted their differences. Sometimes those differences were even visually displayed. For instance, a quality manager described how they use colours to circle their responsibility areas on the engineering drawings. While pinpointing the problem, this also highlighted their differences and implied efforts – time and manpower – required to resolve the problem. We saw that engineers were under a lot of pressure to deliver and held back from taking on more work. Our field notes indicate that engineers would go silent and avoid eye contact during meetings when responsibility for implementing solutions was discussed. One engineer commented informally after a meeting that he ‘does not want to be involved’. Thus, task dialoguing could be seen as threatening to an engineer’s daily work, triggering negative feelings about a task. Even the friendly gesture of forwarding information could be seen as negative, as it produced information overload and frustration. As one engineer summarized:

What happens is that people would find a problem and they would write it down on the form, and it was the information, the problem is captured . . . We have charts that are published and released every week. It’s adding up exponentially . . . We just get more and more, and the project gets bigger and bigger.

In sum, through task dialoguing, engineers built problem-specific knowledge and highlighted differences that were in some ways threatening to their work.

Traversing knowledge boundaries

As dialogues continued, engineers began to overcome their differences by developing common ground that situated their knowledge in the problem. Common ground included an understanding of key issues and the impact of the problem, as the following quotation from an engineer demonstrates:

[We] go through the impact analysis, financial analysis . . . how this impacts on other groups. For instance, this might be changing something like hardwiring from software I to IA. But this impacts FDSI group, hardware group, and all that impact drawings, and that’s hours of labour. It is not just you go to the shop and buy wire . . . It is a lot of impact and risk analysis.

This exercise made the impact of the problem and how work would be influenced by it clear to all. In the meeting excerpt described above, the process of building common ground is evident when Roger attempted to interpret Tony’s expertise by asking whether it would be reasonable to deliver work within two weeks, and when Simon paused the meeting to try to understand why the group had lost focus and to align different experts’ goals. Building shared knowledge about the problem helped to resolve that focal problem by identifying places where no one had taken charge of a task.

At the same time, establishing this common understanding of the problem invited discussions around discipline-rooted differences. For instance, an engineer commented on their different ways of working: ‘they might have a strong reason why they run this (procedure) in a particular way, and we have a strong reason why we cannot change it’. These discussions also revealed conflicts about responsibilities:

Gregory:

Has [the document] been sent to us?

Grey:

Should [this] be standard for everyone?

Gregory:

Yes. But we should not be in the deliverables.

Grey:

But your comments are the gate so you also need to be in the schedule.

Gregory:

No, we are not [the gate]. All we want to see is everything before it acts. We need to review and comment on this document, but we are not holding things up, preventing you sending documents to the customers.

Gregory viewed reviewing and signing off on the design as the responsibility of the quality team and therefore anticipated a dependence between the teams, whereas the quality manager Grey did not expect to be included in the process and viewed this as outside of his responsibility.

These discussions could be intense and emotional. A software engineer described his frustration over an interaction with a hardware engineer when it came to changing the update process:

Recently, the hardware guy had heard about the change and he said ‘What is this all about? This is a big change, we did not know about it, what is going on?’ . . . the hardware guy knows nothing about [the change]. Hardware is trying to finalize drawings . . . I told them several times about it and I do not even know what to say anymore. I just rolled my eyes.

The frustration was visible to others in the meeting, indicated by the engineer’s tone of voice and eye-rolling.

Resolving the problem could also be contentious, as experts’ interests would override their willingness to commit to a new responsibility for resolving a problem. In the meetings, we observed comments that ‘we have an ownership issue’, or ‘we are still bouncing around . . . We have a bit lost our focus. I am not sure why . . . Is it because of lost communication? Or is it lack of resources?’ When engineers negotiated their differences to create common ground, the distinction between engineers remained and deciding who owned a problem was challenging. Engineers were reluctant to be the problem owner, commenting that ‘I have many responsibilities – for this, this cannot be me,’ or ‘we are not responsible for this. We should not be involved.’ Even when conversations were more positive, they emphasized distinctions between experts. In one case, a team manager asked whether there would be any drawings or any deliverables identified for the project. Another manager replied ‘four’, and the manager replied ‘Can we have at least one cabinet? Is it possible to do that? I am not pushing you.’ Thus, building common ground maintained and sometimes intensified professional distinctions in terms of knowledge, resource limitations, or professional domains.

Working independently

Ultimately, emergent problems had to be resolved due to the high-hazard nature of building a safety system for the nuclear power plant. To resolve disagreements about responsibility, managers often stepped in to assign ownership, either by writing explicit policies and procedures that one or two experts were assigned to complete or, in some cases, creating an entirely new role with responsibility only for that issue. This meant that collaboration was minimized; individual engineers resolved and managed the problem. A general manager, commenting on the incident of incomplete cabinet design input from a software team, said he had ‘. . .never seen them separate like this. I’d expected the hardware and software teams are working much closer together’. He attributed the separation to teams’ continuous focus on their subtasks:

We found that the cabling, wiring around some of the hardware . . . that hardware group thought they are going to make this point, and software thought they are doing to this point. There is a piece in the middle there with no one doing it . . . I don’t know how this happened . . . my only conclusion I can come to is the individual who is sitting down to do the job the first time didn’t realize how important [it is] to establish upfront very clear interface . . . The separation is clear but the interface wasn’t clear.

The delegated owner of the problem then became responsible for collecting information from other engineers during meetings or through documentation. Although they helped pass information along, other experts disengaged from resolving the problem. Delegation further reinforced limited engagement from others. One engineer commented he was ‘. . .trying to selectively not get involved working with others because when you are doing a project, you cannot really deliver resources to one another’. Another engineer summarized: ‘. . .that’s not my responsibility. So we will go ahead and do our job, and somebody down the line will realize we need to do something’; ‘I just want to focus on my work . . . to me, these people are not relevant to my day-to-day problem solving’. Thus, interactions and relationships between teams became more limited in scope and depth after the process of traversing knowledge boundaries.

Emergence and process of transcending knowledge boundaries

The transcending approach to managing knowledge boundaries on NCP is illustrated in Figure 3. It emerged when engineers took an exploratory approach to problems that they interpreted as opportunities to improve. Those meta-level dialogues focused engineers’ attention beyond their immediate task and toward the broader project structure, leading them to build new frameworks that integrated expertise across different parts of the project. Thus, a particular form of knowledge emerged from that approach. That created new relationships between project members, leading to more interdependent work.

Recognizing gaps

The problems that occurred at the beginning of a process of transcending knowledge boundaries were described by engineers as resulting from gaps in the task structure; that is, rather than viewing them as arising from failures to meet deadlines or coordinate as expected, engineers described these problems as resulting because how to complete or coordinate some part of the task had not been specified. This occurred when engineers realized that the problem structure itself did not help guide engineers towards those with relevant expertise or task roles for solving the problem. Some problems were less technical, but engineers found them difficult to resolve. These problems were often novel; engineers had not encountered that type of problem before. A team may also experience communication difficulties that could have many possible causes and solutions, such as cultural differences, gaps in expertise, or poor team relationships. For instance, in one episode, the team did not initially know how to work together with a team of Chinese customers and learned by discussing how other teams had approached this task.

Not knowing how to approach part of the task led engineers to view those problems as presenting opportunities to improve their work by identifying other projects or tasks with parallels to the problem. This led them to reach out beyond their immediate task to speak to engineers working on other work packages or different projects entirely to share lessons learned, broader principles, and general procedures. Learning from others’ experience allowed them to explore the underlying problem.

Meta-level dialoguing

Following the recognition of a gap, engineers engaged in meta-level dialoguing to explore how they could approach the unfamiliar situation. Meta-level dialoguing was the discussion of broad issues, best practices, and principles that drew engineers’ attention away from their immediate task environment. It began when engineers discovered something they perceived as an opportunity to improve their work and reached out to gather information from others about how to implement a new approach. For instance, in one case an engineer discovered that other projects used a common format for reporting data based on a one-off conversation with someone in the hardware group who was not directly connected to that engineer’s task. This encounter highlighted that two engineers who shared broad similarities could work together in the absence of a direct input-output relationship (i.e. working on the same project).

Meta-level dialoguing was propelled by analogical reasoning that focused engineers on structural comparisons between tasks rather than details of a problem. It was thus a proactive approach to seeking out ideas. For instance, an engineer on software II, WP2, provided another example following a meeting with the client:

When we first started, we didn’t know how to deal with the [foreign customers]. On WP1, there is a software I team. Each project has a software I team. Each WP has a very similar structure . . . They did the same job as I do. They said: ‘that’s how we do it’. This is how we learned – who to talk to, who to send documents to, who to bring here . . . We talk in general and about what we do, but we don’t talk about technical issues.

During the conversation, WP2 software II manager attended to WP1 manager’s experiences and WP1 manager’s suggestion served as a tentative solution. It aided their problem-solving process, suggesting alternatives to try. The nature of those discussions revealed opportunities to experiment with new ways of accomplishing work by benchmarking an engineer’s role with others performing similar functions. The engineer on software II, WP2, quoted above went on to describe how he gets ideas from other projects, but also alters and adapts those ideas: ‘You cannot do everything they do the same . . . you have to change and try something different.’ Discussions therefore may not lead to a concrete solution but a good opportunity to obtain ideas about the problem.

The practice of seeking generative information also created and helped to sustain a positive atmosphere during dialogic encounters. Engineers felt good about working together during those interactions. For example, one engineer commented in an interview that in those discussions ‘. . . You can learn from other people’s perspective. Sometimes it can inspire you.’ Others described meta-level dialogues as ways of getting help and ‘very good support’ for learning, noting that through those interactions they came to ‘see [another engineer] as my mentor and I learn things from him that I do not need to experience myself’. Ultimately, engineers often mirrored the sentiment that meta-level dialogues constituted ‘. . .a very good experience of communication between the teams. . .’. Engineers had these positive reactions when meta-level dialoguing aided their problem-solving for their own work without trying to assign responsibility or blame for a problem.

Transcending knowledge boundaries

Meta-level dialoguing made experts aware of one another’s work beyond their immediate task, which gave them a better understanding of how their work fit into the broader project. That enabled them to see new connections between themselves and other experts, from which new abstract frameworks, or scaffolds, could emerge. As a lead engineer from WP2 described his interaction with a counterpart in WP1:

We communicate methods and procedures, we share them so that we make sure we are doing things in the same way . . . We don’t meet . . . on the actual work. It’s the procedures and the methods that we want to be the same.

Methods and procedures were general, high-level principles for the project without specific task information – they were not about ‘the actual work’, but the ‘the bigger picture’. Through the interactions and exchange of their experiences, engineers came to a better understanding of their work, and each other’s work. This was possible because meta-level dialogues led to the discovery of commonalities in expertise by revealing previously unknown relationships and similarities in their work. One engineer commented that:

Informally we [the lead engineers from all of the work packages] work together. Say there is a document called SyRS, SRS, we meet together to [discuss the document to] make sure that we are doing very, very similar work . . . We meet together all the time to discuss this. We are reviewing the procedures together . . . At EngCo, you work on one project.

This quotation illustrates that software II managers from all three WPs were aware of their association as it emerged from discussing methods and procedures, presenting a new understanding of how their work could be connected. The process of ensuring consistency across procedures brought the teams’ work closer together (i.e. making sure the work was ‘very, very similar’), minimizing distinctions among engineers. Discussions focused less on technical details but more on understanding overlaps in expertise.

In some cases, engineers intentionally transformed the high-level commonalities into written format, shared with other engineers. By hosting a database meeting to develop common standards for completing data reports across seven teams, all teams became experts in the new framework – the data structure – rather than everyone needing to understand the unique data from others. The communal abstract knowledge that was built through that process became further shared through interactions. For example, the manager commented that he communicated frequently with members of other teams and then discussed his learnings with his team: ‘I coach them, so they can understand the logic behind it and why this is designed in this way.’

Situating knowledge in a broader framework created new connections between engineers, blurring relationships so that engineers found ways to interact with others beyond their immediate task. First, boundaries blurred because the set of experts any one engineer interacted and engaged with around their work shifted so that they interacted regularly with some experts not otherwise involved in their focal task. Second, through those interactions, they learned about new ways to engage with the focal task and others involved with it. Previously unconnected experts started to build bridges to their new connections by, for instance, calling them or stopping by their desk regularly, blurring the boundaries between the two similar, but otherwise independent, aspects of the task.

Working collaboratively

Once engineers had formed new frameworks and forged new relationships through scaffolding, they maintained their collaboration through ongoing informal relationships, as the hardware engineer in WP1 commented:

We have a quick phone call, [saying that] we have these issues, and this is how we fix it, and I think you should do it in the same way . . . It’s more discussion-based. I already know the project lead [in WP2] . . . They give me a call . . . and we catch up on a few things. [We talked about] what they learned and what I learned that can help them.

This involved both participating in ongoing problem solving and claiming responsibility for a problem. For example, engineers generated solutions together, wrote up problem reports together, and jointly filled in project documents.

Over time, new frameworks and collaboration became more formal and specific. For instance, a report was collectively generated that contained the ‘global listing and revision checking’, which represented a new way of connecting information from multiple reports that had previously been separated. The revision of the report required regularly meeting up to resolve new differences. Engineers were keen to be involved because they knew that this exercise would save their time in the long term. In another case, software teams in WP1 decided to host a meeting to develop common standards for completing data reports. Engineers were motivated to voluntarily set time aside to meet, continued their conversation together, and identified a set of common and essential elements. Despite teams facing aggressive delivery deadlines, the conversations remained at a high level, rarely about their interests, such as the team delivery schedule and resources. Engineers continued to articulate their commonalities; in some cases, they generated new understanding through the conversation. Engineers worked together on solutions, wrote up a problem report together, and jointly associated their names with responsibility for the problem in the project documentation.

Post hoc analysis of failures to resolve problems within single episode: Insight into the dynamics of traversing and transcending pathways

Our findings show that how experts recognized and interpreted problems shaped how they navigated knowledge boundaries. This raises the possibility that engineers may switch between approaches when they perceive problems differently. Although our data do not allow us to explicitly examine such dynamics, in rare occasions (10 out of 122 episodes) where problems were not resolved within an episode, our post hoc analysis provided insight into how traversing or transcending could go wrong, setting the stage for further problems to occur or a change in strategy.

Our analysis revealed that traversing could result in capturing problems without immediate action, so that capturing the problem became a proxy for the solution. One good example is the correction programme where a manager was appointed to oversee the programme three months before our field trip. Although problems were recognized, discussed among 12 senior managers, reached a common understanding, and developed solutions which were captured in a root-cause report, the problems were not fixed. A newly appointed manager commented: ‘at the time, senior managers saw it as too painful to solve the problem’, and ‘senior managers, for some reason, they believe that there is no time to fix what has gone wrong. Just keep going – which is crazy.’ We observed that the new manager viewed those problems as an opportunity to improve the project, searching for and discussing patterns of the problems with expertise across the project, and creating new joint work with engineers and managers. Thus, the traversing approach led to a repetition of the problem until so many problems accumulated that a traversing approach emerged.

In contrast, a transcending approach could lead to engineers being overloaded with responsibility and unable to always maintain a high level of awareness, so that specific issues fell through the cracks. For example, in one episode, we witnessed that a general catchup between software and hardware teams without the focus of having to resolve specific problems had created opportunities for the two teams to work on new joint work and continue their informal interactions. However, at the same time, the two teams also repeatedly missed inputs from one another. When we discussed this issue with the project director, he noted:

They communicate when they feel it is relevant . . . Relevance is subjective. Because what you think is relevant to me might not be what I feel and vice versa. Because we should communicate everything and let (hardware) determine what is relevant and what is not relevant . . . So what happened over and over again is a person who sits as the lead engineer doesn’t understand the significance of the issue and because of that they [don’t delegate it to the appropriate person].

The situation was alleviated by formalizing daily reviews within WP1 where teams engaged in task-related dialogues, sharing technical details from each team, and looking for problem ownership for the problem, thus shifting the solution to a traversing approach.

These cases suggested that failure in one approach may lead experts to switch practices. If traversing fails, so that the same type of problem accumulates, it may trigger experts to reconstruct the issue more broadly so that they see a gap that the cluster of problems falls through, prompting a search for higher-order solutions across the broader network. If transcending knowledge fails because specific issues are not followed through, it may trigger experts to reconstruct the issue as a mistake, leading them to focus on specific problems and shifting them to a traversing approach.

Discussion and Contribution

Prior research has provided deep insight into the practices of traversing and transcending knowledge, through which groups of experts integrate complex, specialized expertise, viewing either the traversing or transcending pathway as characterizing a particular project or context. Our study built on the dialogic perspective (Collins et al., 2007; Tsoukas, 2009) to explore how knowledge integration emerged on a high-hazard project in a nuclear power plant. Because our study focused on a single project, our findings imply that, even within a single project, experts use both practices to manage their knowledge differences, as they navigate problems that emerge in the course of their work. In addition, our approach revealed that the emergence of traversing or transcending depended on how experts interpreted problems and initiated dialogues around specific problems (cf. Hibbert et al., 2016), so that experts exhibited flexibility in how they overcome knowledge differences. Our work responds to recent calls for research into how and why experts use a particular approach to manage knowledge differences (Barley et al., 2018; Majchrzak et al., 2012). In the following sections, we develop some theoretical insights and contributions from our findings.

Recognizing problems and initial problem dialogues

While past research identified knowledge trajectories to overcome knowledge differences, we know less about the condition through which a particular trajectory emerged (Barley et al., 2018; Majchrzak et al., 2012). Our findings indicate that initially recognizing and constructing an understanding of a problem shaped initial dialogues around the problem, which set trajectories for integrating knowledge onto one path or another. When problems were identified that were framed as mistakes, initial dialogues focused on garnering task details to explore the problem in depth. This leads to the emergence of traversing practices that aim to connect expertise necessary to solve the problem. In a sense, having a clearly identified problem to solve provided engineers with a map of relevant expertise that they could use to identify and build bridges. However, initial dialogues also reflected their functional domain and their resources, such as the lack of time and manpower which were required to resolve the issue. Initial dialogues therefore heightened domain differences, requiring traversing to situate knowledge in the problem to resolve those differences.

When engineers observed less clear problems – where problems related to gaps in the task structure – transcending practices emerged. In those cases, engineers lacked a map of relevant expertise, so they searched for analogies outside of their immediate tasks. When reaching out, dialogues were more open and often involved shared experiences. Reaching out in that way may have helped engineers articulate their past experiences in a different setting and learn about another context, enabling reflexive thinking (Hibbert et al., 2016; Tsoukas, 2009). In this way, dialogues make past experiences visible and thus allow engineers to reevaluate one another’s work and become more aware of how their work could have been related, which in turn, transcend their knowledge differences and focus more on understanding overlaps in expertise.

We suggest that engineers’ initial understanding of a problem may be a function of both the objective nature of the task and engineers’ perception of the task situation. Some complex problems are relatively well-structured and closed-ended; although they are difficult to fully specify at the outset, the problem situation presents a clear goal and criteria for assessing whether the goal has been achieved (Simon, 1973), limiting the potential solution set (Lin & Lien, 2013; Unsworth, 2001). Other problems are less well-structured and open-ended and the final form of the solution is unknown (Ben-Menahem et al., 2016; Shapira, 1995; Siedlok et al., 2015). At the same time, how well an expert understands and can map out the task and solution set depends on his or her knowledge and role in the network of project collaborators, so that experts may perceive a problem in different ways. Objective task characteristics and expert interpretation may also interact. For instance, open-ended problems leave more space for solvers to first find, discover, or construct the problem itself (Unsworth, 2001).

Working collaboratively or independently

We further found that whether experts engaged in traversing or transcending shaped their subsequent interactions and collaborative dynamics. We suggest that how the practices unfolded set experts on a path that shaped their interpersonal dynamics and the development of knowledge in response to problems. When experts engaged in traversing, focusing internally on those relevant to the task allowed them to build common ground, making it easier to pool one another’s expertise (Bechky, 2003; Carlile, 2002); yet, the process of building common ground around technical expertise preserved and reinforced unique interpretations and understanding (Van der Vegt & Van de Vliert, 2005). Interactions, therefore, may reinforce or weaken existing division of labour, shaping how experts work together.

In contrast, because meta-level dialoguing is more open and unconstrained by task structure, it provides an opportunity for experts to direct their energy and efforts towards ideas that they find most interesting. It requires experts to assess their own needs and initiate action. That allows experts to access a positive group dynamic (Harvey, 2014) and connect to a broader set of stakeholders (Hibbert et al., 2016; Siedlok et al., 2015) based on common interests beyond a focal task. Moreover, it may lead to the development of new frameworks that connect more distant parts of a project or organization (Hargadon, 2002). Those new frameworks then guide the search for information and enable experts to identify possibilities for collective work. Thus, the question of ‘who is the owner of the problem’ is not only about resolving knowledge differences, but also a cognitive and relational one.

Knowledge trajectories and organizational enabling conditions

Our findings provide insights into organizational conditions that increase the likelihood of a problem being viewed as a mistake versus an opportunity. For example, when tasks and roles are very clearly structured, a greater opportunity exists for coordination failure; whereas when tasks and roles are loosely structured, a greater opportunity exists for experts to craft their jobs around learning that results from exploring gaps. We also speculate that connections among experts may make experts more aware of the impact of their task on others, making it possible to flex the way to transform knowledge differences. Whereas most experts in our study engaged in both practices, we observed that they were more flexible in their approach when they were closely connected with collaborators. Connections could be based on objective task features (e.g. looking at the engineering drawings, using different platforms) or subjective interpretations of their context (e.g. despite being collocated, engineers commented that their seating plan meant that ‘we are really over by ourselves’).

Our findings further suggest that engaging with one approach for integrating expertise may set the stage for future dialogic encounters by shaping the nature of subsequent problems that are likely to occur. For example, when engineers traverse differences, their relationships and roles become increasingly precise and structured, which may make them perceive emergent problems as tightly structured. This increases the chance of further coordination failures but may be beneficial when tasks have a relatively stable underlying structure. In contrast, transcending differences may lead experts to broader frameworks and more collective work in which roles and expertise are blurred, creating further opportunities for synthesizing knowledge and ever-expanding experts’ roles. That circle may be more beneficial for novel contexts, where work evolves in less predictable ways, but make coordination more difficult.

Our work suggests that a spiral may develop in which one approach to integrating knowledge sets the stage for further problems to unfold, until a switch in approach is triggered. By exploring situations where a problem was not resolved within an episode, we theorized that if an approach failed, it may lead to repetition of the problem and its solution until problems accumulate and trigger a switch to an alternative approach. Our observations echo Barley et al.’s (2018) notion of integration-specialization tension in managing expertise knowledge and Faraj and Xiao’s (2006) finding on dialogic practices as a result of failing to resolve emergencies through habitual practices. An additional possibility is that different approaches are more or less beneficial under different organizational conditions. When tasks are predictable and can be highly specified, it may be possible to reduce the chance of coordination failures by repeatedly engaging in traversing knowledge boundaries. However, when work is less predictable, it may benefit more from a transcending approach so that it can adapt by building new frameworks in response to new task demands.

Future research directions

Our study is based on a single organization with some unique characteristics, so our theory should be transferred to other contexts with caution. One unique aspect of our setting is that the task involved both novelty and accuracy. This meant that the task involved a wide variety of problems. We expect that transcending knowledge boundaries may be difficult to observe in situations without a need for or possibility of novelty. Although transcending is possible in novel settings, our findings also reveal that it does not always occur – indeed, over 70% of the episodes in our data were characterized by traversing. Further research may explore the relative scarcity of transcending and how it fails to emerge in response to relatively open-ended or novel problems.

A second distinctive aspect of our setting was a strong emphasis on safety, and therefore a low tolerance for mistakes, producing a strong motivation for experts to integrate expertise. When experts lack the motivation or ability to integrate expertise, we expect that the challenges to that process would be greater, more failures of integration would occur, and the more positive and proactive interactions we observed would be less likely to occur. At the same time, the strong focus on correcting and preventing mistakes may have engendered more negative reactions from engineers in response to problems that were framed as threats when they did occur. In environments where problems were less critical, we may not have observed negative team environments and interactions developing in response to problems. Finally, experts in our study had relatively high levels of familiarity, although their sub-tasks were specialized. That may have facilitated knowledge sharing and integration. Our study therefore provides a model of integrating expertise when the barriers to collaboration are relatively low. Future research may explore the limits of the collaborative environment.

A final limitation of our work is that, because we focused on problem episodes, we treated problems and experts’ responses to them as if they were independent from one another. We did not examine patterns through which the approaches evolved throughout multiple phases in the project (e.g. Reypens et al., 2021; Siedlok et al., 2015), or switched from one to another, or the ultimate outcomes of engaging in a particular approach. Further research may investigate these dynamics, considering, for instance, whether one approach becomes more dominant over time or the precise conditions under which experts switch from one approach to another.

These features allowed us to observe dynamics that may not be present in other contexts, which is ideal for building theory (Glaser & Strauss, 1967) but may limit the settings to which the processes apply. In particular, we suggest that our findings can be most easily transferred to contexts where there is a strong motivation for integrating expertise and culture around sharing knowledge, and those that involve complex work where a variety of problems are likely to emerge day-to-day. Our study reveals how initial dialogues around problems shape the emergence of practices and different practices shape the form for integrating expertise. Our work calls for a shift from understanding practices for integrating expertise to exploring the dialogues through which experts navigate the complex matrix of traversing and transcending in response to problems as they emerge in the course of work.