Objects of Collaboration: Roles and Sequences of Objects in Spanning Knowledge Group Boundaries in Design

In the 1990s Pratt and Whitney developed a new high-thrust jet engine for Boeing 777 airplanes, the PW4098. The engine is complex, with over 600 subsystem interfaces. As cross-functional design teams developed these subsystems, two interfaces were missed, which, by the time they were discovered and addressed, resulted in an estimated increase of at least 6-months in development time and 2–4% (likely >$1 M) in the total program budget [1,2]. When developing complex products and systems, design interfaces and functional dependencies are not always apparent up front, and even when they are, shifting external conditions can create a moving target of design requirements, interfaces, and dependencies. As such, complex system design involves uncovering and addressing a potentially shifting set of unknown unknowns, many of which reside in the boundaries between knowledge groups.

Spanning knowledge boundaries has been described as both a source of and a barrier to innovation [3]. Boundary spanning poses challenges because members of different knowledge groups must bridge their respective status and interests [4], language (jargon and communication rules [5,6]), “thought worlds” (interpretive systems of meaning [7]), schemas (mental representations [8]), scripts (patterned ways of acting [9]), mental models (ways of “playing out” scenarios in one’s head [10]), etc. to effectively broker, resituate, and make use of each other’s ideas. While focusing work within a knowledge group has advantages, working across knowledge groups has been found to improve product performance [11–14], innovation [15,16], product development speed [15], and optimize system-level design decisions, e.g., Refs. [17–19]. However, these boundary-spanning benefits are not always realized due to between-group differences in language, cognitions, thought worlds, etc. which can lead to missed communications, such as the Pratt & Whitney example above, or miscommunications, such as excess or biased design margins or uncertainty in parameter estimates [20–22]. Such miscommunications can result in expensive rework cycles and decreased design quality.

Objects have been found to play a consequential role in structuring the thoughts and actions of designers (e.g., engineering drawings [23], prototypes [24], and design methods [25] that guide designers’ learning and decision-making), particularly when spanning knowledge group and occupational boundaries [26,27]. In the present study, we define “objects of collaboration” as collaboratively developed physical or digital representations of designs (e.g., prototypes, sketches, engineering drawings), representations of design risks, tradeoffs, or problems (e.g., failed parts, failure modes and effects analyses (FMEAs), tradeoff curves, A3s), and representations of design processes or workflows (e.g., value stream maps, obeya andons, kanban boards, sprint backlogs). Design research has contributed many cross-functional design methods (that often take the form of objects, e.g., Refs. [25,28–30]), but currently offers limited theory [31] on how designers engage with such objects, and one another, to span knowledge group boundaries. To address this gap, we conducted a two-year (2019–2021) ethnographic study within a large turbomachinery design company, “Turbo” (pseudonym). Our data include ethnographic observations of 70 cross-functional meetings and 52 interviews across seven functional groups (Advanced Technologies, Aerodynamics, Mechanical Design, Rotordynamics, Structural Analysis, Supply Chain, and Quality) during the ongoing development of Turbo’s complex turbomachinery products. We analyzed these data using an inductive grounded theory approach drawing from theories in design science [23,24,32] and organization studies [3,33–35] and guided by the question: How do cross-functional design teams span their knowledge group boundaries to advance their designs and design processes? As our inductive process progressed, the boundary-spanning roles of objects emerged as prominent themes and led to more specific research questions:

1. What roles do objects play in structuring cross-functional interactions in design practice?

2. What outcomes seem to follow from these object roles and their sequences?

We draw upon research streams in the fields of engineering design and organization studies to examine how designers use objects to help bridge knowledge group boundaries during product development. This section offers an orienting framework for understanding cross-boundary design work, background on three types of knowledge group boundaries, and theory from both engineering design and organization studies on how objects help span such boundaries. We draw from existing syntheses by organization studies scholars [33,34], make connections between these syntheses, and put them in conversation with engineering design scholarship.

Multiple forms of boundary spanning have been identified in engineering [36], and multiple terms refer to people working together across group boundaries in a design process, including “collaboration,” “coordination,” “cooperation,” and “integration” [37]. We refer to these collectively as “cross-boundary design work.” Edmondson and Harvey [38] offer a model of “cross-boundary teaming” that provides an orienting theoretical framework for our study (Fig. 1). While their model was developed to understand cross-boundary work in innovation teams with more temporary and unstable membership, we have found the model to be applicable in our setting. It centers cross-boundary behaviors (e.g., experimenting, discussing errors, seeking feedback), objects used during interactions (e.g., prototypes, drawings, process maps), participants’ individual states (e.g., role clarity, self-efficacy, belonging), and collective states (e.g., psychological safety, shared mental models, transactive memory). These constructs are affected by the languages, interpretations, and interests of each group and contextual factors like the environment, leadership, task, and time. The combination of all these variables influences the outcomes of cross-boundary work. Acknowledging the complex nature of cross-boundary design work, the focus of our study is to better understand the roles that objects play in influencing cross-boundary interactions and, ultimately, cross-boundary outcomes (as highlighted in gray in Fig. 1).

Knowledge boundaries demarcate functional, disciplinary, and other knowledge groups [36]. Such boundaries are spanned when information is transferred, translated, and/or transformed between groups [33]. Previous work in organization studies [3,39,40] has identified three kinds of knowledge boundaries, in order of increasing complexity: syntactic, semantic, and pragmatic.

Syntactic boundary spanning involves establishing a “shared and stable syntax” by which information can be accurately transferred between groups [41]. Syntactic boundaries are foundational in that spanning any knowledge boundary, by definition, minimally involves a transfer of information. For example, in developing a new automobile, engineers from an Engine/Powertrain group and those from a Climate Control group might each use a parameter they call x, related to the length of a vehicle’s grill. These parameter values must be understood using the same syntax in order for their potentially different values to be properly compared.

Semantic boundary spanning involves not just the transfer but also the translation of information. Even when two knowledge groups share a common syntax (e.g., a shared understanding of variables related to a vehicle’s grill), information transferred between them may be interpreted differently unless a shared interpretative scheme is used. Shared interpretive schemes can make visible the novel differences and dependencies between groups’ “thought worlds” [7]. Following the same example as above, imagine that the Engine/Powertrain group advocates for a higher horsepower engine. This information would need to be translated to show its meaning for other groups, otherwise, the Styling group may not see how much the higher horsepower engine affects vehicle hood slope, and the Safety group may not see the implications for vehicle weight, bumper position, etc.

Pragmatic boundaries add a final layer of complexity. These acknowledge that spanning a knowledge boundary is not just about challenges in transferring and translating information but about addressing groups’ different and potentially competing interests and agendas. Spanning a pragmatic boundary involves making one’s knowledge, skills, and designs—hard-won within one’s own knowledge group—vulnerable to being transformed as a result of interactions with other groups [3]. Consider how an Engine/Powertrain group might aim to optimize engine power, whereas the Styling, Climate Control, and Safety groups might aim to achieve a desired look and feel, heat flux, and safety rating, respectively. Implementing a higher horsepower engine could advance the goals of the Engine/Powertrain group but not necessarily the goals of other groups. Table 1 provides a summary of these three types of knowledge group boundaries. Understanding which kind of knowledge boundary(s) is being spanned can help designers to improve their boundary-spanning efforts. We now turn to understand how objects support boundary spanning in design.

Objects play a central role in the cross-functional collaborative work of product development [23,42–45]. We refer to “objects” broadly to include representations of designs, risks, opportunities, tradeoffs, processes, workflows, etc. In the field of organization studies, scholars refer to such artifacts as “objects of collaboration” [34]. The following section summarizes background from engineering design literature on prototypes, a prevalent category of objects involved in cross-functional design collaboration and coordination. We then summarize theories from the field of organization studies on objects of collaboration more broadly, different object types, and how these objects help to span syntactic, semantic, and pragmatic knowledge boundaries.

While various objects have been found to structure the thoughts and actions of designers [23], prototypes play a prominent role in design practice and are key objects of study in design research. Foundational studies of prototypes describe how they provide both material and cognitive representations of design ideas [46], are used at different design stages and with varied fidelity to increase design quality and reduce development time [47], and vary depending on the types of questions being addressed (e.g., “works-like,” “looks-like,” or integration prototypes) [48]. A study with students found that simpler prototypes (those with fewer parts and fewer parts added over time) were correlated with better design outcomes [49]. Ethnographic studies in design firms found that prototypes—whether physical or digital—provided “small wins” [50] that fueled a sense of progress, reframed failure as an opportunity for learning, and strengthened designers’ creative confidence [51] in addition to enabling communication and informing decision-making [24]. Other design scholars have developed a “prototyping for X” framework that structures prototyping for novice designers [52] and heuristics that support designers to better tradeoff resources spent on, and design information gained from, prototypes [53]. While many studies have been based in Europe and North America, some have examined prototyping in East Africa [54] and India [55] and found that prototypes remain relevant collaborative objects but operate with different constraints and opportunities (e.g., the availability of materials and software, regulatory flexibility, etc.). For a more extensive review of design prototyping strategies and techniques, see Ref. [56].

Taken together, prior work in design research has established prototypes as key objects in design practice, characterized dimensions and kinds of prototypes, and shown how prototypes support design teams and outcomes. This body of work, however, offers limited theory on how prototypes, among other objects, support boundary spanning in design. One exception is a study of design collaboration between designers and bio-scientists in which prototypes and other objects supported knowledge sharing across disciplinary groups, with designers generating such objects more frequently than scientists [27]. To understand more about how objects can support cross-boundary design work, we turn to the field of organization studies.

The organization studies literature offers four types of “objects of collaboration:” infrastructure, boundary, activity, and epistemic objects (for a synthesis, see Ref. [34]). These collaborative object types are not characterized by objects’ inherent qualities but by how they are used. Thus, the same object may be categorized differently when it plays a new role in a new situation. To make this concrete, we draw upon an example from Carlile [33] of a computational fluid dynamics (CFD) model that served as an early-stage integration prototype for a new vehicle at a major automotive firm. The CFD model augmented traditional clay models of the vehicle made by Vehicle Styling designers. These clay models did little to help the firm’s four major functional groups—Vehicle Styling, Engine/Powertrain, Climate Control, and Safety—to foresee how the designs of one group would affect the designs of another. For example, a higher horsepower engine might affect the Vehicle Styling group by requiring a steeper front hood slope or the Climate Control group by requiring a bigger front grill. We will use the CFD model as an illustrative object of collaboration because it played multiple roles in helping these groups to span multiple kinds of knowledge boundaries. Let us begin with the CFD model’s use as an infrastructure object in spanning syntactic knowledge boundaries.

“Infrastructure objects” scaffold the transfer of cross-boundary information [57,58], such as images, plots, charts, or other visuals used in, for example, cross-functional meetings. Such objects help groups to develop a shared, stable syntax that facilitates accurate information transfer across their group boundaries. Building from the example above, co-developing a CFD model for the new automobile allowed designers from the Styling, Engine/Powertrain, Climate Control, and Safety groups “to establish a base common language that they could use to specify critical differences (e.g., size, geometry, weight, functionality)” in their designs [33]. To specify critical differences in the length of a vehicle’s front grill, designers from each functional group needed to understand grill length parameters in the same way so that their parameter values could be compared. In this way, the CFD model helped the designers to develop a shared syntax and thereby transfer pertinent information effectively across their syntactic knowledge boundaries. A variety of objects can play an infrastructure role in engineering design, including part libraries, Gantt charts, obeya walls [59], sprint task lists [60], FMEAs [61], and other standardized forms and methods. While infrastructure objects can facilitate a shared syntax for information transfer across syntactic boundaries, this does not guarantee a shared translation across semantic boundaries—that is the work of boundary objects.

“Boundary objects” translate information across group boundaries, thus allowing members of different groups to see and communicate different meanings from the same information. This can make visible consequential group differences and dependencies [3,26,62–64]. Boundary objects facilitate shared meaning by providing “interpretive flexibility”—being “plastic enough to allow polysemy across knowledge boundaries and rigid enough to support particular meanings within them” [35]. The automotive CFD model acted as a boundary object when it was used to represent the cross-functional consequences of potential design decisions, such as integrating a more powerful engine into the vehicle [33]. This design information was translated into new engine block dimensions, heat flux values, and vehicle weight so that the Styling group could see how higher horsepower would affect hood slope, the Climate Control group could see how it would affect grill size, and the Safety group could see how it would affect bumper location. Each group saw both different meanings (implications for their group’s specific design goals) alongside common meanings about what was of consequence. A variety of design artifacts can play a boundary object role, including prototypes, sketches, engineering drawings, bills of materials, value stream maps, and others. While boundary objects support translation across semantic knowledge boundaries and improve the visibility of differences and interdependencies across groups, they do not necessarily establish shared goals and transform knowledge and designs across pragmatic knowledge boundaries. For this, we turn to activity and epistemic objects.

These two types of objects build shared interest across pragmatic knowledge boundaries, though they do so in different ways. An “activity object” is used to identify contradictions between group interests and motivate negotiations across groups [65,66]. Activity objects show how the knowledge, goals, outputs, etc. of one group may have consequences for the knowledge, goals, outputs, etc. of another and, importantly, motivate cross-boundary negotiations that address these potential contradictions and interdependencies. While activity objects act as sources of contradiction and negotiation, “epistemic objects” act as sources of attraction and discovery [67]. Epistemic objects stimulate joint interest across groups to collaborate to solve a joint problem or generate new knowledge. They represent the “thrill of potential discovery” and offer a “not-yet-completeness” that stimulates collective energy and emotional investment [34]. Otherwise weakly connected members of different groups may rally around an epistemic object and build solidarity as they address a joint challenge or opportunity [67]. Activity and epistemic objects facilitate not only the cross-boundary transfer and translation of information but also the transformation of groups’ goals, knowledge, designs, workflows, etc.

To illustrate with the same example, the CFD model acted as an activity object when “each group could first represent their various concerns, data points, and requirements, then engage each other to identify, negotiate, transform, and verify the knowledge that they would then use to design the vehicle” [33]. In this way, the CFD model not only transferred and translated information but also transformed within-group knowledge and associated design parameters across the four functions. For example, when considering the use of a higher horsepower engine, Engine/Powertrain, Styling, Climate Control, and Safety, each transferred their desired design parameters into the shared infrastructure of the CFD model. This helped them to transfer, translate, and see the consequences of their design parameters on other groups’ designs, but it also helped them to transform their designs by seeing and negotiating tradeoffs at an early stage when design changes were relatively inexpensive to make. This resulted in a vehicle development program that “avoided major rework costs and launch delays” [33]. While CFD models are one example, a variety of engineering artifacts can act as activity objects, including tradeoff curves [68], decision matrices [69], and value stream maps [70]. Similarly, various artifacts can act as epistemic objects, including failed parts, novel prototypes, and A3 reports [71]. Activity and epistemic objects both develop shared interest and motivate negotiation or discovery, thus transforming groups’ goals, knowledge, designs, and more across pragmatic knowledge boundaries.

Taken together, prior work has synthesized four types of objects that can help to span knowledge group boundaries [34]. In this paper, we synthesize these collaborative object types alongside theory on prototypes and types of knowledge boundaries. In doing so, we draw connections that suggest that each collaborative object type helps to span a particular kind of knowledge boundary, as described above. Additionally, as is evident in the CFD model example, this set of theories suggest that collaborative objects can play multiple roles and transition between roles depending on the context of their use. So, in our study, we will not ask which type of object a collaborative artifact is, but, rather, when it is a certain type. This matters because how an object is used—the role(s) it plays—may be consequential for its outcomes of use. We build upon prior theory by clarifying the roles that objects play in structuring cross-functional design interactions and the outcomes that seem to follow from those object roles and their sequences.

We underwent a 24-month ethnography focused on cross-boundary design work during the development of complex hardware products within a global turbomachinery company. Focused ethnography directs a researcher’s inquiry toward a particular phenomenon or situation—i.e., cross-boundary design work—instead of exploring an entire organizational and cultural system [72]. We used ethnographic methods and paid particular attention to cross-functional interactions that occurred in the presence of objects. Data collection and analysis happened in parallel, as described below.

“Turbo” is a subsidiary of a large corporation that designs, manufactures, and services turbomachinery globally. Their campus in the United States houses thousands of employees. Compressor Engineering (CE), one of Turbo’s product development divisions, consists of roughly 60 engineers who contribute to developing industrial gas compressors (see a representative example in Fig. 2). Turbo CE engineers ranged in age from just-graduated to near-retirement, with many who had been with the division for decades. Turbo CE was formally arranged as a matrix organization with seven functional groups: Advanced Technologies, Aerodynamics, Mechanical Design, Rotordynamics, Structural Analysis, Supply Chain, and Quality. A Products Management group was made of program managers who oversaw each product development program, managed budgets and timelines, and helped to coordinate work across the functional groups. Beyond CE, other divisions like Marketing, Manufacturing, and Packaging Engineering were also involved in new product development programs. For about a decade, leaders of Turbo CE had been experimenting with tools like kanban boards (a workflow management system), obeya walls (a system to visualize work status and identify deviations from expected conditions), and other tools from Lean Product and Process Development, e.g., Ref. [68]. Their advanced use of these tools in developing complex hardware products and an apparent culture of learning and continuous improvement were what initially attracted us to this organization.

We collected qualitative data from December 2019 through December 2021 in the form of ethnographic observations and interviews [73]. From December 2019 to February 2020, the lead author spent about one week per month full-time within Turbo CE. He was given a desk, building access, introductions, and invitations to attend meetings and conduct interviews. In March 2020, as the Covid-19 virus spread throughout the United States, Turbo moved to primarily remote work. From May 2020 to December 2021, the lead author conducted virtual observations and interviews for roughly 1–5 h per week. The methods used for data collection included: (1) in-person and virtual observations in the workplace, (2) fieldnotes of workplace observations, written and logged daily, (3) audio recordings of semi-structured interviews, (4) audio recordings (or fieldnotes when recordings were not permissible) of informal ethnographic interviews to debrief prior observations and validate emergent findings, (5) images or sketches (when images were not permissible), prototypes, and other artifacts resulting from cross-functional collaborative work. As the study progressed and categories emerged, data were “theoretically sampled” [74,75] by observing targeted social situations that helped to elaborate emergent findings. We aimed to collect not only data that validated our emergent understanding but also “negative cases” that led to the revision or expansion of our coding scheme. The total dataset collected and analyzed in the present study consists of 70 cross-functional meetings observed (in-person and virtually), 52 interviews conducted (ethnographic and semi-structured), and 84 objects observed in use during cross-functional meetings or retrospectively in the context of interviews. This came to a total of roughly 130 h of data spanning a two-year period, as summarized in Table 2.

We took a grounded theory approach [74,75] in analyzing our ethnographic data. This began with inductive open coding of fieldnotes and interview transcripts, building a codebook by iteratively moving between emergent codes and theoretical concepts from the literature, then progressed to writing and discussing memos among the research team, axially coding to form links between concepts, and constantly comparing and refining codes until theoretical saturation was reached. The first author conducted the primary coding and regularly shared memos with excerpts of data, codes, patterns, and potential connections to literature for discussion with the other co-authors. Our unit of analysis was instances of collaborative objects in use. This included any digital or physical artifact being used during cross-functional interactions. Open coding resulted in codes such as “low/high cross-group engagement,” “translating,” “problem-solving,” “co-developing a joint integrated solution,” and so on, which were further refined by reviewing the literature on prototyping, lean product and process development, boundary objects, and team learning. We saw and explored many phenomena in our data before focusing on collaborative objects. For example, we observed behaviors and tools at Turbo that appeared to support or hinder within- and between-group learning, including the use of an evolving set of “standard work” that spread and backstopped collective learning and kanban boards that appeared to limit firefighting and promote a culture of collective learning. The breakthrough that led to this paper occurred when we examined our data with the lens of “objects of collaboration” and subtypes of infrastructure, boundary, activity, and epistemic objects as described by Nicolini et al. [34]. The codebook used for the analysis in this paper is provided in Table 3.

In ethnographic fieldwork, data are typically collected by a participant-observer whose positionality—the intersecting ways that they identify with, are perceived as a member of, and are treated because of their perceived membership in, various social groups—inevitably shapes their research approach, data collection, analysis, reporting, etc. [76]. As the participant-observer at Turbo, the first author could never be a fully “neutral” or “objective” research instrument. So, during data collection, he noted and reflected on the ways that his positionality shaped the research [77]. For example, his identities as a white, mid-30s, Ohioan man and engineer influenced his “fitting in” at Turbo. During an early introductory meeting, Turbo staff warmly joked that he, like a majority of them, “had a beard and would fit right in.” His nearness to dominant identities at Turbo helped him relate to many staff and be invited into various settings. At the same time, his identities limited his invitation to other settings, the ways he could relate to staff with non-dominant identities, and the observations he made.

Our study, like other in-depth ethnographic studies, strives for internal validity, not generalizability. Future work may examine the transferability of our findings to other settings and populations. To establish internal validity, we followed recommended practices for analyzing qualitative data, e.g., Refs. [78,79]. Our process included intensive long-term involvement in our field site (24 months), strong theoretical foundations from the engineering design and organization studies literatures, theoretical sampling and triangulation using multiple data sources (i.e., interviews, observations, images, and archival documents), attempts to clearly report how data were collected and analyzed, debate on the meaning of data among a team of researchers, examination of “negative cases,” and validation of findings (“member checks”) with key informants (staff at Turbo). To protect privacy, pseudonyms are used for all informants in the following text.

Our findings identify a typology of collaborative objects that draws attention not to the qualities of objects themselves but to the roles that they play—how they are used—to span knowledge group boundaries in cross-functional design work. These findings support and translate existing theories from organization studies [33,34] into engineering design. We also identify two object role sequences and cross-functional design outcomes that appear to follow from them.

We observed a variety of objects during cross-functional interactions at Turbo that appeared to support design coordination, exploration, specification, problem-solving, decision-making, and more (see examples in Fig. 3). Across these objects, three roles emerged in how they facilitated cross-boundary design work. We found that collaborative objects (1) routinize cross-functional information transfer, (2) translate information across functional groups, and (3) motivate cross-functional negotiation and discovery (see summary in Table 4). In describing each role, we show how the latter two roles appear to be connected to certain kinds of cross-boundary design outcomes. In our data, objects could play multiple roles simultaneously, and while they tended toward a primary role in a given situation, this role could shift over time. This implies that an object’s role does not derive from its essential qualities but from how it is used. These findings offer guidance for how design teams might employ an appropriate range of objects during cross-functional interactions, use objects in ways that encourage desired cross-functional outcomes, and align team members’ expectations of an object’s role in a given situation. We begin with the first role—how objects routinize interactions between knowledge groups.

In our observations, objects played a routinizing role when they acted as infrastructure, bringing a cadence and scaffolding to routine cross-functional interactions. Objects that acted as routinizing infrastructure were not sources of attraction or contradiction like epistemic and activity objects, nor were they a means of cross-functional translation like boundary objects. They were scaffolds that routinized cross-functional engagements and, in the process, often faded into the background. At Turbo, objects that played a routinizing role included kanban boards (a workflow management system), obeya wall “andons” (flags that indicated deviation from expected conditions or progress), and part models (when frequently shared between functional groups). Development teams used such objects to bring a regular cadence and structure to their cross-functional engagements.

Obeya wall andons frequently played a routinizing role in our data. Obeya walls and andons are artifacts borrowed from lean manufacturing [80] and applied to product development. Obeya means “large room,” and andon means “lamp” in Japanese. At Turbo CE, obeyas involved a large physical or virtual room with physical or digital walls covered in text, plots, drawings, and images that depicted current design status, program milestones, and countermeasures to address technical, timeline, or other challenges. Obeya meetings typically involved routine status updates and coordination of expected handoffs of information or materials. Each design task on a program’s obeya wall included a highly visible red or green rectangle called an andon. Red andons were used at Turbo CE to call attention to a deviation from an expected state (a slip in timeline, change in scope, poor technical performance, etc.).

During one weekly virtual obeya meeting for a large development program, Ethan (pseudonym), the program manager, asked, “Is Arnold [an engineer in the Advanced Technologies group] on?” Arnold’s voice appeared and stated, “Yes, I’m here. I finished the system efficiency calculation, and I passed it to John [another Advanced Technologies engineer] for review. As soon as John and I get a thumbs-up from Jack [the Advanced Technologies group manager], I’ll send it to everyone [in the Rotor and Aero groups].” As Arnold spoke, Ethan scrolled to Arnold’s virtual obeya wall using his shared screen and displayed Arnold’s single red andon. This was a red rectangle on a slide with text that mentioned the efficiency calculation task and new expected completion date (see Fig. 4). Ethan and the managers of the Rotordynamics and Aerodynamics groups thanked Arnold for the update.

In this example, Arnold’s red andon routinized a cross-functional interaction during which information on the efficiency calculation status was transferred from Arnold (Advanced Technologies) to the managers of the Products, Rotordynamics, and Aerodynamics groups. The andon helped Arnold and these managers to span a syntactic boundary in that they regained a shared understanding of the expected system efficiency calculation completion date. The new date estimate needed only to be transferred (not translated or transformed) because each group held aligned interests around achieving a high system efficiency and already understood how they depended on each other and the efficiency calculation. This made the andon’s routinizing role sufficient in this situation. In other situations, such as when more complex (semantic or pragmatic) boundaries were present, objects were called to play other roles.

Objects played a translating role when they served as flexible lenses through which information was situated and meaningfully interpreted by members of different groups rather than just routinizing information transfer. At Turbo CE, objects that played a translating role included value stream plans/maps, prototypes, FEA analyses, engineering drawings, and more. For example, designers built a scaled prototype of a compressor to perform rotordynamic “drop tests” that involved “dropping” the rotor off its main bearings to validate that its backup bearings did not produce “whirl” or other negative consequences. This prototype played a translating role between designers in the Advanced Technologies group who used the prototype to perform the empirical tests, and designers in the Rotordynamics group, who built and calibrated a predictive analytical model based on the prototype’s results.

In another example, functional groups engaged each other in creating what they called value stream plans (VSPs). These were physical or virtual workflow diagrams of interdependent design tasks. Consider the example of a relatively small VSP conducted to plan a product test that involved an abnormal gearbox swap. Pat, a product manager in the Products group, called a meeting to co-develop the VSP with Oliver, an engineer from Rotordynamics, and Eli and Evan, a manager and technician from the Test Cell. Pat hung a long white piece of paper on a wall. The paper was printed with a grid with days listed along the columns and “Test,” “Aerodynamics,” and “Rotordynamics” listed along the rows (see top of Fig. 5). Pat offered a few introductory remarks, then Oliver, Eli, and Evan started to populate the grid as described in the following fieldnote excerpt:

This VSP translated information from Eli and Evan (Test Cell) into a form that was interpretable by Oliver (Rotordynamics). The information shared by Eli and Evan sparked Oliver to ask clarifying questions to Pat (“Do we need low vibes for this?” and “So we need to trim balance?”), which helped Oliver to learn which rotordynamic tasks he needed to perform. Eli and Evan learned from Oliver when he would finish and when they could start their second round of work (Day 11), and Pat learned that the entire test would require 16 days. The process of developing the VSP led to a shared understanding of handoffs and dependencies between the Test Cell and Rotordynamics groups, thus allowing these groups to span their semantic knowledge boundary. We observed that this kind of translation and semantic boundary spanning was especially important for more complex product development efforts. In a similar example, eight functional groups came together to co-develop a VSP that again played a translating role by making visible the handoffs and dependencies between each group’s expected design tasks (see bottom of Fig. 5). This also allowed them to provisionally map the program’s “critical path” (the green, blue, and purple arrows). Taken together, these example VSPs and drop test prototypes made visible interdependencies between groups which allowed pertinent information to be re-situated and translated across their semantic knowledge boundaries. We now turn to the final role of objects observed in our data that helped to not just transfer and translate information but to transform it and associated designs and design processes.

The third major role of collaborative objects we identified is motivating cross-boundary negotiation or discovery. Objects playing this role could help to span a pragmatic knowledge boundary by facilitating shared goals and interest not just shared syntax and estimates (syntactic boundary spanning) or shared understanding of group differences and dependencies (semantic boundary spanning). They motivated negotiation and discovery by acting as sources of contradiction or attraction—akin to activity and epistemic objects, respectively. At Turbo, objects that played a motivating negotiation role included tradeoff curves, Pugh decision matrices, and prototypes, and those that played a motivating discovery role included failed parts, finite element analyses, and “A3” reports [72] For brevity in this section, an example of only the motivating negotiation role will be provided. An example of motivating discovery is provided in the Co-design Sequence section.

To illustrate an object playing the motivating negotiation role, consider the “cost knockdown” spreadsheet and manufacturing cost-volume tradeoff curves that were jointly created by Sam, a manager from Products Management, Caleb, a manager from Supply Chains, and other stakeholders (see Fig. 6). Sam and Caleb had been tasked with transitioning several hundred existing impeller parts away from a prior manufacturer. They worked closely together on this effort but were frustrated by little progress over many months. At that time, Sam described their efforts as having devolved into a “whack-a-mole game” of “what-about scenarios” that had stymied decision-making. To illustrate the situation, consider the following excerpt from fieldnotes during a meeting between three members of Products Management and three members of Supply Chains, including Sam and Caleb:

This excerpt illustrates tension between the two groups and one “what-about” scenario (what if our in-house machining capability goes down again?). Over several months, we observed such “what-abouts” offered by members of both Products Management and Supply Chains with conclusions similar to “so we better be careful what we decide” that stymied progress. These interactions and the apparent conflict between the groups’ interests and agendas suggest that a pragmatic knowledge boundary was present. Products Management held goals around achieving particular costs, tolerances, and other aspects of product quality and performance, whereas Supply Chains held goals around working with suppliers that offered good lead times and had existing contracts with Turbo.

These tensions began to resolve only when Sam and Caleb found ways to “build ownership,” as they described in follow-up interviews, in a jointly developed “cost knockdown spreadsheet”—an object that motivated cross-boundary negotiation. They invited stakeholders from their groups and others (e.g., Marketing) to add to the spreadsheet the information that each believed was necessary to calculate net present value tradeoffs for producing each component using the available manufacturing processes (e.g., forging, machining, 3D-printing). As the group progressed, they collectively examined, debated, revised, and eventually agreed upon a manufacturing process recommendation for each component. Along the way, they generated visualizations that further clarified group tensions and tradeoffs, such as plots showing key manufacturing process tradeoff curves (see Fig. 6). In this way, co-creating the spreadsheet and tradeoff curves motivated negotiations that made visible and clarified contradictions between the Products Management and Supply Chains groups. This made it possible for joint design decisions to be made and the groups’ impeller manufacturing processes to be transformed, thus spanning their pragmatic knowledge boundary.

In our observations, it was rare that a collaborative object operated in isolation from other objects. We observed assemblages of objects being used in concert, objects instigating the creation of new objects, and objects that transitioned between roles depending on their context of use. This section illustrates two examples of object sequences that were prominent in our data and appeared to be tied to consequential cross-functional outcomes: co-discovery of a design risk, opportunity, or workflow bottleneck and co-design of a joint integrated solution (as summarized in Fig. 7). We describe both of these object sequences in turn.

A prominent role sequence in our data occurred when objects shifted from routinizing cross-boundary interactions to translating cross-boundary information, culminating in the co-discovery of a design risk, opportunity, or workflow bottleneck. We provide an example of such a sequence involving kanban boards at Turbo CE. Kanban means “signboard” in Japanese and is part of a workflow management system adapted from lean manufacturing [80] to manage and improve knowledge workflows. Turbo CE used kanban boards to manage which design tasks to work on, when to work on them, and by whom. During kanban board meetings, information appeared to be largely uncontested, and the boards fell into the background as group members discussed workflows. In such cases, kanban boards played a routinizing role by facilitating a cadence of task and timeline updates. However, there were moments when kanban boards shifted from a routinizing to translating role, making visible cross-functional workflow bottlenecks, as illustrated in the example below.

In a weekly 30-min cross-functional kanban meeting, the Director of Turbo CE and eight functional group managers met to review how tasks were flowing within and between their boards. This meeting occurred in person in front of the kanban boards (bottom of Fig. 8). Each manager gave a brief update in front of their board while sharing ideas or issues for discussion. During the meeting, Lucas, the Mechanical Design group manager, explained an opportunity to interrupt what he saw as a longstanding pattern of rework between his group and others, as detailed in this fieldnote excerpt:

While we observed that kanban boards typically assumed a routinizing role, this excerpt shows a moment when the boards transitioned to playing a translating role. How Lucas used the boards enabled the various group managers to translate their group-centric understandings into a shared understanding of rework patterns across the joint workflow system. This made it possible for the different groups to collectively see and, thereby, co-discover this workflow bottleneck, understand their interdependencies, and span their semantic knowledge boundaries. In addition to kanban boards, we observed obeya walls, finite element models, system optimizations, and other objects shifting from a routinizing to translating role culminating in co-discoveries.

A second prominent role sequence in our data occurred when objects moved from translating cross-boundary information to motivating negotiation or discovery, culminating in the co-design of a joint integrated solution. We provide two examples of such sequences. The first involves shifting from a translating to a motivating negotiation role, and the second involves shifting from a translating to a motivating discovery role. Both culminated in the co-design of a joint solution. The first example takes place during a weekly virtual obeya meeting, as described in the following fieldnote excerpt:

In this excerpt, Jim appears frustrated by a pragmatic knowledge boundary. He noted that, “there seems to be disagreement over which direction we should go with [the subsystem]” and “we have been working on this for quite some time, and we’re not making enough progress…” Jim’s andon (similar to Fig. 4) initially played a routinizing role as part of his weekly update but quickly shifted to playing a translating role as it sparked a dialogue between him, Ethan, and Henry “through which key uncertainties and tradeoffs between subsystem concept designs [were] made clear.” This andon and the associated interaction instigated a new collaborative object, a Pugh decision matrix, that Ethan suggested Jim work with on with Dustin “and any other folks we need […] to make a more wholesome assessment.” In subsequent observations, Jim worked with the broadened group to co-develop the decision matrix, which motivated cross-functional negotiations between him, Ethan, Henry, Dustin, and others. This culminated in the refinement and selection of a subsystem concept design—a joint integrated solution. Here we see a full example of an object (an andon) moving from a routinizing to translating role and then instigating a new object (a decision matrix) that played a motivating negotiation role. These coupled co-discovery and co-design sequences resulted in the co-design of a joint integrated solution (the subsystem concept design).

In another example, we see how an object that fills a translating role can instigate a new object that fills a motivating discovery role, again culminating in a joint solution. John, an engineer in the Advanced Technologies Group ran a routine analysis on a flange and was surprised to find high electromagnetic losses. He showed figures of his results to Leo, an engineer in the Structural Analysis group, and they debated to make sense of them. They agreed that there might be a risk of high temperatures being generated in the flange. This motivated them to investigate further and jointly develop a thermal model (a new object) that resulted in the discovery of a simple solution, as Leo describes during a subsequent cross-functional meeting:

In this example, John’s initial figures played a translating role between John and Leo and instigated them to develop a new object (a thermal model) that motivated the exploration and discovery of a joint integrated solution across their two groups (simply switching from carbon steel to 316 stainless). This solution was simple to implement because the design risk was identified and addressed at an early development stage, thus avoiding major rework. In addition to thermal models, we observed other instances when objects that played a translating role instigated new objects that played a motivating negotiation or discovery role, including failed prototypes, A3s, and system optimizations.

Through in-depth ethnographic observations in an engineering design company, we identified a range of objects that designers use to span knowledge group boundaries and make sense of or improve their designs and design processes. By iteratively reviewing our observations and putting them into conversation with both prior theory on prototypes from the engineering design field and prior theory on knowledge boundaries and objects of collaboration from the organization studies field, we offer a typology of roles that objects play in cross-functional design work—to routinize cross-boundary interactions, translate information across boundaries, and motivate cross-boundary negotiation or discovery. In doing so, we add support to existing theories of infrastructure, boundary, activity, and epistemic objects in the organization studies literature, e.g., Ref. [34] and add new theory to the ways that prototypes have been found to facilitate communication, learning, and decision-making in the engineering design literature, e.g., Ref. [24], particularly when spanning knowledge group boundaries.

Prior studies found that prototypes can be used to improve cross-boundary communication [26] and identified mechanisms of such communication, including explaining, persuading, negotiating, and providing feedback [24]. We build upon this existing theory of prototypes as communication tools by adding support to negotiating as an important role, suggesting two new roles (translating information and motivating negotiation or discovery across groups), and connecting these roles to consequential design outcomes (cross-boundary co-discovery and co-design). We observed that prototypes that played a translating role helped members of different groups to not talk past one another but rather to see their differences and interdependencies and co-discover new design risks, opportunities, and workflow bottlenecks. We also observed that prototypes (e.g., a model of electromagnetic losses) could motivate cross-boundary negotiation or discovery by instigating joint interest and intensifying cross-boundary dialogue, sometimes culminating in the co-design of a joint integrated solution (e.g., a flange made of material less susceptible to inductive heating). We found that not only prototypes played such roles but a variety of objects used in engineering design (see Fig. 3). Design methods may be categorized using our proposed object role typology. Methods (and objects) like the Design Structure Matrix [81], for example, might often play a translating role by identifying and clarifying the interfaces between subsystems and interdependencies between groups. Understanding a given object or method’s routinizing, translating, or motivating role(s) can help designers to better identify when and how to use such methods to span knowledge group boundaries.

Our final contribution to design theory is the identification of sequences of collaborative object roles. We show how certain cross-boundary design outcomes seem to follow from certain object role sequences. Objects appear to “have a career” as they transition between different roles. As illustrated in our findings, objects sometimes transitioned from a routinizing to translating role to identify a risk or opportunity. In other cases, objects played a translating role and instigated new artifacts that motivated cross-boundary collaboration to discover and solve a challenge or negotiate a design decision. These findings differ from Nicolini et al.’s [34] suggestion that objects may tend to begin as epistemic or activity objects and transition to boundary objects and, ultimately, infrastructure objects. In our data, objects’ life courses tended to move in the opposite direction. Future work may further investigate patterns in object role trajectories, how objects seed new objects, and the makeup of object assemblages.

Our findings offer recommendations for product development and innovation leaders. Underpinning these recommendations is the observation that an object’s espoused role can differ from its enacted role. For example, Turbo engineers explained that the role of a red andon was to signal that a design task had deviated from its target condition and spark cross-functional problem-solving to address the issue. In other words, the espoused role was to translate information across groups and/or motivate cross-boundary negotiation and discovery. However, we observed that the typical enacted role of red andons at Turbo was to routinize cross-boundary interactions in the form of one-way updates (as described in the Findings). Our study suggests that leaders can improve cross-boundary collaborative outcomes by encouraging and modeling the use of objects for their translating and motivating roles, not just their routinizing role.

For example, leaders could perform a basic inventory of the objects used during cross-boundary engagements in their workplace and then observe the extent to which these objects are used to simply routinize cross-boundary interaction versus translate across groups or motivate cross-boundary negotiation and discovery. When leaders observe a collaborative object consistently filling a routinizing role, they might start to encourage and model practices that build intergroup visibility, such as occasionally pausing a discussion to provide a cross-boundary summary of the conversation, asking clarification questions to one knowledge group when other groups may not fully understand what the first group is communicating, and prototyping alterations to objects that increase the visibility of intergroup dependencies and cross-boundary differences. To illustrate the later, one manager at Turbo prototyped a “resource constraint” flag on andons for design tasks in his purview that were on hold due to limited staff or funding availability. This inspired others to do the same, all of which helped to translate system-level resource constraint information across the groups. Of course, the routinizing role is important for developing a cadence of cross-boundary interactions and shared language to span syntactic group boundaries. However, if an object never transitions to higher-level roles, i.e., translating and motivating, it may become viewed as a waste of time, and engineers may disengage from its use, further limiting cross-boundary collaboration.

This study is limited in that it is based on observations in a single design company (Turbo) in a single industry (turbomachinery) with a limited population (predominantly engineers who present as white, men, and having been raised in the United States or Europe). Future work may examine the transferability of these findings to other organizations, industries, and populations. Additionally, the findings are limited in that we chose to closely examine the roles of objects in advancing cross-boundary design work rather than, for example, individuals’ states or traits (e.g., boundary-spanning mindsets), collective states (e.g., psychological safety), contextual factors (e.g., support from leadership), or other factors in our broader orienting framework (Fig. 1). While these are limitations, they are also opportunities for future research.

In particular, we suspect fruitful opportunities for research around engineers’ boundary-spanning mindsets. At Turbo, individuals from different functional groups appeared to hold different mindsets around the roles of collaborative objects and boundary spanning more generally. Mindsets are belief systems that include expectations, attributions, and goals, such as a growth versus fixed intelligence mindset or a stress-is-enhancing versus a stress-is-debilitating mindset [82,83]. Some engineers appeared to hold a static view of the role of some objects as routinizing infrastructure (e.g., kanban boards and obeya walls) that held limited potential to advance their technical work. These beliefs seemed to limit the objects’ potential to transition to higher-level roles (i.e., translating and motivating). Future research could examine this phenomenon, including engineers’ mindsets around collaborative objects and boundary spanning more generally.

Further research could also examine patterns in object roles used across design stages or between different sets of knowledge groups. This could involve measuring the degree to which particular object roles or sequences are associated with positive outcomes (e.g., co-discovery of risks or co-design of solutions) versus negative outcomes (e.g., cross-boundary tensions or misunderstandings). Such work could benefit from perspectives of design as a learning process [84] and drawing analogies to learning sequences, e.g., Ref. [85]. Similarly, future work could explore the object affordances and interaction scripts associated with desirable cross-boundary outcomes. This could advance the design field’s understanding of how to build collaborative design tools that are unlikely to only routinize interactions but, rather, facilitate cross-boundary translation and motivate negotiation and discovery.

Finally, our findings suggest new avenues for developing artificial intelligence (AI) agents to support human design teams in spanning knowledge group boundaries. As an example that builds from our observations, Turbo CE might benefit from an AI agent that can automatically highlight task bottlenecks and associated intergroup task flows on their virtual kanban boards. Such an AI agent could help to make visible and translate interdependencies between functional groups and, as Lucas did in the excerpt in our Findings, motivate the co-discovery of joint solutions to relieve workflow bottlenecks. Along similar lines, AI agents could be trained to highlight potential interdependencies in CAD, FEA, and other models across knowledge groups. Such tools could help development efforts to avoid missing subsystem interfaces, such as those missed in the Pratt & Whitney PW4098 jet engine discussed in the Introduction. AI agents of these forms have the potential to dramatically improve cross-boundary design work and product development outcomes.

Through a two-year ethnographic study embedded in a turbomachinery design company, we identified three roles that collaborative objects play in spanning knowledge group boundaries: (1) routinizing cross-boundary interaction, (2) translating information across boundaries, and (3) motivating joint negotiation or discovery. These findings add support to the idea that the outcomes associated with collaborative artifacts cannot be reduced to the essential qualities of the artifacts themselves. We must examine how artifacts are used. We also found two prominent object role sequences: (1) routinizing to translating, culminating in the co-discovery of a design risk, opportunity, or workflow bottleneck, and (2) translating to motivating, culminating in the co-design of a joint integrated solution. These findings start to characterize how objects shift between roles, instigate new objects, and operate in assemblages and further clarify how objects are consequential in design collaboration. Taken together, the findings are significant because they clarify the roles of artifacts in cross-boundary design work and suggest ways for designers to more effectively use objects to span their knowledge group boundaries.

We thank the employees of “Turbo” who graciously offered their time and insights to this study while opening their physical and virtual doors to the first author. We are grateful to all involved in the paper review and publication process for their time and critical feedback. We also thank Forrest Stuart, James Morgan, John Shook, Steven Eppinger, Michel Anteby, and participants in the Stanford Work, Technology & Organization “Craft of Inductive Qualitative Research” workshop for their guidance in various stages of this study.

• 10.13039/501100008982 National Science Foundation Division of Information and Intelligent Systems under (Grant No. IIS-1716992; Funder ID: 10.13039/501100008982).

• 10.13039/501100008982 National Science Foundation Graduate Research Fellowship Program under (Grant No. DGE-1656518; Funder ID: 10.13039/501100008982).

• Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.

There are no conflicts of interest.

The datasets generated and supporting the findings of this article are obtainable from the corresponding author upon reasonable request.