2. Coordination in design optimization

Multidisciplinary design optimization arose from the need to analyse systems whose constituent elements are modelled with various discipline-based analysis tools (Sobieszczanski-Sobieski Reference Sobieszczanski-Sobieski1995). The analysis models integrated under MDO use different equations, assumptions and variables. However, these subproblems cannot be solved on their own. Maximizing individual subproblems without regard to how the solutions need to fit together will generally yield an infeasible or suboptimal system-level solution (Allison, Kokkolaras & Papalambros Reference Allison, Kokkolaras and Papalambros2009). Thus, the solution requires coordination: ‘the task of guiding subproblem solutions towards an optimal system design’ (Allison, Kokkolaras & Papalambros Reference Allison, Kokkolaras and Papalambros2009).

If all interfaces between analysis models are identified, they can be combined. Then, system behaviour can be modelled and optimized. An optimized system yields optimal values for subsystem and system variables, which are also consistent as inputs to, or outputs from, multiple models. The organization of discipline-specific models under an optimization scheme to coordinate the search for an optimal system solution is called the MDO architecture. A review of common MDO architectures is given in Martins & Lambe (Reference Martins and Lambe2013), who divide architectures generally into monolithic or distributed formulations. Here, we are concerned with the latter.

Some of the distinguishing features of MDO architectures are the location and purview of the decision-makers, and the approach to coordinating the partitioned analysis models. In the monolithic architecture, all discipline problems are combined into a single problem statement, which then requires no partitioning or coordination. A hierarchical architecture features a central coordinator that oversees what information is shared among subproblems and when. A nonhierarchical architecture distributes coordination among each subproblem. Each subproblem manages its own information exchange, typically according to a fixed routine.

The selection of an MDO architecture is dependent on the physical system’s architecture and the couplings that exist between discipline models (Martins & Lambe Reference Martins and Lambe2013). Coordination methods in MDO have been developed to take advantage of unique problem properties, particularly the existence and strength of coupling between subproblems. Examples include the use of global sensitivity equations (GSEs) and modified GSEs to calculate coupling strength (Hajela, Bloebaum & Sobieszczanski-Sobieski Reference Hajela, Bloebaum and Sobieszczanski-Sobieski1990; Alyaqout et al. Reference Alyaqout, Peters, Papalambros and Ulsoy2011), improved computational efficiency through suspension of weakly coupled subproblems or reformulation of subproblem optimizers (Alyaqout et al. Reference Alyaqout, Peters, Papalambros and Ulsoy2011; Alexandrov & Lewis Reference Alexandrov and Lewis2002) and the inclusion of uncertainty (Yao et al. Reference Yao, Chen, Luo, van Tooren and Guo2011).

MDO coordination architectures are powerful tools for computational design, given system models. A solution to an MDO problem yields a set of fully consistent coupling variables between modelled systems and insight into system behaviour. What is difficult to model includes factors such as incomplete information, unknown or emergent couplings and the role of humans as designers who sometimes make mistakes (Simpson & Martins Reference Simpson and Martins2011; Bloebaum, Collopy & Hazelrigg Reference Bloebaum, Collopy and Hazelrigg2012).

These human attributes are also what makes MDO algorithms unreasonable procedures for human designers to follow. For example, a central (computational) decision-maker in an optimization routine is capable of simultaneous processing of information and near-simultaneous delivery to connected analysis functions. This ideal decision-maker also has full information about the system. Neither the ability to simultaneously process multiple inputs nor the assumption of complete information is reasonable for a human decision-maker (Simon Reference Simon1955), much less an organization. Though human decision-makers are not rational, there have been efforts to incorporate the best of human strategies into multiobjective decision-making. These efforts include the use of games to converge on optimal designs (Ren, Bayrak & Papalambros Reference Ren, Bayrak and Papalambros2016), behavioural experiments to identify what causes designers to shift between exploration and exploitation of alternatives (Panchal, Sha & Kannan Reference Panchal, Sha and Kannan2017), exploring the potential upsides of bounded rationality to improve design solutions (Gurnani & Lewis Reference Gurnani and Lewis2008) and using bounded rationality as a baseline for evaluating the impact of selecting different overall objective functions in a design process (Herrmann Reference Herrmann2010). Classic MDO algorithms are therefore an example of a prescriptive coordination strategy, which can benefit from consideration of the properties and behaviour of individual subproblems.

3. Coordination in organization science

Coordination activity during design is contextualized by the designing organization. This organization thus dictates roles, lines of communication, trust, authority and accountability (Simon Reference Simon1973; Galbraith Reference Galbraith1974; Gulati & Singh Reference Gulati and Singh1998). There are three primary ways of viewing organizations: as rational systems where all actors work in concert to achieve a common objective; as natural systems where actors have diverse goals but use the organization as a common source of information and knowledge and as open systems where actors selectively join and separate to achieve their goals (Scott & Davis Reference Scott and Davis2006).

The foundational literature on coordination largely builds on the rational system model – that every organization has a central goal (March and Simon Reference March and Simon1958; Blau Reference Blau1974; Scott & Davis Reference Scott and Davis2006). A defining feature of a formal organization is ‘the existence of procedures for mobilizing and coordinating the effects of various, usually specialised subgroups in the pursuit of joint objectives’ (Blau Reference Blau1974). Coordination in organizations is about managing interdependencies between groups of people (Malone & Crowston Reference Malone and Crowston1994). Similar to distributed optimization, individual expertise is partitioned into groups, teams and individual roles. Their work is then coordinated through the development of rules, plans and channels for rapid feedback (March & Simon Reference March and Simon1958; Thompson Reference Thompson1967; Van de Ven, Delbecq & Koenig Reference Van de Ven, Delbecq and Koenig1976). The more complex the tasks undertaken by the organization, the more rules, plans and channels for feedback are incorporated into formal organization design (March & Simon Reference March and Simon1958; Galbraith Reference Galbraith1974; Tushman Reference Tushman1979; Malone Reference Malone1987). These may be interpreted, respectively, as design and manufacturing processes, project management and schedules and office layouts and meetings designed to bring interfacing groups together. Therefore in the design and development of LSCES, all of these features of formal organization are expected.

Such prescriptive coordination processes can also evolve, based on how unknown but anticipated coordination needs are interpreted. The frequency of anticipated coordination work and trust between parties within organizations, or between organizations, are significant factors in determining how that coordination is carried out (Gulati & Singh Reference Gulati and Singh1998). Similarly, new technologies may improve awareness of how system elements are related. However, trust in the technology as an accurate representation of those interactions is key to its adoption (Dossick & Neff Reference Dossick and Neff2010). In addition, the identification of coordination needs does not necessarily translate to realized coordination if the organization structure makes developing those communication channels expensive (Dossick & Neff Reference Dossick and Neff2010). Anticipated coordination may also drive the creation of new organizational channels for information transfer (Gulati & Singh Reference Gulati and Singh1998), but unplanned, unexpected or infrequent coordination needs are more difficult to address (Sosa, Eppinger & Rowles Reference Sosa, Eppinger and Rowles2004). These works reinforce the impact of organization structure on coordination activity, both in identifying dependencies and in coordinating across those dependencies.

Informal processes, referring to personal values and individuals’ interactions within a formal organization, have also long been recognized as important in organizations (Blau Reference Blau1974; Barnard Reference Barnard1964). The concepts of ‘soft’ systems methodology emphasizing systems thinking (Checkland Reference Checkland2000), social capital emphasizing development and leverage of social networks (Larsson Reference Larsson2007; Adler & Kwon Reference Adler and Kwon2002; Esser Reference Esser2008; Van Deth Reference Van Deth2008; Agneessens & Wittek Reference Agneessens and Wittek2012), brokerage emphasizing bridging communities or ‘structural holes’ (Burt Reference Burt1992; Obstfeld, Borgatti & Davis Reference Obstfeld, Borgatti and Davis2014; Burt & Merluzzi Reference Burt and Merluzzi2014) and positive leadership emphasizing empathy and optimism (Baker, Cross & Wooten Reference Baker, Cross and Wooten2003; Terrasi Reference Terrasi2015) are well-known informal organizational processes exploited to enhance an organization’s information flow or productivity. However, these concepts are not generally explicitly connected to the coordination of technical tasks towards a common system-level objective, typical of LSCES design.

Informal processes emphasize the role of individuals in organizational behaviour. One approach to interpreting coordination among designers in an organization is to compare observed activity to established MDO architectures. Past research has illustrated that some decision-makers within organizations use a process that is similar to a hierarchical MDO algorithm termed a ‘hybrid MDO–game theoretic’ model (Austin-Breneman, Yu & Yang Reference Austin-Breneman, Yu and Yang2015; Honda et al. Reference Honda, Ciucci, Lewis and Yang2015). While information sharing among individuals in the organization was found to follow a pattern similar to an algorithm, it was not guaranteed to converge due to the incomplete information shared between subsystems (Austin-Breneman, Yu & Yang Reference Austin-Breneman, Yu and Yang2015) – more likely in situations of uncertainty and ambiguity, common in LSCES design. Other approaches to understanding coordination between individuals specifically in the context of LSCES design include economic theory (Mosleh, Ludlow & Heydari Reference Mosleh, Ludlow and Heydari2016), game theory (Vermillion & Malak Reference Vermillion and Malak2015; Takai Reference Takai2010), miscommunication (Meluso, Austin-Breneman & Uribe Reference Meluso, Austin-Breneman and Uribe2020) and exploration of the cognitive processes of systems engineers (Greene, Papalambros & McGowan Reference Greene, Papalambros and McGowan2016; McGowan Reference McGowan2014). Thus, effective coordination within organizations depends not only on the information sharing architecture but also on the quality of that information as supplied and understood by people. In composite, this literature suggests again that coordination effectiveness, particularly for complex design projects, depends on both more formal, top-down coordination strategies as well as individual behaviours and actions.

4. Coordination in software and engineering design

Software engineering and engineering design focus on the design problem per se. While the MDO approach focusses on coordination of partitioned elements, another approach is to start from the process of partitioning to effect desired coordination. For example, this approach might seek to minimize the need for coordination. Several best practices for the design of products and systems focus on partitioning to reduce coordination needs and to use modularization (Parnas Reference Parnas1972; de Souza et al. Reference de Souza, Redmiles, Cheng, Millen and Patterson2004; Maier & Rechtin Reference Maier and Rechtin2009; Panchal Reference Panchal2010; Bayrak et al. Reference Bayrak, Collopy, Papalambros and Epureanu2018). A motivation for developing a more modular product or design process is the high cost of frequent intergroup communication in integrative design work (Pimmler & Eppinger Reference Pimmler and Eppinger1994; Cataldo et al. Reference Cataldo, Wagstrom, Herbsleb and Carley2006) and is one driver for developing a more modular design process (Bosch & Bosch-Sijtsema Reference Bosch and Bosch-Sijtsema2010). Another set of objectives might be based on lifecycle properties of the product or system, suggesting partitioning strategies based on maintenance requirements, changeable technologies or product differentiation (Dahmus, Gonzalez-Zugasti & Otto Reference Dahmus, Gonzalez-Zugasti and Otto2001; Asikoglu & Simpson Reference Asikoglu and Simpson2012; Borjesson & Hölttä-Otto Reference Borjesson and Hölttä-Otto2014; Bayrak et al. Reference Bayrak, Collopy, Papalambros and Epureanu2018).

Module identification or design is often accomplished using a design structure matrix (DSM) or functional dependency table (FDT). These matrices indicate how system elements are related, either showing element to element dependencies in a DSM or dependencies between parts and design variables in an FDT. To identify modules, the goal is to reduce interactions across some set of elements, or modules, by rearranging the matrix of interactions. In a complex system, many design variables will be shared between functions. To cleanly divide a system into elements, some of the most-connected variables will need to be set aside as integrating elements (Baldwin & Clark Reference Baldwin and Clark2000). The remaining elements can be divided into modules using design rules (Baldwin & Clark Reference Baldwin and Clark2000) or graph partitioning (Wagner & Papalambros Reference Wagner and Papalambros1993; Krishnamachari & Papalambros Reference Krishnamachari and Papalambros1997).

Design via modularization illustrates a focus on ensuring that the subsystem interfaces are simple connections between complex elements. Modular design is considered good practice both in systems architecting (Maier & Rechtin Reference Maier and Rechtin2009) and software design (Parnas Reference Parnas1972); however, it presents challenges as systems become more complex. The implementation of simple interfaces between technical interfaces also promotes the practice of hiding the complex nature of a technical element behind an interface (Parnas Reference Parnas1972). In practice, this is often accomplished in software by the use of application-program interfaces (APIs). However, APIs have been shown to cause coordination challenges due to the increasing complexity of both APIs and the modules behind them (de Souza et al. Reference de Souza, Redmiles, Cheng, Millen and Patterson2004). Communication tends to follow organizational boundaries (Kleinbaum, Stuart & Tushman Reference Kleinbaum, Stuart and Tushman2008), and interfaces across those boundaries are often sources of interteam communication lapses (Kraut & Streeter Reference Kraut and Streeter1995; Sosa, Eppinger & Rowles Reference Sosa, Eppinger and Rowles2003, Reference Sosa, Eppinger and Rowles2004; Dossick & Neff Reference Dossick and Neff2010; Galviņa & Šmite Reference Galviņa and Šmite2012) Many such interfaces are potential sources of defects (Piccolo et al. Reference Piccolo, Lehmann and Maier2018; Zimmermann & Nagappan Reference Zimmermann and Nagappan2008). Geographically distributed teams and organizations face further challenges due to communication delays and differing norms (Olson & Olson Reference Olson and Olson2000; Herbsleb & Mockus Reference Herbsleb and Mockus2003).

Communication itself is challenging, and the complexity of LSCES design work compounds the challenge: where parts are complex, interfaces are emerging and evolving, and where geographically distributed teams and organizations are common. The challenges documented in the literature of common architecting strategies (such as modularization) for the design of complex system design suggest the importance of individuals contributing to coordination efforts.

5. Coordination in systems engineering

Systems engineering is a process to enable the design of a system, with a focus on managing the complexity inherent in the design of LSCES (Hazelrigg Reference Hazelrigg1996; Johnson Reference Johnson2002; Maier & Rechtin Reference Maier and Rechtin2009; Blanchard & Fabrycky Reference Blanchard and Fabrycky2011; de Weck, Roos & Magee Reference de Weck, Roos and Magee2011). Most systems engineering process standards include some variant of requirements definition, detailed design, test and integration, verification and validation and operation and maintenance (Johnson Reference Johnson2002; INCOSE 2004; Doran Reference Doran2006; NASA 2007; United States Department of Defense 2017). These processes formalize partitioning and coordination through technical control processes including requirements management, interface management and configuration management (Johnson Reference Johnson2002; NASA 2007; Blanchard & Fabrycky Reference Blanchard and Fabrycky2011). This documentation supplies the information needed to make coordinated, or internally consistent, decisions at every step of design. However, documentation alone does not ensure coordination: the documentation must be written, stored, accessed and understood the same way by others. If systems engineering is to manage complexity from both technical and social sources, it must be more than good documentation (Ryschkewitsch, Schaible & Larson Reference Ryschkewitsch, Schaible and Larson2009; Griffin Reference Griffin2010; Triantis & Collopy Reference Triantis and Collopy2014; Bloebaum & McGowan Reference Bloebaum and McGowan2012).

These tasks reiterate the notion that systems engineers have a managerial role, with responsibility to ensure successful system integration throughout the lifecycle (Sage & Lynch Reference Sage and Lynch1998). Focussing on the design aspect of systems engineering, systems engineers can be considered as decision-makers whose task is to select the design that is most preferred based on evaluation of available options under risk and uncertainty (Hazelrigg Reference Hazelrigg1996) or as enablers of elegant design (Griffin Reference Griffin2010). For a review of elegance and simplicity in LSCES and product design, see Lewis (Reference Lewis2012); Watson et al. (Reference Watson, Griffin, Farrington, Burns, Colley, Collopy, Doty, Johnson, Malak, Shelton, Szajnfarber, Utley and Yang2014); Krayner & Katz (Reference Krayner and Katz2018); Efatmaneshnik & Ryan (Reference Efatmaneshnik and Ryan2019).

Coordination between different groups in an organization is typically reserved for specific coordination roles within the organization (Cataldo & Herbsleb Reference Cataldo and Herbsleb2008; Grubb & Begel Reference Grubb and Begel2012); systems engineers are an example. As described above, systems engineering requires continual integration of technical elements via design and management activities. However, there is little consensus as to the actions systems engineers and coordinators ought to undertake to achieve an integrated optimal design (Bloebaum, Collopy & Hazelrigg Reference Bloebaum, Collopy and Hazelrigg2012; Bloebaum & McGowan Reference Bloebaum and McGowan2012). The existence of a social component to systems engineering has been recognized in multiple systems engineering competency models (Metzger & Bender Reference Metzger and Bender2007; Williams & Derro Reference Williams and Derro2008; Woodcock Reference Woodcock2010; Frank Reference Frank2012; Hutchison, Henry & Pyster Reference Hutchison, Henry and Pyster2016; Pietrzyk & Handley Reference Pietrzyk and Handley2016). These competency models have identified skills and behaviours exemplified by effective systems engineers in defense and commercial industry. Skills include basic engineering know-how, holistic thinking, familiarity with systems engineering lifecycle and process, management and leadership abilities and the ability to collaborate and communicate across diverse groups (Metzger & Bender Reference Metzger and Bender2007; Williams & Derro Reference Williams and Derro2008; Woodcock Reference Woodcock2010; Frank Reference Frank2012; Hutchison, Henry & Pyster Reference Hutchison, Henry and Pyster2016; Pietrzyk & Handley Reference Pietrzyk and Handley2016). What is not directly included in these competency models is an illustration of how the interpersonal skills identified are used to support system-level coordination of design work.

6. Coordination in ecosystems

The above focussed primarily on the challenges posed within an organization having distributed offices. LSCES design and manufacturing is often carried out by not just one, but multiple organizations arranged in a networked ecosystem (Moore Reference Moore2006; Perrow Reference Perrow2009; de Weck, Roos & Magee Reference de Weck, Roos and Magee2011; Jacobides, Cennamo & Gawer Reference Jacobides, Cennamo and Gawer2018). In these ecosystems, firms and organizations exchange material, energy and information (Baldwin Reference Baldwin2007) and each organization’s successes and challenges impact others in their ecosystem (Adner & Kapoor Reference Adner and Kapoor2010).

Modularization, as described above, is often applied to hardware and software systems to partition work and tasks within and between organizations. For example, Michelena et al. (Reference Michelena, Scheffer, Fellini and Papalambros1999) shows early work on distributed system design using common object request broker architecture. Modularization is a partitioning strategy however, and coordination strategies have been shown to differ. As examples, Papalambros (Reference Papalambros2002) and Jacobides, MacDuffie & Tae (Reference Jacobides, MacDuffie and Tae2016) illustrate well how automotive original equipment manufacturers (OEMs) have realized the value and potential of performing the role of integrator across suppliers organized hierarchically. In contrast, the electronics sector studied by Luo et al. (Reference Luo, Baldwin, Whitney and Magee2012) is nonhierarchical, with individual organizations much more active in their own coordination approach. Organizations can also change their positioning within their ecosystem by restructuring their approach to coordination over time (Adner & Kapoor Reference Adner and Kapoor2010; Sun & Wei Reference Sun and Wei2019).

The variance in ecosystem architectures, or the division of agents in the ecosystem and their pattern of connections (Helper, MacDuffie & Sabel Reference Helper, MacDuffie and Sabel2000; Jacobides, Knudsen & Augier Reference Jacobides, Knudsen and Augier2006; Luo Reference Luo2018), mirrors that of the diversity of architectures found in MDO, organization design and system design mentioned previously. In common among the coordination architectures discussed here and in previous sections, there are both formally structured elements and emergent or flexible elements resulting from the behaviour of the system elements (organizations, analysis models or human decision-makers).

Organizations are also collections of individuals and the literature on innovation ecosystems articulates the importance of individual actions in successful coordination towards overarching shared objectives similar to previous sections of this review. Organizations collaborate, cooperate and coordinate tasks similar to human actors (e.g., Dedehayir, Mäkinen & Ortt Reference Dedehayir, Mäkinen and Ortt2018; Ranganathan, Ghosh & Rosenkopf Reference Ranganathan, Ghosh and Rosenkopf2018) and individual leadership behaviours in turn can impact the behaviours of the group and ecosystem to effect that coordination (Roundy Reference Roundy2020).

7. Motivation and aims

Coordination is described in multiple disciplines as a preconceived strategy or set of rules to address the uncertainty and interdependence between diverse tasks completed in support of a common goal. The reviewed literature shows the existence of system-level coordination methods, work processes and plans instituted by the organization or system. A commonly used design process is an example. For individuals in the organization, coordination is facilitated through top-down prescription of rules, schedules, procedures and plans for individuals’ tasks and lines of communication. Literature in varied disciplines also emphasizes the importance of individual behaviour: examples include trust and mutual understanding between individuals, and acceptance and tailoring for varied individual behaviours. These examples apply for human designers, as well as for architecting strategies to coordinate and integrate varied analytical routines as in design optimization. In the context of coordination, individual behaviours and actions can be seen as adjustable design variables. For example, a common design process may be mandated within an organization or ecosystem. How individuals execute, and are guided to execute, that process also contributes to coordination.

The focus of this work is the design of LSCES, which are by nature of their size and use of novel technologies very complex (de Weck, Roos & Magee Reference de Weck, Roos and Magee2011; Bloebaum & McGowan, Reference Bloebaum and McGowan2012). Another prominent source of complexity is the social system engaged in system design and development work (de Weck, Roos & Magee Reference de Weck, Roos and Magee2011; Bloebaum & McGowan, Reference Bloebaum and McGowan2012; McGowan Reference McGowan2014; Sheard et al. Reference Sheard, Cook, Honour, Hybertson, Krupa, MeEver, McKinney, Ondrus, Ryan, Scheurer, Singer, Sparber and White2015; Grogan & de Weck, Reference Grogan and de Weck2016). Distributed knowledge (Cumming Reference Cumming2002; McGowan Reference McGowan2014), inconsistent preferences (Kannan, Mesmer & Bloebaum Reference Kannan, Mesmer and Bloebaum2017; Bhatia, Mesmer & Weger Reference Bhatia, Mesmer and Weger2018) and multiple incentives (Vermillion & Malak Reference Vermillion and Malak2015; Grogan et al. Reference Grogan, Ho, Golkar and de Weck2018; Meluso & Austin-Breneman Reference Meluso and Austin-Breneman2018) all contribute to complexity and hence challenges for coordination. This prior work demonstrates the need for including individuals in an understanding of coordination in LSCES design practice.

The reviewed literature shows the need to account for individual behaviour as technical and social interfaces exhibit emergence, unpredictability and uncertainty – all characteristic of LSCES design. The goal of this exploratory study is to uncover what strategies – behaviours and actions – individuals use to facilitate coordination of overall system design. The research question guiding this work is the following:

In this paper, we present the results of an exploratory study guided by this question. We explore the connection between individual behaviours and actions, and their contribution to system-level coordination efforts. This study was previously documented in Collopy (Reference Collopy2019). The individuals’ behaviours and actions we refer to as facilitation of coordination, drawing a distinction between individual behaviour and action and the aggregate coordination at the scale of the entire organization. Validation of a causal relationship between the two remains an open question.

The significance of this work is twofold. First, we identify individuals’ coordination-facilitation strategies used during LSCES design. While coordination in the literature typically refers to system- or organization-level coordination, we find that both system-level coordination rules followed by individuals and coordination driven by behaviours or actions are required in order to coordinate complex tasks. Second, we discuss connections between these coordination-facilitation strategies and concepts in organizational behaviour theory not typically associated with coordination. This discussion highlights a distinct link between social theory and design practice.

9. Thematic analysis

9.2. Deductive coding

Initially, deductive coding was attempted using 15 deductive codes derived from the initial research question. The deductive codes were grouped into four topics: personal (attributes of a person, innate or imposed by organization), interpersonal (attributes of one’s interactions with others, innate or imposed by organization), design process (attributes of design process) and technical (descriptions of technical design work). These deductive codes are defined in Table 2. The data were coded using NVivo (NVivo for Mac Version 11), a Computer Assisted Qualitative Data Analysis Software (CAQDAS) tool. The result was a set of 2388 segments: excerpts were typically 2–4 sentences long.

Table 2.

Deductive codes and definitions used for second step of thematic analysis, divided by topic.

The 10 interviews from each organization were analysed separately during the deductive coding step. After this coding step, we found that the segments coded across the two sets of interviews yielded similar concepts. However, through discussion and reflection on the deductive codes, there were multiple nuances of coordination activity not sufficiently described by this deductive coding structure. Therefore, we chose to aggregate the coded segments generated from all interviews for the next step of analysis.

9.3. Inductive coding

We used inductive analysis to identify the multiple concepts within each of our deductive codes. Whereas deductive coding is a process of fitting qualitative data to a structure, inductive coding is a process of fitting a structure to the data (Patton, Reference Patton2015, p. 64). This is an iterative process, where potential codes are created, merged and potentially discarded as the concepts in the data are organized. Three coders participated in the inductive coding as before; one of whom participated in interviews and two of whom did not.

Our process included two iterations: the first to identify potential or initial codes out of deductively coded segments, and the second to refine and organize those codes into final inductive codes. We collaboratively reviewed each deductive code one at a time, tagging the segments with initial codes and subcodes. The initial codes represent common threads that emerged from review of the deductively coded segments, and subcodes are specific examples of those common threads. An example is an initial code we called ‘Formally Structured Information’ which included subcodes of presentations, reports, technical documentation, database, schedule, budget and deliverables.

Throughout analysis, codes and subcodes were added and combined as necessary. After reviewing all the deductively coded segments, the initial codes and subcodes were laid out on cards, and overlaps and connections between them were considered. Rearranging cards, we grouped initial codes and their respective subcodes into final inductive codes. Continuing the above example, the subcodes within the initial code of ‘Formally Structured Information’ were reorganized into final inductive codes of ‘Information Usage’ and ‘Systems Engineering Process’. A map of the interrelations we observed between inductive codes is shown in Figure 1, with inductive codes grouped into four topics: Precursors, Methods, Purpose and Context. The general flow of this map is that precursors inform the choice of methods used to accomplish a purpose, all within the context of a design process. While the deductive codes are organized by type of task, the inductive codes and topics are instead organized along a temporal axis separating actions and outcomes. The final inductive codes, their definitions and some example subcodes are given in Table 3.

Figure 1.

Map of interrelations between inductive codes. Codes are marked in blue and organized into topics of (a) Precursors, (b) Methods, (c) Purpose and (d) Context. Arrow labels are general characterizations of the relationship between inductive codes. Inductive codes are defined in Table 3.

Table 3

Inductive codes, definitions and selected subcodes, divided by topic as used for third step of thematic analysis

9.4. Theme identification

Inductive codes describe the content of the interviews, but they do not necessarily give insight into the meaning behind the content. Our next step of analysis was to look in more detail at the relationships between inductive codes as shown in Figure 1. For example, which communication preferences dictate which job methods or approaches will be used? What job functions create what kind of information? To address the research question of how coordination is accomplished in practice, we focussed on one specific question: what job methods, approaches and styles are used to accomplish specific roles and functions? In other words, we looked at the connections between inductive codes ‘Communication preferences’, ‘Job methods, approach and style’ and ‘Role, Function’ (which includes facilitation of coordination).

We looked for evidence of relationships between subcodes by reviewing text segments within each inductive code. For every subcode, we reviewed again the coded segments and identified other subcodes that were overlaid or connected through the interviewee’s language. Subcodes that tended to appear together coalesced into four concepts which became focal points of our analysis: Authority, Empathetic Leadership, Management and Facilitation of Coordination. Authority and Empathetic Leadership are names we gave to groups of subcodes under the ‘Communication preferences’ code. Management and Facilitation of Coordination are two subcodes under the ‘Role/Function’ code. The analysis identified which subcodes under the ‘Job methods, approach and style’ code connect these concepts; that is, the link between communication preferences and job functions. Inductive codes and subcodes that appear in the following analysis are highlighted in Figure 2.

Figure 2.

Selected subcodes included in theme analysis discussion. Many subcodes are common to the examples given in Table 3. Coloured boxes around each topic of codes are consistent with those in subcode maps in the following sections: Precursors are yellow (left), Methods are green (middle) and Purpose codes are purple (bottom right).

Our analysis focussed on codes within the three topics of Precursors, Methods and Purpose. While Context, the fourth topic, is not explicitly present in the analysis, it is pervasive throughout. An example is the use of a systems engineering process as a tool to organize what, how and when work is done: this appears as ‘establish norms and process’ under the ‘Job methods, approach and style’ code. Under the ‘SE Process’ code, not included in this analysis, are the specific kinds of documentation and reviews that comprise the process itself.

We discuss now the central concepts of Authority, Management, Empathetic Leadership and Facilitation of Coordination in turn. For each, we highlight the subcodes relevant to each, drawn from the inductive codes indicated in red in Figure 2. Our analysis focusses on identifying connections between subcodes according to our interviewees’ responses. An example we walk through below in the section on Empathetic Leadership is how Personality and Leadership Traits (extroversion and integrity) impact communication preferences (use of empathy and knowing people, or Empathetic Leadership), which in turn dictate actions such as asking questions and translation as strategies for Facilitation of Coordination and Management. Final themes emerge from the composition of these analyses, which show a dichotomy between authority-driven and empathetic leadership-driven strategies for facilitation of coordination.

9.4.1. Authority

Authority is defined as the ability to give orders and make decisions (Stevenson & Lindberg Reference Stevenson and Lindberg2011). Authority, its enablers and the tasks it is used for as identified from our interviews are shown in Figure 3. Each block in this map represents a subcode. Arrows between subcodes indicate that the attribute or action described by one subcode enables another. Squared boxes in this map indicate specific instantiations of each subcode: for example, instantiations of Authority identified through analysis include technical authority based on recognized technical expertise and positional authority, based on delegated responsibility.

Figure 3.

Map of subcodes related to Authority subcodes, with specific instantiations of ‘Authority’ and ‘Set norms, process, scope and objectives’ subcodes shown in squared boxes. Subcode colours refer to the topic its parent inductive code belongs to (see Figure 2).

9.4.1.1. Technical expertise

Authority comes from assigned responsibility for decision-making, which in turn is supported by experience and technical understanding. As pointed out by one interviewee, technical understanding is essential to effective decision-making: ‘I do not understand how you can be accountable for the decisions you are making if you do not understand the thing you are building, and how it works and what the trades are.’ The benefit of technical knowledge was mentioned by all interviewees, but its importance was emphasized for situations with high technical or programmatic uncertainty, common in LSCES design. Decision-making under uncertainty requires a risk assessment, based on experience: ‘If things feel like [they are] low risk, I do not spend a lot of time looking at them. If they are new, or novel, or something we have not done in a while, then I’ll pay special attention to that.’ In addition to experience, one interviewee pointed out that ‘it helps to have some ... level of domain knowledge’ to estimate technical and programmatic risk.

9.4.1.2. Positional authority

Technical authority to make decisions can be delegated to any member of the organization where experience and technical understanding assists that decision-making. However, we mostly spoke with those in management and leadership roles, whose positional authority enables directing the work and decision-making of others. Direction includes setting the scope and objectives of work (broadly, what work is done) as well as norms and processes for approaching and reporting work (broadly, how work is done). Taken to an extreme, this direction could be considered micromanagement. However, we do not mean to imply poor management, rather, the areas of responsibility and guidance typical for those in a management position. Specific instantiations of norms, process, objectives and scope are shown in Figure 3, and include delegation, action tracking, planning, setting deliverables, calling standing meetings, co-locating groups and using a standard design process.

9.4.1.3. Set norms, process, scope and objectives

Methods such as action tracking and deliverables are used to structure the vast amount of information that the interviewees have coming to them daily, regardless of their role. One interviewee explained how structured deliverables help them stay on top of their group’s work: ‘I need to get this information from everybody so I can understand it so I can make sure it’s all coming together, and I need them to provide it to me in some kind of consistent format, otherwise it takes me too long to digest all of it.’ For some, this consistent format is a bulleted list, others, documents posted to SharePoint and still others use a custom action-tracking document to centralize information about who is working on what tasks and each task’s status.

Planning and establishing a formal design process supports management tasks by enabling tracking how closely actual work adheres to those plans. Plans also support coordination by scheduling concurrent design work. As one interviewee explained, ‘I think just having that process in place that everybody’s bought into and everybody kind of understands and follows, it helps ensure that everybody’s communicating and they are on the same page.’ At the organizations we visited, these design processes – including implementations of systems engineering, lean manufacturing and design review schedules – are an integral part of organizational culture and shape how work is done. While a design process applies to the project as a whole, an individual’s authority allows them to enforce how the process is followed. An example is using standing meetings and co-location to support design work: ‘There are situations where ... somebody [has] the experience [needed to resolve an issue], but it may not be communicated. So what we do to foster that communication is essentially have open-ended discussions, weekly meetings [and] we also try to co-locate teams.’

Authority enables the setting of formal structures of work and standards for accomplishing that work. The management and coordination-facilitation tasks these authority-based actions support are discussed further in the sections below.

9.4.2. Management

Management in the design of LSCES can be both technical, ensuring the right work is done to meet technical requirements, and resource-based, ensuring constraints of time and budget are met. A map of the subcodes related to Management functions is shown in Figure 4. Again, the various instantiations of subcodes are shown in squared boxes. Management is supported by the use of authority to set norms, process, objectives and scope of work, instantiations of which are discussed in the section on Authority. Management tasks are also supported by one’s knowledge of others.

Figure 4.

Map of subcodes related to Management subcodes, with specific instantiations of ‘Set norms, process, scope and objectives’, ‘Tailor interactions’ and ‘Management’ subcodes shown in squared boxes. Subcode colours refer to the topic its parent inductive code belongs to (see Figure 2.)

9.4.2.1. Knowing people

An approach to delegation mentioned by interviewees relies on knowing people well enough that they can delegate tasks knowing how that person will respond to situations. As one interviewee explained: ‘I’ll split my work across ten people. ... I know where my work is delegated to, and I basically self-replicate my principles to them.’ Another frequently mentioned approach to ensuring that the correct work is done is asking questions. One interviewee described one of their roles as an ‘interrogator’, ‘[asking] you as many hard questions as I can to make sure that you are [doing the right work].’ Asking questions of multiple people is also a tactic used to reduce uncertainty: ‘It’s not uncommon for me to ask the same question three times either in different ways, or [of] different people, just to check consistency.’ The actions of asking questions and relying on knowledge and trust in people to ensure work is being done stand in contrast to using authority to set upfront rules and procedures for doing work. Both strategies are used widely by our interviewees to support technical management tasks.

9.4.2.2. Technical leadership

We also found that management tasks support technical leadership. While technical management as we define it here is about ensuring the technically correct work is done to meet requirements, technical leadership is the complementary guiding vision that defines what the resulting system should be. This leadership concept is also about maintaining focus on the end designed system: ‘[E]verybody has to as much as possible consistently implement leadership’s intent. Because everybody cannot be going different directions.’ Interviewees shared common understanding of important system objectives within their industry: performance, safety and weight and used these objectives to guide decision-making and consensus building. When designing large hardware systems, the final physical artefact is out of sight for much of the design process, and perhaps the entirety for designers in remote locations. Maintaining this forward ‘solutions-oriented’ focus was cited as an important part of their job for several of our interviewees: ‘You have to be able to share a vision. ... Being optimistic and solution oriented is so critical. Without that, then the team basically loses confidence.’

9.4.3. Empathetic leadership

We use the term empathetic leadership to describe the tailored, individualized approach to working with and leading or managing people described by several interviewees. A map of the subcodes related to empathetic leadership is shown in Figure 5. These subcodes include personality traits, social skills and the ability to work with people effectively.

Figure 5.

Map of subcodes related to Empathetic Leadership subcode, with specific instantiations of ‘Empathetic Leadership, Social Capital’ and ‘Tailor interactions’ subcodes shown in squared boxes. Subcode colours refer to the topic its parent inductive code belongs to (see Figure 2).

9.4.3.1. Building relationships

One instantiation of empathetic leadership is an emphasis on getting to know people. This way of working with people was described by one interviewee: ‘I spend time knowing people, talking to people, I know what they do outside of work, I know what their interests are, I get to know them, like if they have families and what they are doing, and taking that time – there’s a lot of engineers that will tell you that you do not need to do that, that’s not part of your job. – and I strongly disagree. ... I do not see how you can lead a group of people without seeing that whole human side.’ Acknowledging that people have different needs and different perspectives helps these interviewees to get the most out of their teams and to build trust within the team.

9.4.3.2. Influence

Building individual relationships with people is also helpful for working outside one’s team. As one interviewee expressed, ‘When we say please and thank you and treat each other with respect in that way and we do relationship building, [when] the next project or the next thing comes along, people have a more positive understanding.’ Several interviewees mentioned that many technical challenges benefit from knowing the people who are involved: ‘[U]sually it’s not that we do not know how to do something technically, it’s usually a conflict that’s more at a personal level or it’s an opinion or something like that. ... [Y]ou need to steer towards understanding how individuals operate or their perspectives.’ Maintaining connections and building trust in those relationships also helps to support technical leadership through the development and use of influence. According to our interviewees, influence can support or supplant authority to guide decision-making: ‘[y]our ability to influence the final design is much more dependent upon your personal influence and your personal integrity than it does on your position of authority.’

9.4.3.3. Empathetic leadership

Our synthesis of all interviews suggested an underlying concept that is supported by these actions of building and maintaining connections with others, using empathy to get to know people, building trust in relationships with others and personality traits and values of extroversion, reliability and integrity – all shown on the left side of Figure 5. We call this concept empathetic leadership as explained above. We also note this description evokes the concept of social capital. Social capital is the resource afforded to an individual based on their connections and their ability to navigate those connections (Burt Reference Burt1992; Adler & Kwon Reference Adler and Kwon2002). This connection to social capital is discussed further in the Discussion section.

On the right side of Figure 5 are several actions and behaviours that emerged as supported by empathetic leadership. These actions, such as encouraging others to have empathy, asking questions so that others gain understanding of situations and translating or engaging in sensemaking to help others navigate technical discipline or cultural boundaries, are all supported by the ability and willingness to humanize and tailor reactions with others. These proactive behaviours are valuable for supporting management tasks and delegation as discussed previously but also support the facilitation of coordination by helping others work together productively. Facilitation of coordination and the strategies used to accomplish coordination are discussed more in the following sections.

9.4.4. Facilitation of coordination

According to our interviewees, facilitation of coordination is about ‘[getting] the right information to the right people at the right time so that they can be enabled to [do] what needs to be done.’ We heard from our interviewees several actions they use to facilitate coordination in their daily work. The majority of interviewees mentioned one of their top responsibilities in their position was communication, and in many cases followed closely by ensuring others are communicating. In the design of large and complex systems, communication across disciplines is key due to the inherent interdependencies between parts that are designed by different people and groups, often in different locations and sometimes in different organizations. We found that both setting norms, process, scope and objectives for work (through use of authority) and tailored interactions (through use of empathetic leadership) are used to facilitate coordination. These authority-based and empathetic leadership-based strategies, actions that comprise each strategy and example instantiations of each are shown in Figure 6.

Figure 6.

Map of subcodes related to Facilitation of Coordination subcode, with specific instantiations of ‘Set norms, process, scope and objectives’ and ‘Tailor interactions’ subcodes shown in squared boxes. Subcode colours refer to the topic its parent inductive code belongs to (see Figure 2).

We found that the authority-based actions of calling standing meetings, co-locating teams and the use of a standardized process are complementary to the actions based on empathetic leadership: encouraging others to have empathy, translation and sensemaking and asking questions for others’ understanding. We discuss each pair in turn.

9.4.4.1. Meetings

One oft-used mechanism for ensuring discourse across groups and disciplines is meetings. For some, meetings are where their work gets done: ‘[W]e have so many different design [groups], we have got to get them to talk to each other. ... [T]here are some days I have a half hour that I’m not in the meetings throughout the day. But really that’s how work gets done.’ Meetings can take several forms, but two main functions were apparent from our interviews. One typical purpose of a meeting is to provide awareness of team member’s current status and issues. A second common meeting function is bringing together multiple teams whose work is impacted by a design change to make and agree to that change. In both cases, the meeting is a forum for disseminating information to many parties at once, ensuring all parties receive the same information.

9.4.4.2. Encouraging empathy and asking questions

The success of meetings and their utility depends on what the individuals bring to the table: what makes these meetings go well centers around having the ‘right people’ there. This means people with the right experience and information to contribute to decision-making as well as a clear sense of purpose of what they want to get out of being at a meeting. The effective transfer of information at a meeting, central to coordination, then depends on both having regular meetings and the awareness to make use of the meeting time. Coordination is in part facilitated through asking questions of people to ensure they understand why their meeting participation is important and encouraging them to have some empathy and awareness of how their work impacts others; ‘helping them try and connect the dots’. Empathetic leadership, specifically having empathy and knowing people’s individual strengths and weaknesses, supports these two actions of asking questions and encouraging the use of empathy.

9.4.4.3. Co-location

Another approach used to facilitate coordination is to co-locate people who have related or interdependent work. One interviewee expressed their goal of co-locating a multidisciplinary team is to help them ‘self-integrate, because [then they are] just the people that naturally communicate with each other on a day-to-day basis.’ Another interviewee expressed a similar sentiment that co-location for their team ensures that problems can be solved by walking to a nearby desk: ‘[Y]ou can go to your neighbor or you would go to a guy that you see almost every day who is ... the expert in that discipline or methodology. Or [say] hey, I think that I’ve seen on [someone’s] screen [something] that I’m trying to solve.’

9.4.4.4. Proactivity and translation

In highly interdependent design work, people are likely to have multiple interdependencies across both aspect (discipline) and object (subsystem) partitions. Co-location partitions a group of people based on one kind of dependency. In turn, that group likely has additional dependencies with other individuals who are farther away. Proactively seeking out those more remote interdependencies was identified by our interviewees as important to effective facilitation of coordination: ‘You cannot sit in your office, you have got to go [and] interact with all of these design disciplines. You’ve got to communicate.’ Being able to communicate across discipline and cultural divides, or ‘translate’, is essential. As one interviewee explained, the lack of consistent terminology and language across disciplines can cause miscommunication and ultimately problems that take extra time to resolve. Translating discipline-specific language to something more universally understood is key to ensuring groups work well together. ‘I end up being the translator. I end up being the [person] that says hey wait a minute, I think this is what you just said. Is that right? ... I specifically really try and push enough of a plain language that all of the groups can understand it. ...It’s a hard thing, but that actually is really, really critical.’ Again, empathetic leadership includes building relationships across the organization and knowing individuals and their styles. Proactively seeking out others and translation to develop a common language are central to the coordination strategy based on empathetic leadership.

9.4.4.5. Standard process

Finally, the complexity introduced by the multitude of parts and people involved in LSCES design is often managed through a formal systems engineering or design process. Simply having a process and a standard way of documenting work is not always considered sufficient or the most efficient way to support coordination in all cases, though: ‘[I]t may not be as effective sometimes to just look through a bunch of documentation, and sometimes knowing the right person to ask the informal route [is more effective].’ As mentioned by several interviewees, the ‘real work’ happens prior to documentation being written and approved, and that prior work is where coordination is needed. ‘[I]t takes a lot of communication, because there has to be a level of day to day communication that gets the message across of what’s about to occur, not stacks and stacks of documents and review, but it’s about having that right level of cognisance in that discipline and say, hey we have a design issue that we are having, a challenge meeting our requirements, it looks like we are making a change over here, it’s probably going to affect discipline X and Y, we need to bring them in.’ An individual’s authority gives them the ability to set a design process in place and to mandate certain kinds of documentation. However, the actions and behaviours of proactive interaction with peers, developing a shared understanding of the technical system and knowing the right people to help identify and resolve design problems are part of the empathetic leadership concept introduced previously.

9.4.5. Themes

Tables 4 and 5 summarize quotes from interviewees that focus on the coordination-facilitation strategies implemented in turn, by use of authority and management techniques, and use of empathetic leadership. The authority and management strategies were most often mentioned not only by project managers and senior managers but also by systems engineers, discipline leads and chief engineers. The majority of these positions have direct authority over others, enabling the use of authority to implement processes designed to streamline and simplify communication. The focus on easing communication is key for working in a complex environment: the main driver for standardized processes was ease of understanding for all parties in a situation of very high information volume, and ensuring that as new interactions emerge, they can be assessed and addressed.

Table 4.

Quotes from interviewees that center on the implementation and importance of standardized processes in large-scale and complex engineered system design, drawn from the management and authority subcodes

Table 5.

Quotes from interviewees that center on the implementation and importance of individually tailored processes in large-scale and complex engineered system design, drawn from the empathetic leadership and facilitation of coordination subcodes

The individually tailored processes that are enabled by the empathetic leadership concept were most often described not only by systems engineers and discipline leads but also project managers, chief engineers and an engineer (reflecting on past management experience). Again, the focus is on addressing the inherent complexity of LSCES design tasks, by appealing to individuals one-on-one to help make interfaces tangible for all parties. This includes improve communication across those multiple interfaces and documentation of interfaces, especially important in LSCES design as the number of interfaces increases and interface behaviour may be changeable.

We found the standardized processes supported by use of authority and the individually tailored processes that are supported by use of empathetic leadership served as two broad strategies for the facilitation of coordination in LSCES design projects. In turn, we call the two strategies authority-based and empathetic leadership-based, respectively. The dichotomy of these two coordination-facilitation strategies is illustrated on the composite subcode map as shown in Figure 7. A full subcode map including all previously discussed instantiations is shown in Figure 8.

Figure 7.

Illustration of themes overlaid on full subcode map, illustrating empathetic leadership and social capital as complementary strategies used for facilitation of coordination and management. Subcode colours refer to the topic its parent inductive code belongs to (see Figure 2).

Figure 8.

Full map of all highlighted subcodes, including all specific instantiations mentioned in previous sections. Subcode colours refer to the topic its parent inductive code belongs to (see Figure 2).

The authority-based strategy is comprised of actions to set norms, processes, scope and objectives for technical work and behaviour that relies on the use of authority to get things done. As mentioned in previous sections, these actions are used in support of both management (ensuring the right work is done within organizational constraints) and facilitation of coordination (ensuring that distributed work is being done towards the same goals).

Authority supports actions and behaviours including delegation, planning, co-location of groups and setting and enforcing a standard process. They are enacted through the exercise of authority and shape the system of how work is done within the organization. These authority-based actions bear strong similarity to how coordination is presently described in multiple disciplines: a process prescribed at the outset of work to ensure that information can be communicated across the organization to those working on complementary parts of a larger design problem.

In turn, empathetic leadership enables a strategy that includes actions and behaviours to tailor interactions with others. These actions include building and maintaining a social network of information resources, tailoring interactions with others, encouraging others to have empathy in interactions and asking questions to support a common understanding of what work is being done and how it fits together. These actions and behaviours help to ensure information is shared and meaningfully translated between disciplines and to assist sensemaking (Weick, Sutcliffe & Obstfeld Reference Weick, Sutcliffe and Obstfeld2005) in order to facilitate the coordination of diverse technical tasks. Again, as mentioned in previous sections, these actions are used by our interviewees in support of both management and facilitation of coordination.

The two themes that emerged from our analysis comprise what appear as complementary strategies for the facilitation of coordination work. Both strategies appear to be necessary in the design of LSCES due to the complexity involved: the authority-based strategy is used to simplify and standardize processes and make sense of the scale of technical information. Meanwhile the empathetic leadership-based strategy is used to aid the navigation of technical interdependencies and to come to common understanding of technical uncertainty and unpredictability. These strategies differ in terms of their enabling preferences (use of authority or use of empathetic leadership), or the resultant actions and behaviours (centered on plans and procedures, or centered on tailored one-on-one interactions). While multiple terms could be used to describe each strategy, we choose to call these strategies Passive and Active. The first strategy for facilitation of coordination we call Passive due to its top-down implementation through the use of authority. The second strategy we call Active, distinguished by the proactive behaviour interviewees mentioned repeatedly as helpful. Knowing when to ‘jump in’ and get involved and taking the time to tailor interactions with each person they talk to both require going above and beyond the minimum required for a given task. The denotation of the authority-based actions and behaviours as Passive is not meant to belittle the work that goes into these tasks but rather serve as contrast to the extra proactivity requisite for the Active strategy.