Abstract
This paper reports on a qualitative study of how 12 work teams and a project-management team spanned their boundaries in a large engineering project. The study identified two types of boundary-spanning activities. Project-level managers carried out receptive activities in which they spanned boundaries vertically, adapted their management practices, and attuned themselves to the teams. Team-level managers’ activities, on the other hand, were reactive: they spanned boundaries vertically and horizontally when they needed to, and made informal connections to peer teams and project-level management. These findings underscore the important role of team boundary-spanning activities in the shape of subsequent inter-team interactions.
Complex endeavors such as large engineering projects are often fulfilled through the use of specialized teams (Kouchaki et al., 2012; Shuffler et al., 2015). Yet, despite such teams’ expertise, research suggests that when projects are large, they are likely to have conflicting priorities and interests, with negative effects on project-level outcomes (Shuffler et al., 2015; Zaccaro et al., 2020). Understanding how a network of teams carries out boundary-spanning activities to attain project-level goals is therefore critically important.
Past studies of this topic have typically focused on how teams’ respective efforts are coordinated, in terms of either communication structures (Davison et al., 2012; Shuffler et al., 2015) or specific modes of communication (Luciano et al., 2018; O’Leary et al., 2014). As teams interact, they may change cognitively: For example, through developing shared a cognitive maps (Peltokorpi, 2012), coming to accept multiple interpretations of the project context (Beck & Keyton, 2009; Köhler et al., 2012), or influencing their perception of their work effectiveness (Mroz et al., 2018). Collectively, such changes direct and manage teams’ efforts and inter-team linkages, and thus can be seen as boundary-spanning activities (Harvey et al., 2014; Marrone, 2010).
However, the applicability of existing boundary-spanning findings to large-project scenarios has been questioned in recent reviews (Luciano et al., 2018; Marrone, 2010; Shuffler et al., 2015; Zaccaro et al., 2020). In a small project, it is easy to communicate and meet frequently, and cross-team adjustment is manageable. As the size of the project increases, the sheer number of potential dyadic links among teams in a large project is daunting to those who might otherwise opt to coordinate in spontaneous mutual adjustment way. In practice, moreover, the more teams there are, the less likely any one of them is to be able to spare time and resources for interaction with other teams (Gilson et al., 2015; Marrone, 2010). This clearly implies that the size of the project matters to the effectiveness of boundary spanning in aligning different teams’ priorities. However, research has yet to illuminate this dynamic, despite calls to do so by Marrone (2010), Shuffler et al. (2015), and Zaccaro et al. (2020).
To fill this gap in the literature, the present study explored an engineering project, Refinery (a pseudonym), that resulted from a contract to design a safety system for a petrochemical complex. Refinery directly involved 177 people, divided into 12 work teams, and a project-management team, known as the “
Literature Review
Team Boundary Spanning
Team boundary spanning refers to the ways teams coordinate their efforts and seek information to meet performance goals (Harvey et al., 2014; Marrone, 2010). It can be an internal or external team process. The internal form consists of interactions among the members of one team, whereas external team boundary spanning comprises inter-team interactions that occur externally to the team itself. In line with the present study’s research purpose, however, the phrase ‘
Marrone (2010) reported that team leaders often acted as boundary spanners on behalf of their teams. In a setting constituted by a network of teams, a key task for boundary spanners is to identify how all teams can accomplish their own tasks while also working together to achieve higher-level project goals (DeChurch et al., 2011; Marrone, 2010). As Davison et al. (2012) noted, “boundary-spanners are often stuck in the middle and unable to be well coordinated with all the parties that might demand accommodation” (p. 14). It is not unusual for teams to be unaware of the impact of their own activities on the project. Because teams’ attention is finite, fulfilling their local demands inevitably shifts some of their efforts away from the wider project (Majchrzak et al., 2004).
Broadly speaking, teams have two ways of enhancing their overall performance while managing a variety of requirements. The first consists of using a centralized communication structure to span their boundaries vertically across hierarchical levels. This typically involves seeking, obtaining and disseminating task-related information, as well as reporting to project-level managers. Vertical boundary spanning is often driven by a high-level management team’s need to disseminate bulk information downward through reporting lines (Davison et al., 2012; Firth et al., 2015). When conducted with the approval of senior managers, it also helps teams to access more resources and establish their respective roles in the collective project more clearly (Harvey et al., 2014).
The second consists of spontaneous adjustments between teams (i.e., a decentralized communication structure in which peer teams span their boundaries horizontally). It includes searching for work-related expertise and information, and communicating about delivery plans with functionally related teams (Ancona & Caldwell, 1992; Marrone, 2010). For instance, based on a study of 210 multi-team systems, each composed of three 6-person teams, Lanaj et al. (2013) and Firth et al. (2015) found that planning across teams promoted proactive behavior and led to better performance at the system level. Horizontal boundary spanning can also stimulate new connections with distant partners (Harvey et al., 2014) and also potentially improve the success rates of scouting for additional resources, support, and information (Faraj & Yan, 2009).
However, increasing the number of teams involved in a project complicates the impact of both these types of boundary spanning on teams’ ability to meet both proximal and system-level requirements (Marrone, 2010; Shuffler et al., 2015; Zaccaro et al., 2020). Because adding more teams to a project increases the overall volume of project communication exponentially, it requires dramatic increases in teams’ expenditure of resources–notably including time and attention–if they are to achieve the project-level goal. If such dramatic increases cannot be made, a team is likely to stretch itself too thinly to meet both team- and project-level demands, a situation that may have negative effects on the project as a whole (Shuffler et al., 2015). Yet, while prior research has recognized the complexity that an increased number of teams in a project may bring, the question of
Certainly, there is no consensus on which type of boundary spanning is better at aligning teams’ diverse priorities with one another, and with those of the project, as the number of teams proliferates above a certain level. Some studies have found that horizontal boundary spanning continues to help spontaneous adjustments among teams, irrespective of their numbers (e.g., Lanaj et al., 2013), while others have concluded that vertical boundary spanning is more important in large projects than small ones (e.g., Davison et al., 2012). This discrepancy is probably explicable by the very small number of empirical studies on this topic with a network of teams that have been conducted: a gap that the present work is intended, in part, to address.
Linking Teams Through Team Boundary Spanning
Prior scholarship on boundary spanning in multi-team settings has primarily focused on ways of connecting teams’ knowledge and information to accomplish project goals (i.e., promoting resource flows among teams (Kouchaki et al., 2012)). To do this effectively, teams can establish communication structures and tools to store and retrieve bulk information. For example, tracking devices and virtual texting tools have been found helpful in facilitating information exchange among teams (Curtis et al., 2017). When teams develop a transactive memory system, it also assists them to retrieve knowledge quickly (Peltokorpi, 2012). Alternatively, when teams establish a shared way of representing and understanding a task prior to performing it, they are likely to share the same expectations about it, and consequently, coordinate their actions more effectively. For instance, Firth et al. (2015) used frame-of-reference training to minimize the representation gap when teams faced a multi-team task, and found that this improved cross-team coordination and, subsequently, performance.
However, the act of boundary spanning is complex, and can be more than just a means of gathering resources. Although its other aspects have seldom been examined in settings that feature networks of teams, a small body of prior team research hints that how teams interact can influence how they span their boundaries subsequently. For example, an emergent affective state may influence the way teams to coordinate their inputs. Metiu and Rothbard (2013), for instance, found that being available for frequent interaction–even informally, and/or regarding their emotions–signaled teams’ willingness to accommodate others’ requests. This process is not always beneficial, however. Those who are not involved in it can feel left out, and this can degrade their operational effectiveness (Majchrzak et al., 2004). Cramton (2001) also highlighted the need for communication to include all the teams in a project. Specifically, she reported that when teams failed to share information inclusively, even by mistake, team effectiveness was lower and conflicts were more intense. And similarly, Wilson et al. (2008) proposed that whether teams felt connected depended on their understanding of their interrelationships, which could be changed via interaction.
Likewise, as teams interact, they may gradually adopt new views of their task, and of how their respective efforts should be aligned. For example, Harvey et al. (2014) found that horizontal boundary spanning in multi-organization collaborations raised teams’ awareness of their own unique needs, but that helping other teams instead boosted awareness of inter-team similarities. The latter phenomenon encouraged senior managers to change their organizational practices and structures such that teams could better align their work. Based on a study of cross-disciplinary collaboration, Harvey and Kou (2013) found that teams became better at integrating their experiences and knowledge for a project when they focused on smaller sets of ideas and information. This was because providing feedback to one another on a narrow topic shifted their attention toward their similarities and away from the distinctiveness of their perspectives. In other words, interactions can produce a situated consensus about how inputs from each team should be connected. Soliciting up-to-the-minute information on the wider project’s status also appears to be a cause, and not just an effect, of teams’ cognitive states (Weick & Roberts, 1993). Looking at all this prior evidence together, it is reasonable to expect that boundary spanning can cause qualitative changes in how teams work together.
However, relatively little is known about either how teams span boundaries in large projects, or such activity’s impact on how they work together on such projects (Marrone, 2010; Shuffler et al., 2015; Zaccaro et al., 2020). Prior research aimed at examining boundary-spanning activities has typically taken the form of experimental studies in tightly structured controlled environments, among three or four teams totaling between 14 and 18 people (e.g., Davison et al., 2012; de Vries et al., 2016; Firth et al., 2015). The question of precisely how boundary spanning takes place within larger networks of teams has hitherto lacked empirical exploration–despite the increasing prevalence of large groupings of teams in the real world. The present study directly addresses that absence.
Method
Research Context
The setting for this study was an engineering company headquartered in the UK, ElectricCo (a pseudonym). At the time of the study, ElectricCo had around 20,000 employees serving customers in 180 countries. ElectricCo specialized in designing and manufacturing safety-control systems for clients in highly hazardous industries. It provided communication tools to support all projects, including systems for managing all technical requirements and updates, and technologies for video and conference calls. Recognizing the importance of their products to others’ safety, ElectricCo’s engineers tended to be highly motivated and had a strong knowledge-sharing culture, feeling it was safe to speak up and freely challenge one another’s perspectives.
This study took place in one of the multi-team engineer projects in ElectricCo, Refinery (a pseudonym). A total of 12 work teams and the core team working on Refinery project were located across Europe, the Middle East, and Asia. As noted above, each work team created a safety system for 1 of the 12 units of the client’s petrochemical facility. Each work team functioned as a mini-project within Refinery, and the 12 safety systems were expected to function as a single, well-integrated safety system. As an ElectricCo’s engineering manager put it: From a technical perspective, and a project management perspective, we have the overall project—split into 12 slices. When you look at the slices horizontally, everything should be the same. It’s like cutting through a cake. Every aspect of design in each of the vertical slices should be the same as the other slices.
As such, a high level of inter-team coordination was needed to ensure that standard designs, templates, and changes were being adhered to by all the teams, and that consistency of their design output was being maintained. While work teams were unable to meet in person, core team managers used sharepoints and requirement-management tools to capture, trace, and manage changes to project information. In addition, core-team managers updated teams via emails and telephone conferences, at least once per week, but often more frequently if the need arose. During the three-month study period, Refinery was in its engineering phase, with work teams implementing unit design (i.e., analysis of design requirements, installation, configuration, testing, and making necessary changes) before shipment of components to the client’s site for assembly. The biggest challenge for Refinery was the huge effort required to coordinate effectively among its work teams.
Refinery thus represented an ideal setting in which to study how teams coordinate with one another. Its size and complexity required its work teams to follow clients’ requirements and regulatory constraints at the team-task level, while also ensuring that their respective sets of engineering drawings would fit together consistently at the project level. In short, it provided a real-world context in which teams’ needs to engage with other teams arose frequently, creating many opportunities for cross-team interactions.
Data Sources and Data Collection
Over 3 months, I conducted a field study using non-participant observation and interviews at Refinery. Before interviewing managers who worked on Refinery, I shadowed two of ElectricCo’s engineering projects: one a standard, short-term project, and the other a bigger, long-term one, to familiarize myself with ElectricCo’s engineering process, and observe interactions in meetings among software, hardware, and testing teams, and managers. Following Glaser and Strauss’s (1967) recommendations regarding theoretical sampling, interviewees were selected because of their boundary-spanning role. This selection process began with Refinery’s project director nominating managers whom he felt to be a representative sample in terms of their disciplines and tenure. Then, to further ensure that the sample included the most representative personnel, the initial interview list was checked by Refinery’s resource managers, who were responsible for allocating engineers to projects. Lastly, the interviewees themselves were asked to recommend others who could offer further insights relevant to this study. In all, 34 semi-structured interviews lasting 60 to 90 minutes were conducted. The interviewees included the project director and managers in the core team, project managers, and lead engineers, with each person having an average of 20 years’ experience at ElectricCo. All interviews were face-to-face, recorded, and transcribed.
As well as general questions (e.g., about the participants’ roles and responsibilities within Refinery) the interviews included more specific ones centered around how teams share their knowledge (see Appendix). To enhance my understanding of the project’s context and progress, internal ElectricCo documents were also gathered during fieldwork, and included project process and procedure documents, organizational charts, engineering manuals, and work instructions, along with relevant public documents such as company web pages and reports on Refinery. Lastly, follow up e-mail conversations with a core team manager and company managers continued for five months after the researcher left the site. These multiple data sources allowed for triangulation, which can help prevent informant bias (Jick, 1979).
Analytical Strategy
The principal goal of data analysis was to understand how Refinery’s 13 teams coordinated and shared information. Following the lead of other researchers who have studied group interactions (Harvey et al., 2014; Harvey & Kou, 2013), this study adopted grounded theory methodology. Coding of the data commenced with identification of Refinery’s key boundary-spanning activities, including building awareness of information needs; accessing tasks; monitoring tasks; information-seeking; and providing information. The language used by informants in interviews and interactions formed the basis of the first-order code labels (Glaser & Strauss, 1967; Van Maanen, 1979). These first-order concepts offered insights into individuals’ information-sharing activities. Then, axial coding was used to search for common themes among the first-order codes (Glaser & Strauss, 1967; Miles & Huberman, 1984). This allowed for the emergence of abstract higher-order categories that were more theoretically meaningful to the research purpose (Van Maanen, 1979). At this stage, links between and among the first-order concepts were identified and grouped into second-order themes. Similar second-order themes were then joined into aggregate dimensions. If the data did not fit well with a theme, it was abandoned or revised until the final data structure was stable.
The data structure and the percentage of coding for each theme are presented in Figure 1, below. To confirm the accuracy of these basic findings, the research participants’ narratives were re-checked with them. Two graduate students who had practical experience in large projects, and research experience in organizational knowledge, gave feedback on the coding scheme. They coded a randomly selected set of 60 statements from the interview transcripts were coded according to the aggregate dimensions (Cohen’s kappa = 0.85).
Data structure.
Findings
The key question that guided this study was: How do teams span their boundaries in a large multi-team project? Data analysis showed that managers from the core team and work teams not only spanned their boundaries in different directions, but the nature of their boundary-spanning activities also differed. The following sections explicate the categories of boundary-spanning activity that emerged, and then how each category’s component activities influenced both core team and work team managers’ actions in the Refinery project.
Core Team Managers: Receptive Boundary Spanning
Understandably, given their lack of any peer team(s), the core team’s managers spanned their boundaries vertically: receiving and disseminating from the work teams, soliciting information from them, adapting their responsibilities by creating solutions for work teams, and attuning themselves to work team information. The core team’s activities reflected the general expectation that, in a large project, such teams will be more directive and centralized (Davison et al., 2012). However, doing so also helps them to gain and maintain a broad view on their role, and consequently, clearer perspectives on how teams can be connected. Core team managers’ boundary spanning is therefore termed receptive boundary spanning. Each such activity that Refinery’s core-team managers carried out is described below.
Soliciting information from work teams
To facilitate their solicitation of information from the work teams, core-team managers created the project’s organizational structure, reporting processes, and documentation system. These centralized setups helped them to send out project information to work teams. One characterized their interactions as occurring “12 hours a day, 6 days a week.” At times, the core team’s senior manager held meetings to ensure that work teams fully understood particular messages: We explain. . . what is the problem and what are the solutions. To [better] explain, sometimes we don’t have engineering meetings. I have Internet meetings with DCS [Differential Scanning Calorimeter] to explain specific points—for example, a variation of 36-25-A digital channel—and ask them to explain 36-25-A to us. Everyone is expected to be involved and I don’t want to explain each time one by one. So the meeting involved all the leads. And leads will try to explain to us how to build the 36-25-A, to be sure this information is given to everyone. Normally, we did an oral presentation, and we put the slides to SharePoint and we send the pass to everyone, and then they bring the permission. This is the way to communicate. (Overall project manager in the core team)
Setting up channels for soliciting information meant that the core team was also obtaining work teams’ local information and updates, and this provided opportunities for core-team managers to reflect on the information obtained from work teams. As of those managers commented: Each work package will follow its own requirement and its own way of working. What happens is that we get to a point that hardware is fairly consistent. The software, in particular, display for example, varied between work packages. Here we have a lot of conflicts. Our team did not do anything wrong because their customers told them to do something particular. But it does not fit into the overall design. . . . The only mistake the team made—if any—is not to revisit the standard design. This is very difficult when you have very aggressive clients. (Engineer manager in the core team)
Another core-team manager also noted what had gone wrong: Now I see the work that engineers done. . . I am not sure whether things are consistent. . . This one is missing, this one is missing, and this one is not following the good philosophy. . . Sometimes, they didn’t do that because they didn’t have time. (Saftey system manager in the core team)
In short, soliciting the information from work teams enabled core-team managers to detect differences in their implementation strategies, and thus to notice when there were variations in software design and failures to follow the project’s philosophy.
Adapting
To see how the project could deliver an integrated safety system, core-team managers looked at the various issues work teams were confronting. Pointing to a particular work team on the project’s organizational chart on the wall, one core-team manager noted: We have problems in this package, in this slice. We need to understand their problem to help them. We are now drilling the details. The problem is technical, resourcing, schedule, finance, everything. The thing is that’s what it is required. (Overall project manager in the core team)
Through such evaluation, it became clear to the core team that work teams’ complex issues went far beyond keeping design implementation consistent. With 12 work teams, pressure to deliver, and the need to maintain project-level design integrity, core-team managers felt they needed to approach work team issues differently: that is, to move beyond their original responsibilities, creating designs and policing implementations of those designs. Instead, they became more intrusive in work teams, such as by performing technical reviews, producing templates for technical reporting, and scrutinizing finances, resources, and delivery schedules. They also started to develop solutions that could be more easily applied to 12 teams: technical templates. These templates captured engineering-process workflow and other information, including task information such as the definitions of technical terms, conditions of the technical environment, implementation procedures, and obligatory technical documentation. Where it provided design guidelines, this innovation fulfilled work teams’ daily needs, while also providing further encouragement to feedback provision by work teams. Individual work team members welcomed templates and viewed them as relevant to their work, rather than as managerial gibberish. For the core team, templates helped maintain design integrity at the project level, while also helping to reduce inconsistencies in software design. In addition, these developments encouraged the flow of information from the work teams to the core team via meetings, conversations, and formal documents.
Interestingly, core-team managers were aware that this process of adaptation was resulting in renewal of the meaning of their role. The engineering manager from the core team described this as follows: The structure, I would say, changed radically. Not in terms of boxes on the pages, but in terms of what boxes are doing. . . . People’s roles have changed because we find gaps, find weaknesses, find misunderstandings. The more experienced people drilling down the detail, which is never the intent of our team. . . . The thing is, that’s what is required. (Engineer manager in the core team)
Attuning to work teams
Core team managers’ adaptation made them notice that work teams’ local information and strengths were needed to complete the project. For instance, work teams using templates sometimes found mistakes in them. Core teams’ revisions of templates relied on diagnosis of the work teams’ issues and review of their enquires and technical reports. This cycle also helped core-team managers to question their existing way of allocating resources: When you are doing the reviews, you find out—we realize that some teams do better than others. . . . So we looked into a process that we asked a special team to do a certain function. . . . We look at not just the progress, but also what are the things that the team is doing well. Because if someone is doing something well in one work package, is this being done well in other work packages? So we start to move around the resources. (Overall project manager in the core team)
This alternative viewpoint on work teams’ daily work created opportunities not only to better understand work teams’ local contexts and issues, but also fostered discussion between work teams and core-team managers: Everyone has some issues. I am talking about project challenges. If you are not able to give me the correct answer, at least we can discuss and then we can have a correct answer. We can get the right person, and chase the right person. But we need the opportunity to do it. (DSC area lead in the core team)
This new way of looking at the core team’s management role also helped them to address work teams’ problems differently. Previously, work teams’ problems were generally assumed by the core team to be outcomes of work teams’ failure to follow the project philosophy, and core-team managers’ usual response had consisted of assigning blame and making threats. However, when the core team interacted more with the work teams and better understood their contexts and challenges across all aspects of the Refinery project, these managers came to view the work teams more sympathetically. The core team’s senior manager described ElectricCo’s engineers as working like a “body shop,” and went on to say: If they continued to do so, all they would be doing is providing bodies. Whereas what we need is that they understand that they are providing a service. That service requires training. . . . [But] they are expected to provide some additional benefits to the project rather than just labor, which they don’t appear to understand. (Safety system lead in the core team)
Another core-team manager suggested that the attention devoted by his team to the work teams also became more thoughtful, and that this translated into decisions that were more meaningful and relevant at the local level: When the solution comes through from individuals in the local team, this is generally implemented. Therefore, he sees his idea being implemented. Quite often, the email will go back and say thank you and copy everyone else involved. There is a reward in that respect, and there is also the reward that he can see things getting improved and it is his idea that did it. (DCS & ECS lead in the core team)
Although unable to interact at the individual level, core-team managers delivered praise by broadcasting individual engineers’ most important contributions. In doing this, the core team was manifesting a conscious decision to disseminate positive feelings and promote inclusion through emails. In becoming more aware and understanding of work teams’ contexts, the core-team managers had learned that a given work team’s engineers would usually not know what their efforts had resulted in, and their counterparts in other non-collocated work teams would not be aware of such results either. The core team’s rectification of this absence strengthened its connections to the work teams. As one core-team manager noted: “Jeff jokingly said the other day that we are like Nokia: connecting people. That really resonated. That is what we are doing.”
Work Team Managers: Reactive Boundary-Spanning Activities
Work team managers carried out interactions both within and across levels. These activities were often reactive: that is, consisted of reporting to the core team or sending requests for help in response to new or unexpected local issues. In these reactive boundary-spanning activities, the linkages between different work teams’ respective task problems were not always immediately observable because the scope and internal schedule of each work team’s task were clearly demarcated from those of other work teams. Nevertheless, this reactive activity provided opportunities to heighten all teams’ engagement by increasing their sense of connection, and refocusing their attention beyond their distinctive work requirements and the initial project setup. The subsections below describe each activity that work team managers carried out.
Reactive soliciting of information from the core team by work teams
Work team managers’ communication with the core team was driven by reporting lines and escalation procedures. Work team managers emailed daily status reports, testing-progress percentages, the number of punches
1
they had opened, and whether they had noted any patterns in those punches. One work team manager described this formalized process: The technical problems will be addressed by the lead engineer and the project manager [PM] will be aware of this. . . . If there is something small, PM won’t act on it. If this is a serious thing, then PM will act on it and escalate the matter in the client organization and saying this is high-ambiguity and we cannot work on this. The escalation is on the client-side and the core team need to be aware because the core team is supporting us and they need to know the direction. (Conversion work team manager)
When work team managers identified a problem, they usually submitted a description of it to the core team: There are always possibilities to find bugs or things that are not conforming to the product. Those kinds of issues are identified. . . . [Having identified one,] we report to the core-team managers first. . . . to see whether this discrepancy is critical to the project. . . . [Then, they] will evaluate the issue and will decide whether to reissue the new templates to all packages. (Amine work team manager)
For the core team, the local information this process produced highlighted incompleteness in templates, and directly prompted template revisions. For work teams, meanwhile, raising local issues yielded a harvest from the core team of updated solutions, specifications, procedures, and directions on how to use data. These interactions were reciprocal, in the sense that they served the two parties’ mutual need for solutions. However, this process was not always a smooth one. Sometimes, for example, work teams had to wait for the core team to redevelop templates or solutions, which caused stress due to the former’s tight schedules: “today they change something, the change will come to me 2 days later. . . . [But it could] impact on what I have done in the past 3 months.” (Interconnecting work team manager)
Reactive soliciting of information from other work teams
As noted above, Refinery’s scale and distributed structure limited work teams’ exposure to other work teams’ work. Day-to-day interactions between the managers of different work teams were minimal, in part because they lacked knowledge of “whether other managers will be interested or not. Everyone has his/her own way of managing the team. Everyone has his/her issues.” Nonetheless, work team managers spanned their boundaries horizontally when seeking help. One of them explained: When I have some problems on my package, I was on fire, I spoke to the package, and I will ask them whether they have a similar problem and whether you fixed it. . . . I used to speak to my buddy [another mid-level manager in a different work team] and see whether they have similar problems. (Conversion work team manager)
By its nature, asking for help attracted attention to the focal problem, establishing a mutual focus. This new focus of attention also prompted different work teams to identify similarities in the issues they were experiencing. If, through this process of communication, it emerged that multiple work teams were talking to the core team about the same problem, the same work team manager quoted immediately above said, he would be more likely to escalate it: “This is not just in my package, this was with other packages.” In other words, exploring problems jointly with other work teams could clarify the severity of an issue before it was escalated.
A further benefit of such activity was that reaching out to one another helped work team managers, who would never normally work on the same task, to establish or maintain friendships. Implicitly, the fact that these inter-team interactions centered on whether other teams had the same problems suggests that a relatively abstract level of knowledge was involved. This, in turn, produced deep and detailed discussions of inter-work team variations in assumptions and practices. Sometimes, boundary spanning between work teams led to the development of new solutions. One work team manager described that process as follows: You will bring your requirements, I will bring my solutions, and somebody else will have an operational perspective, and somebody else will have maintenance perspectives. . . . We basically split the design into distinctive workshops. We had workshops with the control system, we had workshops with ESD [Emergency Shut Down] systems, fire and gas system. What we were doing is that we present our solutions and explain to the customers, and get their feedback, write meeting minutes, producing technical notes that are required. (Distillation and hydrotreating work team manager)
Holding workshops of this kind among work teams helped their managers deal with the requirements in the specification papers, which comprised between 20,000 and 30,000 pages, meaning that no one person would ever be able to read and fully understand all of them. By discussing this material and presenting their solutions, work team managers formed a better understanding of one another’s project-level roles. Templates issued by the core team also helped work teams to consider cross-team similarities in their information, and thus its potential cross-team applicability. Solutions could quickly be shared by sending pictures from one work team to others, and templates created a safe environment in which individuals felt they could speak up.
Emotional interrelating
Work team managers’ reactive solicitation of information influenced how they related to other work teams and to the project. When interacting with other work team managers, their experiences were generally positive, and involved displays of appreciation. Helping to find and being part of solutions usually made them feel happy. For instance, when the core team sent out emails recognizing work teams’ contributions, work teams saw that their input had become solutions, giving them a sense of fulfillment and achievement and increasing their commitment to the Refinery project. Even when such solutions could not be implemented, team members still displayed appreciation, and were therefore welcomed. A core-team manager described how positive feedback could be given even when work teams’ input was not included in a revised template: If this is a good idea, but we cannot implement [it], we will explain why it is so—to a smaller audience. Quite often it is too late and it will cost too much to do it. But this does not mean the way that is currently being done isn’t good, [it] just means—it is a good way and we probably do that in the next project. (Safety system lead in the core team)
These positive feelings were mutual. Work team members commented that the core team played a “very core function” that was not merely managerial “but also technical,” and that this latter function was “very important.” Interestingly, not being able to interact informally was not a barrier to the development of emotional connections. Broadcasting recognition in the way explained above made individuals’ and work teams’ contributions visible. And, on those rare occasions when face-to-face interactions between the members of non-collocated work teams did occur, it was generally a positive experience for them: For every event, good opportunity, good progress in the project in the schedule frame, I arrange a dinner with the team. We go for dinner and have fun. Make people work as a body. That’s a festival. (Aromatics work team manager)
At one of these social events, work team managers sat and interacted with one another and with the core team, danced, and mingled together. As some other work team managers noted, “Teams are willing to work together and to resolve problems,” and “I think the relationship is very good. . . . [even if] very challenging because so many teams are involved and [so many] documents. I think there are a lot of things to be learned from this project.”
Discussion and Conclusion
Discussion
Prior research on boundary spanning has focused on it as a means of pulling inputs from small numbers of teams, often under controlled experimental conditions. By looking closely at real-world boundary spanning in a large multi-team project involving 177 personnel, with a total of 12 work teams and one project-management team, this study has revealed that managers at different levels not only carried out different boundary-spanning activities, but also that such activities changed their understandings of their shared task and of how teams’ input should be joined together. As project-level managers spanned boundaries vertically, they became more understanding of work teams’ problems when they solicited and reviewed information from them, and adapted their approach to managing those teams, becoming more attentive to their local contexts and resources. Mid-level managers, meanwhile, carried out reactive boundary spanning, responding to both problems and new requirements through reporting or asking for help. Together, the above findings demonstrate how team-level boundary spanning behaviors took place within a network of teams.
Theoretical Implications
This study has important implications for research on team boundary spanning. As the number of teams grows, they are increasingly unlikely to be collocated, and therefore more likely to suffer from low overall levels of communication, limited methods of communication (Hinds & Bailey, 2003; Hinds & Mortensen, 2005), and a relative lack of spontaneous interactions (Metiu & Rothbard, 2013). Existing research has generally recommended that such problems remedied by relying on the directionality and strength of boundary spanning across teams, often with an emphasis on quantity of inter-team communication as a positive predictor of performance. Yet, hardly any empirical examination of such dynamics has been conducted within large networks of teams (Shuffler et al., 2015; Zaccaro et al., 2020).
While previous research has tended ask which single type of boundary spanning is better suited to accomplish multi-team projects, the present work has highlighted that multiple types of boundary spanning were crucial in a large project setting. Previous research suggested that project-level managers process information centrally and are decision makers due to their position within the large project (Davison et al., 2012; Firth et al., 2015). This study further pointed out that vertical boundary spanning also helped project-level managers to detect common local problems and evaluate what was happening at the local level. And, as project-level managers came to understand local issues systematically, they changed their view of their role in the project and, subsequently, how their relationship with the engineering teams ought to be. They assigned meanings to their actions: for example, where their original role was “design police,” they revised it to “connecting people.”
For mid-level managers, reactive boundary spanning meant that managers tended to focus on work team level goals: to project-level managers’ guidance and specific incidents. On the other hand, being reactive to project-level guidance helped teams follow the project’s philosophy and documentation. These project-level requirements and philosophies also served as shared contextual knowledge between project management and local management, which facilitated ongoing conversations among teams. This echoes the idea of share context in Cramton’s study (2001) where shared contextual information helped teams to understand their differences. Rather than leaving them focused on their distinctive team-level priorities, this narrowing of focal issues directed teams’ attention to their commonalities at the project level. That is, when they shared stories about similar problems, they learned from peers’ experience. Moreover, seeking help in this way created emotional connections between teams, as they shared their interests, excitement, and mutual appreciation. In light of such new-found awareness, they then reviewed their own respective tasks, a process that often resulted in reinterpretations of their roles and connections to one another.
In addition, the findings suggest that the prior literature has disproportionately valued project-level managers’ efforts to promote teamwork in multiple-team settings. For instance, previous studies have focused on how cross-team interactions can be facilitated through centralized planning (Lanaj et al., 2013), implementing coordination structures, and encouraging inter-team interactions (Davison et al., 2012). Training has also been identified as a key means of improving managers’ capacity to communicate, leading to more effective interactions between teams (Firth et al., 2015). The current study indeed found that Refinery’s project-level manager played a key role in planning and organizing cross-team interactions. However, it also revealed that project-level managers played a more proactive role than their status as authority figures would seem to imply. The data indicated that project-level managers at Refinery redeveloped their own processes and roles, by focusing on updating solutions, developing alternative relationships with the work teams, and reconsidering their use of communication media in vertical boundary spanning. In this way, they crafted feedback loops whereby uniform reporting documents encouraged spontaneous feedback from the work teams to the core team, and that information then fed into revised solutions and further development of the core team’s own processes. Spanning boundaries across levels, therefore, appears to have helped teams engage with one another and change their views of how team-level resources fit into project-level requirements.
This study also highlighted that boundary spanning may result in qualitative changes. These changes prompted by changes in what boundary spanners do—including, but not limited to, their subsequent boundary-spanning activities. As teams interact, they drilled down into the similarities in their respective experiences, including problems they encountered, procedures they used, and standards they were expected to adhere to. In this case, teams became gradually more mindful of the requirements of various levels of the project. This finding also suggests that organizations could develop new, effective strategies for re-directing teams’ efforts in ways that facilitate subsequent information-sharing and that make relevant information more likely to be noticed across team boundaries (Metiu & Rothbard, 2013; Weick & Roberts, 1993).
Prior research on networks of teams has suggested that spontaneous interactions across teams can lead to better performance (Davison et al., 2012; Marks et al., 2005), and that decentralized interaction and planning may boost teams’ willingness to be proactive (Firth et al., 2015). The present study’s findings, however, suggest that this may not apply to multi-team projects above a certain size threshold. Although project performance was not explicitly measured in the current study, project monthly progress report and its interviews with team managers, project directors and corporate managers all indicated that the Refinery project was perceived as a success, due to its being only slightly delayed. In Refinery, planning was very centralized. Even spontaneous cross-team interactions were made possible by common ground, such as templates and project philosophies, emanating from the core team. As such, in the absence of high centralization, it might have been very difficult for teams to share ideas and problems quickly (see also Shuffler et al., 2015).
Practical Implications
The present study’s findings also have important practical implication for managing a large project. First, when considering how to balance teams’ proximal goals against the project goal, the content of communication and how individuals make sense of such communication are just as crucial as communication patterns and media. This study has pointed out that vertical boundary spanning played an important role in balancing conflicting interests. In particular, this was achieved by core team managers engaging in receptive activities through soliciting information from teams, adopting a new view of their existing role, and attuning to the other teams. These actions shaped a new, project-level view of inter-team relations. Horizontal boundary spanning, on the other hand, helped to promote a sense of open communication at the team level. Accordingly, the present study’s second major recommendation is that, in a lengthy multi-team project, the project-level manager’s role is likely to change to incorporate additional responsibilities, while team-level managers’ roles may remain relatively stable over time. Lastly, this study has highlighted the important role of establishing a feedback loop in large projects. Such a loop helps teams not only to solicit information, but also to be both cognitively and affectively engaged. In Refinery, shared documentation played an important twofold role. It helped the project-management team to tap into lower-level teams’ day-to-day work by providing practical, work-related guidance. It also provided a common ground for interaction among teams. In short, a feedback loop can create interaction opportunities that facilitate and sustain teams’ joint striving for solutions and improvements.
Limitations and Future Research Directions
This study was based on fieldwork in a large, long-term, distributed engineering project composed of one project-management team and 12 work teams. This setting, of course, had its own unique aspects. One of these was an especially strong demand for knowledge-sharing, in part because of the negative consequences of not doing so. The number of registered mistakes, re-workings, and delays were visible to everyone involved in the project. And, if inconsistencies remained among the work teams’ respective parts of the focal safety system, the quality of that system could easily have been jeopardized, both in terms of reliability and ease of maintenance. These special project characteristics meant that boundary spanning was especially necessary in bringing to the surface many local issues that might otherwise have remained hidden.
Refinery’s unique setting yielded a clearer understanding of the role of boundary-spanning activities in a large project. In the settings where non-sharing of information would not have such markedly negative impacts, managers could be expected to be less-proactive. For instance, templates were the key type of management intervention in Refinery, but consumed both money and time to develop. Likewise, in a smaller and/or shorter-term project, project-level managers might not need to adapt their roles and responsibilities because spontaneous or informal interactions would suffice. Future research could therefore usefully explore emergence of role adaptation in other settings, such as short-term projects and different project stages, and explore what specific conditions prompt managers to change their boundary-spanning activities. Certainly, in pursuit of a rounded understanding of what interventions may be appropriate to dealing with the size-induced complexities of large projects, more research in this area is warranted.
In managing any multiple-team project, communication structures and patterns are essential factors (Davison et al., 2012; Shuffler et al., 2015). The findings of the current study indicate that boundary-spanning activities are more than linking who-knows-what, and may further develop and sustain positive affective states across teams if the right types of interventions are established. As they are repeated, teams’ interactions become associated with both cognitive and affective adaptation. Due to the difficulties of gaining comprehensive access to a dispersed, high-security setting like Refinery, this study was not able to systematically measure the level of cognitive state in teams, their affective states, or their actual communication. In the future, careful, fine-grained longitudinal work should track communication content, communication modality, and how cognitive and affective adaptation co-evolve as teams interact. In addition, future research could investigate the impact of boundary-spanning activities on the emergent affective state of large-project personnel, and what practices help teams to sustain positive affect.
Footnotes
Appendix
Declaration of Conflicting Interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.
