Skip to main content Accessibility help
×
Home
Hostname: page-component-56f9d74cfd-s5lbf Total loading time: 1.343 Render date: 2022-06-27T00:41:52.863Z Has data issue: true Feature Flags: { "shouldUseShareProductTool": true, "shouldUseHypothesis": true, "isUnsiloEnabled": true, "useRatesEcommerce": false, "useNewApi": true }

On the use of coordination strategies in complex engineered system design projects

Published online by Cambridge University Press:  04 December 2020

Arianne X. Collopy*
Affiliation:
Division of Integrative Systems + Design, University of Michigan, Ann Arbor, MI, USA
Eytan Adar
Affiliation:
School of Information, University of Michigan, Ann Arbor, MI, USA
Panos Y. Papalambros
Affiliation:
Department of Mechanical Engineering, University of Michigan, Ann Arbor, MI, USA
*
Corresponding author A. X. Collopy acollopy@umich.edu

Abstract

Coordination of distributed design work is an important activity in large-scale and complex engineered systems (LSCES) design projects. Coordination strategies have been studied formally in system design optimization and organizational science. This article reports on a study to identify what strategies are used in coordination practice. While the literature primarily offers prescriptive coordination strategies, this study focussed on the contribution of individuals’ behaviours to system-level coordination. Thus, a coordination strategy is seen as a particular set of individual actions and behaviours. We interviewed professionals with expertise in systems engineering, project management and technical leadership at two large aerospace design organizations. Through qualitative thematic analysis, we identified two strategies used to facilitate coordination. The first we call authority-based and is enabled by technical know-how and the use of organizational authority; the second we call empathetic leadership and includes interpersonal skills, leadership traits and empathy. These strategies emerged as complementary and, together, enabled individuals to coordinate complex design tasks. We found that skills identified in competency models enable these coordination strategies, which in turn support management of interdependent work in the organization. Studying the role of individuals contributes an expanded view on how coordination facilitates LSCES design practice.

Type
Research Article
Creative Commons
Creative Common License - CCCreative Common License - BYCreative Common License - NCCreative Common License - ND
This is an Open Access article, distributed under the terms of the Creative Commons Attribution-NonCommercial-NoDerivatives licence (http://creativecommons.org/licenses/by-nc-nd/4.0/), which permits non-commercial re-use, distribution, and reproduction in any medium, provided the original work is unaltered and is properly cited. The written permission of Cambridge University Press must be obtained for commercial re-use or in order to create a derivative work.
Copyright
© The Author(s), 2020. Published by Cambridge University Press

1. Introduction

Large-scale and complex engineered systems (LSCES) are comprised of thousands of parts and designed by hundreds or thousands of engineers. Partitioning is the process of decomposing the design of a system into smaller manageable portions. Each portion, allocated to an individual or group, then requires coordination: ensuring interfacing groups are working with consistent data, consistent interpretations of that data and consistent goals. The objective of coordination is assurance that, when partitioned work is recombined, the recomposed system is equivalent to the original system design that would have been achieved without partitioning (Blanchard & Fabrycky Reference Blanchard and Fabrycky2011; Papalambros & Wilde Reference Papalambros and Wilde2017).

This system-level coordination is challenging both technically and socially. Many interdependent functions required of the system and unpredictable mappings between an individual subsystem’s behaviour and the system behaviour yields technical complexity (Bloebaum & McGowan Reference Bloebaum and McGowan2012; Madni & Sievers Reference Madni and Sievers2014). The social system of a manufacturing or design organization also produces complexity, partly due to evolving understanding of the system and its interactions as it is developed (Bloebaum & McGowan Reference Bloebaum and McGowan2012; Page Reference Page2015). Coordination also requires different disciplines to work together effectively (Sage & Lynch Reference Sage and Lynch1998; Madni & Sievers Reference Madni and Sievers2014) and to share information between the tasks of analysis, design and test (Johnson Reference Johnson1997; Blanchard and Fabrycky, Reference Blanchard and Fabrycky2011).

LSCES design is a naturally multiobjective optimization problem due to many competing objectives. Competing objectives may be functional ones related to desired performance and lifecycle ones related to how the system operates, such as safety, maintainability, durability and other ‘ilities’ (de Weck, Roos & Magee Reference de Weck, Roos and Magee2011). This inherent mutiobjective nature of LSCES design can be addressed in the standard ways of combining them into a scalar substitute function (Papalambros & Wilde Reference Papalambros and Wilde2017) using, for example, a weighting scheme. Alternatively, a single system objective function can be constructed at the enterprise level. Enterprise metrics such as profit or net present value implicitly contain the competing desires of performance and ‘ilities’ (see, e.g., Cooper & Papalambros (Reference Cooper and Papalambros2003)). Modelling such single objectives goes beyond engineering models and includes marketing and finance models (see, e.g., Michalek et al. (Reference Michalek, Ebbes, Adigüzel, Feinberg and Papalambros2011)). In either case of scalarizing the original multiobjective problem, we refer to this single objective as the ‘overall system objective’ throughout. Identifying this overall system objective, ensuring all parties understand this objective the same way and facilitating work to achieve it are well-studied system management problems and constitute key components of coordination in LSCES design (see e.g., Crawley et al. (Reference Crawley, de Weck, Eppinger, Magee, Moses, Seering, Schindall, Wallace and Whitney2004)).

Coordination is often entangled with related concepts. McGowan (Reference McGowan2014) distinguished between four types of interactions that occur across organizational and technical interfaces during system design: Connecting is akin to the assembly of parts. Connected items work together but are designed and developed separately. Collaboration is a process of bringing together heterogeneous parts to form an integrated system. Ownership of the parts remains distinct, but individuals and the artefacts they design are tailored to facilitate integration. Collective design is even more collaborative; the result is a fully homogeneous and co-created artefact that results from shared and integrated expertise. Finally, Coordination is described as a process of ensuring diverse system elements remain integrable as they evolve and ensuring that the system-level needs can be met as the component parts are defined. Coordination is described as negotiation or orchestration among constituent parts and people (Ryschkewitsch, Schaible & Larson Reference Ryschkewitsch, Schaible and Larson2009; McGowan Reference McGowan2014).

We mention these distinctions between coordination, collaboration, connecting and collective work because these terms are often used interchangeably. The processes as described by McGowan are similar, and even complementary, but are ultimately distinct. The focus of the present study is coordination in LSCES design, which is differentiated by the focus on an overall system objective.

Literature on coordination spans several disciplines including multidisciplinary design optimization (MDO), organization science, engineering design, software engineering and systems engineering. Each discipline looks at system design from a different angle: MDO, the analytical formulation and solution of system design problems; organization science, the structure and nature of organizations engaged in system design work and engineering design, software engineering and systems engineering, the development of software and hardware systems alongside methods and tools to support that design. The review of the literature drawn from each discipline is intended to highlight the juxtaposition between top-down coordination processes and coordination processes that are tailored to individual behaviour. The scope of disciplines is not intended to be exhaustive.

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:

What behaviours and actions do individuals use to facilitate system-level coordination of distributed design work?

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.

8. Methodology

To address the question of how coordination in LSCES design is carried out in practice, we developed a semistructured interview protocol. Semistructured interviews consist of a priori questions to guide the general discussion but are open-ended to allow for fluid conversation and exploration of unexpected topics that may arise (Given Reference Given2008). The interview protocol was designed to elicit individuals’ skills and behaviours used as part of LSCES design work. The focus on the individual led us to narrow the questioning to look at communicative and cognitive skills and behaviours. Questions in the protocol progress from general to specific, setting a basic understanding of an individual’s job and typical functions before discussing how they complete those functions. Of particular focus were job functions that pertain to partitioning and coordination processes during system design. Examples include determining work breakdowns, delegation as well as the need to recombine and make sense of distributed information. Questions centered on strategies for partitioning and coordination tasks that are both communicative (e.g., How would you characterize interactions between groups you work with regularly? What are typical communication methods used within the organization and what works best for you?) and cognitive (e.g., Was there any stage during the system design process in which you found it difficult to process and integrate the information available?). The full interview protocol is included in the Appendix.

We interviewed 20 professional engineers, managers and systems engineers at two large aerospace design and manufacturing organizations as part of this study. Interviewees were selected by their organizations as representative of expertise in a range of positions within the organization. Interviewees were also selected as representative of exemplar systems engineering practice within the organization, meaning that their coordination strategies are not necessarily shared by all members of the organization. The study examined what were considered best practices.

All interviewees had experience in systems engineering, leadership and/or management positions, and 19 of 20 interviewees were in those positions at the time they were interviewed. Interviewees were asked to reflect on their previous project work. In all cases, these were situations where the interviewee was in a leadership, systems or management role. Our sample is biased, as this does not reflect the typical depth of engineering organizations. Meanwhile, the gender diversity of interviewees is roughly consistent with national trends: 3 of 20 interviewees (15%) were women, slightly higher than the 9–10% typical of mechanical and aerospace engineering workforce in the United States in 2015 (National Science Board 2018).

Though the organizations whose employees we interviewed are quite large, we found that similar concepts arose frequently across the 10 interviews conducted at each site and across all interviews regardless of site. Therefore, we perceived saturation of concepts within the topics we included in our questionnaire. These concepts formed the basis for the definitions of each deductive code used in our first step of analysis.

The two organizations were selected due to their common features: a matrix organized structure, engaged in the design and manufacture of large and complex systems in a highly regulated industry (here, aerospace engineering), employing more than 5000 employees across multiple offices, and having a systems engineering process in place. At each organization, interviewees were selected from a single office site, chosen by its accessibility to the authors. These organizations partition their system design work both by aspect into disciplines and by object into subsystems (Papalambros & Wilde Reference Papalambros and Wilde2017). This dual partitioning is realized as a matrix organization structure, with management and leadership roles overseeing both the discipline analysis work (aspect partitions) and the technical subsystem design work (object partitions). We refer to the design and manufacturing work to develop and produce a single system as a project.

We grouped the actual titles of our interviewees into six general titles to preserve anonymity: Engineer, Discipline Lead, Chief Engineer, Project Manager, Systems Engineer and Senior Manager. Engineer reflects a nonmanagement position that supports a single discipline or subsystem within a single project. Discipline Lead and Project Manager titles refer to leadership and management positions for a single project, overseeing a single aspect or object partition, respectively. Chief Engineer and Systems Engineer titles are also positions for a single project, overseeing both dimensions of partitioning for a subsystem or system. Those with Systems Engineer titles tended to be responsible for interfaces between system partitions throughout project work, while those with Chief Engineer titles tended to be responsible for the success of the project overall. The Senior Manager title refers to management and leadership positions whose scope extends to multiple projects. Table 1 presents a summary of interviewee demographics including current titles and years of industry experience. This summary gives an idea of the types of people we interviewed, noting that the exact function expected of an individual with any given title may vary, and may differ between organizations.

Table 1. Summary of interviewee demographics based on title and years of industry experience

The main analysis goal was to identify and describe coordination strategies used in practice, using our interviews for an exploratory study. Thematic analysis is well suited for this exploration as it identifies emergent concepts or themes from the aggregate analysis of data (Patton Reference Patton2015). Our thematic analysis approach followed the methodology outlined by Braun & Clarke (Reference Braun and Clarke2006). Implementation consisted of five steps:

  1. 1. Prepare data for analysis by transcription of audio recordings.

  2. 2. Deductive coding based on initial broad categories of interest derived from original research question.

  3. 3. Inductive coding of the segments coded in step 2 to organize emergent ideas.

  4. 4. Identification of themes from review of inductive codes and their interrelationships.

  5. 5. Reflection and review of themes to ensure they are characteristic of entire interview corpus.

Our stated methodology differs from that in Braun & Clarke (Reference Braun and Clarke2006) in that we separated our initial coding process into two steps, and our search, review and naming of themes were combined within the theme identification step. The findings at each step of our analysis are presented in the following section.

9. Thematic analysis

9.1. Data preparation

To prepare interview data for analysis, we created verbatim transcripts of raw audio files. Our transcription focussed foremost on recording words accurately. We then also added punctuation according to pauses and emphasis in interviewees’ speech. Following transcription, the raw transcripts were anonymized. Qualitative coding assistants prepared for analysis by reviewing the organizations’ structures, the products they design and manufacture, their design processes and notes from interviews regarding general impressions of the work environment. This served to provide the coders who did not participate in interviews – two of three total coders – with context for their review of interview data.

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.

9.5. Reflection

The previous conclusions are drawn from the analysis of inductive codes in turn drawn from a subset of the original data. As a final step in our thematic analysis, we reviewed the entire interview corpus to draw out a description of each theme reflective of the full dataset.

Our thematic analysis suggests the existence of two archetypical strategies, or sets of behaviours, based on the use of authority or empathetic leadership to accomplish management and the facilitation of coordination in LSCES design work. Referring to Figures 7 and 8, the passive archetype describes individuals who use their authority to dictate what tasks are to be done (e.g., delegation), standards for task reporting (e.g., documentation standards), plans for work completion (e.g., through project management), the process by which work is completed (e.g., a design process) and the environment in which work is done (e.g., location of teams).

The active archetype describes individuals who are extroverted, proactive and reliable, which allows them to build and maintain a robust social network and to use it to access information. By using empathy in interactions with others, these individuals tailor their interactions to support coordination. This includes encouraging the use of empathy and systems awareness (e.g., through mentorship and coaching), translating information to bridge discipline and cultural boundaries, creating a positive and collaborative work environment and asking questions to ensure a common understanding of work and its purpose.

Archetypes are stereotypes of behaviour, and thus purely active and purely passive behavioural archetypes are not likely to match the behaviour of any one individual all the time. Most of our interviewees are best described by a combination of both archetypes, using both Active and Passive strategies, or a combination, as they believe the situation merits.

10. Discussion

Our qualitative analysis identified two different sets of actions and behaviours used to facilitating coordination, which we call Passive and Active. We focus on two main findings from our analysis: the concept of empathetic leadership and related concepts in literature, as well as the juxtaposition of Passive and Active coordination strategies.

10.1. Active facilitation of coordination

The literature on coordination emphasizes the use of standards for documentation and work processes, clearly partitioned work assignments and lines of communication, schedules and meetings for the effective coordination of complex tasks (March & Simon Reference March and Simon1958; Thompson Reference Thompson1967; Van de Ven et al. Reference Van de Ven, Delbecq and Koenig1976; Tushman Reference Tushman1979; Malone & Crowston Reference Malone and Crowston1994; Herbsleb & Mockus Reference Herbsleb and Mockus2003; Sosa, Eppinger & Rowles Reference Sosa, Eppinger and Rowles2003; de Souza et al. Reference de Souza, Redmiles, Cheng, Millen and Patterson2004; Cataldo, Herbsleb & Carley Reference Cataldo, Herbsleb and Carley2008). This emphasis is fairly consistent across disciplines and aligns clearly with the passive strategy for facilitation of coordination we found in our analysis.

The individual-level behaviours and actions included in the Active strategy for facilitation of coordination relate to behaviours emphasized in literature, including but not limited to concepts of informal organizational behaviour: tailored processes to accommodate variance in individual behaviour (Hajela et al. Reference Hajela, Bloebaum and Sobieszczanski-Sobieski1990; Alyaqout et al. Reference Alyaqout, Peters, Papalambros and Ulsoy2011), the existence and need to account for multiple preferences and incentives (Vermillion & Malak Reference Vermillion and Malak2015; Bhatia, Mesmer & Weger Reference Bhatia, Mesmer and Weger2018; Grogan et al. Reference Grogan, Ho, Golkar and de Weck2018; Meluso & Austin-Breneman Reference Meluso and Austin-Breneman2018), use of social capital (Adler & Kwon Reference Adler and Kwon2002; Larsson Reference Larsson2007; Agneessens & Wittek Reference Agneessens and Wittek2012), brokerage and working across organizational boundaries (Sosa, Eppinger & Rowles Reference Sosa, Eppinger and Rowles2004; Burt & Merluzzi Reference Burt and Merluzzi2014;Obstfeld, Borgatti & Davis Reference Obstfeld, Borgatti and Davis2014) and positive leadership (Baker, Cross & Wooten Reference Baker, Cross and Wooten2003; Terrasi Reference Terrasi2015). It is natural that the findings from our questioning, focussed on individuals’ cognitive and communicative actions and behaviours, might correspond to informal processes studied in organizations. However, the context of the Active theme and associated behaviours is specific to the coordination of technical tasks during LSCES design. The behaviours that comprise the Active coordination-facilitation strategy are used to improve the quality of connections, communication and technical understanding throughout the design process. The intent is to allow complex tasks and their dependencies across many interfaces to be understood and acted on effectively to achieve a common system goal.

There is also some overlap between the Active theme we identified and the skills identified in systems engineering and project management competency models. Extroversion or proactive communication, leadership abilities and the ability to collaborate and communicate across diverse groups are included in several competency and behavioural models of systems engineering practice (Williams & Derro Reference Williams and Derro2008; Hutchison, Henry & Pyster Reference Hutchison, Henry and Pyster2016). These skills and behaviours are reflected in the Precursors topic of our inductive code, those that we found to support empathetic leadership. Our analysis connects these skills and empathetic leadership to the facilitation of coordination through proactive and tailored communication. We thus show a link between skills and behaviours identified of successful systems engineers and tasks they may be engaged in, particularly the facilitation of coordination.

Overlap between concepts of systems thinking, social capital, brokerage and positive leadership in sociology and organizational literature, skills like empathy, leadership and communication in existing competency models and the actions that comprise our identified Active coordination strategy suggests three things. The first is that empathetic leadership may serve as an encompassing term to bring these various ideas together to describe the informal processes happening in large organizations in support of coordination. Second, as coordination is one major task for which these skills are used in practice, we may consider in turn coordination to be a central component of systems engineering practice in which more individuals are engaged than just those with the title of ‘systems engineer’. Finally, existing social science theories can help to understand better the connection between the concept of empathetic leadership and facilitation of coordination.

10.2. Relationship between active and passive themes

Through our analysis, we identified Active and Passive strategies used to facilitate coordination. The discussion above suggests that the ‘active’ actions and behaviours we identified are similar to informal organizational processes, whereas the ‘passive’ actions and behaviours we identified are similar to formal organizational processes. This dichotomy suggests that the two sets of coordination strategies are related, in the sense that ‘passive’ or ‘formal’ approaches establish a structure or culture of work, and ‘active’ or ‘informal’ approaches are used to work within and across that structure. A similar comparison can be made to different perspectives one can take to guide management decisions, for example, the strategic, cultural and political lenses described by Ancona et al. (Reference Ancona, Kochan, Sculley, Van Maanen and Westney2004). However, the focus of the coordination-facilitation strategies here is the coordination of technical tasks during LSCES design, all tasks contributing to a single shared artefact. In addition, more than being complementary strategies, the impacts of complexity in LSCES design suggest the need for using both Active and Passive coordination-facilitation strategies. Parallels may also be drawn to a handful of other dualities: strategies to set long-term goals and tactics to accomplish near-term objectives, design of an artefact and control to determine its behaviour, and partitioning to divide a problem and coordination to solve it. The nature of each of these pairs is that they are intricately linked parts of the same problem. This has been illustrated for partitioning and coordination decisions (Allison, Kokkolaras & Papalambros Reference Allison, Kokkolaras and Papalambros2009), design and control decisions (Reyer & Papalambros Reference Reyer and Papalambros2002), formal and informal organization (McEvily, Soda & Tortoriello Reference McEvily, Soda and Tortoriello2014) and strategy and tactics selection (Mackay & Zundel Reference Mackay and Zundel2017), to name a few. Generally, making decisions about one without consideration of the other leads to a poorly performing or, at worst, infeasible system design. What this suggests for our findings is that the Passive and Active coordination strategies should be considered together when making decisions about how to best facilitate the coordination of distributed work.

Some ideas for how to consider Active and Passive coordination strategies together come from studies focussed on unexpected challenges in collaborative work. Modularization relies on clearly defined tasks in order to partition work cleanly and to reduce the need for coordination. However, this focus on clean partitions can result in challenges putting the results of those tasks back together. Even if tasks are defined so that the results should be easy to integrate, the awareness of how the parts combine to operate as a whole can be lost (de Souza et al. Reference de Souza, Redmiles, Cheng, Millen and Patterson2004; Grubb & Begel Reference Grubb and Begel2012). Similarly, the use of a standard process or set of rules is better able to support coordination if the individuals whose work is to be coordinated are bought into the efficacy and purpose of the process (Espinosa, Armour & Boh Reference Espinosa, Armour and Boh2010). Recommended resolutions to these apparent challenges with the Passive strategy for facilitating coordination focus on increasing communication and awareness of parallel work (Herbsleb & Mockus Reference Herbsleb and Mockus2003; Espinosa, Armour & Boh Reference Espinosa, Armour and Boh2010).

There are also evident challenges in executing the Active strategy. In highly interdependent system development, the logic that all pairs of individuals with interdependent tasks should be communicating regularly becomes infeasible (Brooks Reference Brooks1995). In an organization of several thousand or more individuals, it is difficult to develop a robust social network that spans a significant portion of those individuals. Relying on individuals to coordinate their own work faces challenges from the difficulty of communicating across divisional boundaries (Sosa, Eppinger & Rowles Reference Sosa, Eppinger and Rowles2003; Dossick & Neff Reference Dossick and Neff2010) and identifying and accessing relevant information out of a large possible set (Salzberg & Watkins Reference Salzberg and Watkins1990). To address these challenges, defining formal coordinator roles is often recommended (Strode et al. Reference Strode, Huff, Hope and Link2012; Parraguez, Eppinger & Maier Reference Parraguez, Eppinger and Parrag2016; Poleacovschi & Javernick-Will Reference Poleacovschi and Javernick-Will2016). Formal roles come with authority, thus enabling the Passive coordination-facilitation strategy.

The Active and Passive strategies for facilitating coordination both have benefits and drawbacks. The review of literature presented here suggests drawbacks from one set of actions may be mitigated by use of the other set of actions. Following from this, and the observation that our interviewees made use of both strategies, we hypothesize that a balance between Active and Passive actions and behaviours for the facilitation of coordination is needed in LSCES design. These projects require many individuals with high technical skill in order to design and develop a system. The large organization benefits from Passive coordination strategies to unify standards of doing work, while also benefiting from empathetic leaders who use Active coordination strategies to leverage extensive networks across the organization. Together, the Passive and Active strategies are used to mitigate many of the challenges of LSCES design tasks: high interdependence, changeability, uncertainty and ambiguity. Lower complexity (e.g., lower interdependence, lower changeability, lower uncertainty or lower ambiguity) may mean that less use of both Passive and Active strategies is expected. Both Active and Passive strategies address easing the communication, information sharing and workflow challenges associated with complex tasks. Less use of the Passive strategy means setting and using formal structures such as setting norms, process, scope and objectives. Less use of the Active structure means less time taken to exercise empathetic leadership, tailoring interactions with individuals to help facilitate necessary coordination. Whether an individual chooses to adopt more or less of either approach identified here is an individual choice. An individual may use either strategy or a combination. In this study, technical managers, discipline leaders, project managers and systems engineers all made use of some combination of these strategies in order to facilitate coordination.

11. Conclusions

The results of this exploratory qualitative study are the identification of two strategies – sets of actions and behaviours – used by practitioners to facilitate the coordination of distributed design work. Through thematic analysis, we found evidence of authority-based and empathetic leadership strategies, and that individuals engaged in LSCES design projects make use of both strategies to address complexity. The former strategy we called Passive, and the latter strategy Active, due to the relative proactivity required for each approach. The Passive approach was more frequently emphasized by project managers and senior managers, and the Active approach more frequently emphasized by systems engineers. However, all interviewees recognized the importance of elements of both strategies in facilitating coordination during LSCES design projects. This gives a qualitative illustration of the necessary balance between the different coordination strategies. A more detailed or quantitative description of the balance is left as future work.

The findings from this study are expected to be analytically generalizable (Yin Reference Yin2003) to organizations with similar characteristics to those visited as part of this study. These organizations are matrix-organized, engaged in the design and manufacture of large and complex systems in a highly regulated industry, employ more than 5000 employees across multiple offices and have a systems engineering process in place.

Passive actions and behaviours are supported by the use of authority to enforce what work is done and how it is done through formal delegation, setting standardized documentation and deliverables, a common design process, developing plans and project management and co-locating groups with interdependent tasks. These actions provide common norms of how work is to be done with the expectation that this environment enhances coordination. Active actions and behaviours are supported by a concept we call empathetic leadership, a proactive approach to developing and maintaining a diverse social network across the organization. The ability to develop these connections is used to tailor communications to successfully share technical information across discipline and cultural boundaries, to ask deep questions to help oneself and others develop a common understanding of work to be done and how it fits together and to encourage others to use empathy in their own interactions to facilitate effective collaboration. Identification of these two strategies presents a new way to look at coordination in LSCES design. Our findings suggest that implementing and enforcing a systems engineering process (a Passive action) is complemented by the actions and behaviours of systems engineers and managers above and beyond that process (Active actions), both in support of successful coordination. Further, individuals in many positions are able to contribute to coordination, whether setting a coordination strategy or through their individual behaviours and actions. While the interviewees in this study were primarily in management, leadership and systems engineering roles, the coordination strategies require buy-in and adoption throughout the organization to be effective. Therefore, we believe these strategies are of use to individuals at multiple levels of an organization, engaged in LSCES design. As individual behaviour also applies to analytical problems in design optimization, for example, these active and passive coordination-facilitation strategies may also be applied to improve algorithms in other domains.

The Passive strategy we identified is consistent with existing literature on coordination in MDO, organization science, and software and engineering design. This literature tends to describe coordination as a preconceived set of processes meant to address the uncertainty and interdependence between diverse tasks that support a common goal. Empathetic leadership and the actions and behaviour that comprise the Active coordination strategy we identified are similar to concepts in organizational sociology. Related concepts include the use of social capital, brokerage, systems thinking and positive leadership. The precursors we identified as associated with the Active facilitation of coordination, including extroversion and leadership traits, are consistent with skills and behaviours found in systems engineering competency models. Together these findings suggest that coordination is a central task of systems engineers and systems engineering, and concepts in social science such as brokerage, social capital and positive leadership are likely to contribute to the further development of systems engineering theory and best practice.

This work has several limitations. The study purposely focussed on experts in systems engineering, management and leadership roles. Follow-up interviews or surveys are recommended to ensure the validity of findings across all levels of the organization. Extension to companies based in other countries or in other industry sectors requires additional study. Finally, validation as to the quality of the design outcome with respect to the coordination strategies used is lacking.

In this study, we did not aim to develop a full theory of coordination; rather, we sought to develop hypotheses for further exploration. The findings here are supported by existing literature across several relevant domains, suggesting that the identified Active and Passive strategies for facilitating coordination in LSCES design projects are representative of important organizational processes. Based on our findings, we hypothesize that Active and Passive actions and behaviours used to facilitate coordination are interrelated and that there exists a balance between them in practice. Future work should aim to identify this balance point and explore what environmental parameters [e.g., group size and degree of interconnectedness between teams as in Tushman (Reference Tushman1979) and design activity as in Strode et al. (Reference Strode, Huff, Hope and Link2012)] and behaviours (e.g., Active and Passive) impact the balance point and the performance outcome of the designed system.

Additionally, the selection of a coordination strategy has been shown to be dependent on a given partitioning or task division (Sosa, Eppinger & Rowles Reference Sosa, Eppinger and Rowles2004; Rivkin & Siggelkow Reference Rivkin and Siggelkow2007; Allison, Kokkolaras & Papalambros Reference Allison, Kokkolaras and Papalambros2009; Vrolijk & Szajnfarber Reference Vrolijk and Szajnfarber2015). A second direction of future work is to examine how coordination strategies, or the balance between strategies, change with different organizational partitionings. A third direction for future work includes investigating the applicability of the coordination strategies identified in this work to projects partitioned among multiple firms [as in Gulati & Singh (Reference Gulati and Singh1998); Helper et al. (Reference Helper, MacDuffie and Sabel2000); Baldwin (Reference Baldwin2007); Baldwin (Reference Baldwin2012); Luo et al. (Reference Luo, Baldwin, Whitney and Magee2012); Jacobides, MacDuffie & Tae (Reference Jacobides, MacDuffie and Tae2016)] and how these coordination-facilitation strategies apply to an organization’s outward behaviour.

Acknowledgments

The authors would like to thank Michael Watson of NASA Marshall Space Flight Center for his sustained enthusiastic support and advice provided during this study; Melissa Greene for contributions in interview protocol development and conducting interviews; Tianyi Liu for assistance in interview transcription; and Vanessa Rychlinski and Rugved Arte for their qualitative coding work and contributions to thematic analysis – all of the Optimal Design Laboratory at the University of Michigan.

Financial support

This work was partially supported by a University of Michigan Rackham Graduate School Merit Fellowship, and by the NASA Systems Engineering Research Consortium, headquartered at the University of Alabama-Huntsville (grant number NNM11AA01A, subcontract 2015-059-A6). This support is gratefully acknowledged.

A. Appendix

The interview protocol used in this study is reproduced below.

Please consider your first-hand experiences with designing and maintaining a large-scale, complex engineered system.

  1. 1. Please describe a specific project in which you participated in the design and management of a complex system. Can you sketch the technical system? Using this sketch, can you tell me which groups work on which parts of the technical system? How many engineers were involved in the project? How many engineers were in each group you drew in the sketch? Where was each group physically located?

  2. 2. Where do you work? What is your formal title? How many years of work experience do you have? For this project, can you describe your typical work day? In a typical week, what are the top 3–5 tasks you spend/spent the most time on? What would you say has contributed most to your ability to do these tasks effectively? Formal education, on the job experience, mentoring or something else? Could you elaborate? (Who is your mentor? When do you switch?)

  3. 3. What was your role in the project? Did your responsibilities change throughout the design of this system? Can you indicate which subsystem(s) you worked on and their relationship to the other systems in the project? How would you characterize your work on these subsystems (design, interface management, analysis and something else)? Which of the groups you indicated did you feel you ‘belonged’ to?

  4. 4. How did you arrive at this partitioning (in the sketch)? Is there a typical partitioning common to your organization or is each project broken down differently? Can you describe it? Is this partitioning reflected in the structure of your organization? Who (what title) is responsible for deciding how the work gets done/what the subsystems are? Can you describe how these decisions are made? How are the design teams selected? Are you directly involved in making these decisions?

    1. a. (If participant makes partitioning decisions): Generally speaking, what heuristics or processes did you use to decide how to distribute the technical work for this project? At what stage did you finalize this breakdown? Is this consistent with the original work breakdown structure for the project? What information did you have available to you at the time you were making decisions about how to distribute the technical work for this project? (Within groups and within organization?) Did you use all of the information available to you when making decisions about how best to distribute the work?

    2. b. (If participant does not make partitioning decisions): How was this work breakdown structure presented or communicated to you? Who delivered it to you? Is this consistent with the original work breakdown structure for the project? Do you feel that this was the best way to break down the project/distribute the work? To communicate the project structure? Why or why not? Would you have broken things down differently? How? Why? Would you have communicated this information differently?

  5. 5. Going back to your sketch, which groups you indicated often found your work relevant to theirs? Which groups in the sketches rarely found your work relevant? How did you know? Did you work with these groups frequently (e.g., several times per week)? Infrequently (e.g., a few times per month)? How would you characterize your interactions with these groups, for example requesting information, or providing information? Would you characterize these interactions as primarily formal or informal? Did you routinely anticipate any requests for information from other groups or the need to provide information to other groups? How do you work this into your personal process?

  6. 6. What methods of communication does your organization use (email, meetings, face-to-face, documents, coffee breaks and other)? What roles do each of these communication methods have? Can you compare them? How could these communication channels be improved? Is there a common technology or software that you use to keep track of documentation or host meetings? Do you feel that this technology or software is useful/ effective? Why/why not? Is there something you would do differently, or another tool that you would use?

  7. 7. How do/did subsystems interface throughout the design process (early conceptual stages through to final design)? Was this different during different stages of design? In what way? Is there a single person or group with which all subsystems regularly communicated? What is the role of direct communication between groups as compared to communication with this central individual/group? Do these interactions tend to be through scheduled meetings or informal conversation? Something else?

  8. 8. At what stage in the design process do systems engineers attempt to coordinate the design of the subsystems? Can you describe how this was done in this project? Who was involved? Did the coordination change over time? What information was available to the systems engineer in each of these cases? How was this information presented to the systems engineer? Was this information presented to design groups?

  9. 9. At any stage in system design or subsystem coordination, were you uncertain about either the reliability or the relevance of the information that you had available? Can you elaborate? At any stage, were you uncertain about the appropriateness of the decisions you made based on this information? How did you handle this situation?

  10. 10. Was there any stage during the system design process in which you found it difficult to process and integrate the information available? Describe precisely the nature of the situation.

  11. 11. Were you reminded of similar experiences/projects at any point during your work on this project? Were you at any point reminded of different experiences/projects? Were you at any point reminded of a project that succeeded? Were you at any point reminded of a project that failed? Did these experiences affect the decisions you made or actions that you took? How? Who refers relevant lessons learned?

  12. 12. Do you think that you could develop a rule, based on your experience, which could assist another person to make the same design decisions successfully? Why/why not? What advice would you give to someone new to the role you had on this project?

  13. 13. Is there anything we might have missed? Do you have any other thoughts about systems design that you would like to share?

References

Adler, P. S. & Kwon, S.-W. 2002 Social capital: prospects for a new concept. Acad. Manage. Rev. 27 (1), 17.CrossRefGoogle Scholar
Adner, R. & Kapoor, R. 2010 Value creation in innovation ecosystems: how the structure of technological interdependence affects firm performance in new technology generations. Strateg. Manag. J. 31 (3), 306333.Google Scholar
Agneessens, F. & Wittek, R. 2012 Where do intra-organizational advice relations come from? The role of informal status and social capital in social exchange. Soc. Networks 34 (3), 333345.CrossRefGoogle Scholar
Alexandrov, N. M. & Lewis, R. M. 2002 Analytical and computational aspects of collaborative optimization for multidisciplinary design. AIAA J. 40 (2), 301309.CrossRefGoogle Scholar
Allison, J. T., Kokkolaras, M. & Papalambros, P. Y. 2009 Optimal partitioning and coordination decisions in decomposition-based design optimization. J. Mech. Des. 131 (8), 081008–081008-8.Google Scholar
Alyaqout, S. F., Peters, D. L., Papalambros, P. Y. & Ulsoy, A. G. 2011 Generalized coupling management in complex engineering systems optimization. J. Mech. Des. 133 (9), 091005091005.Google Scholar
Ancona, D. G., Kochan, T. A., Sculley, M., Van Maanen, J. & Westney, D. E. 2004 Managing for the Future: Organizational Behavior and Processes (3rd ed.). Cengage.Google Scholar
Asikoglu, O. & Simpson, T. 2012 A new method for evaluating design dependencies in product architectures. In 12th AIAA Aviation Technology, Integration, and Operations (ATIO) Conference and 14th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference. American Institute of Aeronautics and Astronautics.CrossRefGoogle Scholar
Austin-Breneman, J., Yu, B. Y. & Yang, M. C. 2015 Biased information passing between subsystems over time in complex system design. J. Mech. Des. 138 (1), 011101011101.Google Scholar
Baker, W. E., Cross, R. & Wooten, M. 2003 Positive organizational network analysis and energizing relationships. In Positive Organizational Scholarship: Foundations of a New Discipline (ed. K. S. Cameron, J. E. Dutton & R. E. Quinn), pp. 328342. Barrett-Koehler Publishers, Inc.Google Scholar
Baldwin, C. & Clark, K. B. 2000 Design Rules: The Power of Modularity (Vol. 1). MIT Press.CrossRefGoogle Scholar
Baldwin, C. Y. 2012 Organization design for business ecosystems. J. Organ. Des. 1, 2023.Google Scholar
Baldwin, C. Y., 2007 Where do transactions come from? Modularity, transactions, and the boundaries of firms. Ind. Corp. Chang. 17, 155195.CrossRefGoogle Scholar
Barnard, C. I. 1964 The Functions of the Executive. Harvard University Press.Google Scholar
Bayrak, A. E., Collopy, A. X., Papalambros, P. Y. & Epureanu, B. I. 2018 Multiobjective optimization of modular design concepts for a collection of interacting systems. Struct. Multidiscipl. Optim. 57 (1), 8394.Google Scholar
Bhatia, G., Mesmer, B. & Weger, K. 2018 Mathematical representation of stakeholder preferences for the SPORT small satellite project, 2018. In AIAA Aerospace Sciences Meeting, presented at the 2018 AIAA Aerospace Sciences Meeting. American Institute of Aeronautics and Astronautics.CrossRefGoogle Scholar
Blanchard, B. S. & Fabrycky, W. J. 2011 Systems Engineering and Analysis (5th ed). Pearson.Google Scholar
Blau, P. 1974 On the Nature of Organizations. Wiley.Google Scholar
Bloebaum, C., Collopy, P. & Hazelrigg, G. 2012 NSF/NASA workshop on the design of large-scale complex engineered systems - from research to product realization. In 12th AIAA Aviation Technology, Integration, and Operations (ATIO) Conference and 14th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference. American Institute of Aeronautics and Astronautics.Google Scholar
Bloebaum, C. L. & McGowan, A.-M. R. 2012 The design of large-scale complex engineered systems: present challenges and future promise. In 12th AIAA Aviation Technology, Integration, and Operations (ATIO) Conference and 14th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference. American Institute of Aeronautics and Astronautics.Google Scholar
Borjesson, F. & Hölttä-Otto, K. 2014 A module generation algorithm for product architecture based on component interactions and strategic drivers. Res. Eng. Des. 25 (1), 3151.Google Scholar
Bosch, J. & Bosch-Sijtsema, P. 2010 From integration to composition: On the impact of software product lines, global development and ecosystems. J. Syst. Softw. 83 (1), 6776.Google Scholar
Braun, V. & Clarke, V. 2006 Using thematic analysis in psychology. Qual. Res. Psychol. 3 (2), 77101.Google Scholar
Brooks, F. P. 1995 The Mythical Man-Month: Essays on Software Engineering (2nd ed.). Addison-Wesley.Google Scholar
Burt, R. S. 1992 Structural Holes: The Social Structure of Competition (1st ed). Harvard University Press.Google Scholar
Burt, R. S. & Merluzzi, J. 2014 Embedded brokerage: hubs versus locals. In Research in the Sociology of Organizations (Vol. 40) (ed. D. J. Brass, G. Labianca (JOE), A. Mehra, D. S. Halgin & S. P. Borgatti), pp. 161177. Emerald Group Publishing Limited.Google Scholar
Cataldo, M. & Herbsleb, J. D. 2008 Communication patterns in geographically distributed software development and engineers’ contributions to the development effort. In Proceedings of the 2008 International Workshop on Cooperative and Human Aspects of Software Engineering, pp. 2528. ACM.CrossRefGoogle Scholar
Cataldo, M., Herbsleb, J. D. & Carley, K. M. 2008 Socio-technical congruence: a framework for assessing the impact of technical and work dependencies on software development productivity. In Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, pp. 211. ACM.Google Scholar
Cataldo, M., Wagstrom, P. A., Herbsleb, J. D. & Carley, K. M. 2006 Identification of coordination requirements: implications for the design of collaboration and awareness tools. In Proceedings of the 2006 20th Anniversary Conference on Computer Supported Cooperative Work, pp. 353362. ACM.Google Scholar
Checkland, P. 2000 Soft systems methodology: a thirty year retrospective. Syst. Res. 17, S11–S58.Google Scholar
Collopy, A. X. 2019 Coordination strategies and individual behavior in complex engineered systems design. PhD Thesis, University of Michigan.Google Scholar
Cooper, A. B. & Papalambros, P. Y. 2003 An enterprise decision model for optimal vehicle design and technology valuation. In Proceedings of IMECE ‘03, ASME 2003 International Mechanical Engineering Congress and Exposition. ASME.CrossRefGoogle Scholar
Crawley, E., de Weck, O., Eppinger, S., Magee, C., Moses, J., Seering, W., Schindall, J., Wallace, D. & Whitney, D. 2004 The Influence of Architecture in Engineering Systems, Engineering Systems Monograph. MIT.Google Scholar
Cumming, M. 2002 Flexible and distributed coordination models for collaborative design. In Proceedings of the 20th eCAADe Conference: Connecting the Real and the Virtual, pp. 268–275. eCAADe.Google Scholar
Dahmus, J. B., Gonzalez-Zugasti, J. P. & Otto, K. N. 2001 Modular product architecture. Des. Stud. 22 (5), 409424.CrossRefGoogle Scholar
Dedehayir, O., Mäkinen, S. J., Ortt, J. R. 2018 Roles during innovation ecosystem genesis: a literature review. Technol. Forecast. Soc. Change 136, 1829.Google Scholar
Doran, T. 2006 IEEE 1220: for practical systems engineering. Computer 39 (5), 9294.CrossRefGoogle Scholar
Dossick, C. S. & Neff, G. 2010 Organizational divisions in BIM-enabled commercial construction. J. Constr. Eng. Manag. 136 (4), 459467.CrossRefGoogle Scholar
Efatmaneshnik, M. & Ryan, M. J. 2019 On the definitions of sufficiency and elegance in systems design, IEEE Syst. J. 13 (3), 20772088.Google Scholar
Espinosa, J. A., Armour, F. & Boh, W. F. 2010 Coordination in enterprise architecting: an interview study. In 2010 43rd Hawaii International Conference on System Sciences, presented at the 2010 43rd Hawaii International Conference on System Sciences, pp. 110. IEEE Computer Society.CrossRefGoogle Scholar
Esser, H. 2008 The two meanings of social capital. In The Handbook of Social Capital (ed. D. Castiglione, J. W. Van Deth & G. Wolleb), pp. 2249. Oxford University Press.Google Scholar
Frank, M. 2012 Engineering systems thinking: cognitive competencies of successful systems engineers. Procedia Comput. Sci. 8, 273278.CrossRefGoogle Scholar
Galbraith, J. R. 1974 Organization design: an information processing view. Interfaces 4 (3), 2836.CrossRefGoogle Scholar
Galviņa, Z. & Šmite, D. 2012 Low degree of separation does not guarantee easy coordination. In 2012 38th Euromicro Conference on Software Engineering and Advanced Applications, presented at the 2012 38th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), Cesme, Izmir, Turkey, pp. 345348. IEEE.CrossRefGoogle Scholar
Given, L. 2008 The SAGE Encyclopedia of Qualitative Research Methods. SAGE Publications, Inc.CrossRefGoogle Scholar
Greene, M. T., Papalambros, P. Y. & McGowan, A.-M. R. 2016 Position paper: designing complex systems to support interdisciplinary cognitive work. In Proceedings of the DESIGN 2016, presented at the DESIGN 2016, Dubrovnik, Croatia, pp. 1487–1494. Design Society.Google Scholar
Griffin, M. D. 2010 How do we fix system engineering? In 61st Annual International Congress, Prague, Czech Republic, Vol. 27. AIAA.Google Scholar
Grogan, P. T., Ho, K., Golkar, A. & de Weck, O. L.. 2018 Multi-actor value modeling for federated systems. IEEE Syst. J. 12 (2), 11931202.CrossRefGoogle Scholar
Grogan, P. T. & de Weck, O. L. 2016 Collaboration and complexity: an experiment on the effect of multi-actor coupled design. Res. Eng. Des. 27 (3), 221235.CrossRefGoogle Scholar
Grubb, A. M. & Begel, A. 2012 On the perceived interdependence and information sharing inhibitions of enterprise software engineers. In Proceedings of the ACM 2012 Conference on Computer Supported Cooperative Work, pp. 13371346. ACM.CrossRefGoogle Scholar
Gulati, R. & Singh, H. 1998 The architecture of cooperation: managing coordination costs and appropriation concerns in strategic alliances. Adm. Sci. Q. 43 (4), 781814.CrossRefGoogle Scholar
Gurnani, A. P. & Lewis, K. 2008 Using bounded rationality to improve decentralized design. AIAA J. 46 (12), 30493059.Google Scholar
Hajela, P., Bloebaum, C. L. & Sobieszczanski-Sobieski, J. 1990 Application of global sensitivity equations in multidisciplinary aircraft synthesis. J. Aircr. 27 (12), 10021010.CrossRefGoogle Scholar
Hazelrigg, G. A. 1996 Systems Engineering: An Approach to Information-Based Design. Prentice-Hall.Google Scholar
Helper, S., MacDuffie, J. P., & Sabel, C. 2000. Pragmatic collaborations: advancing knowledge while controlling opportunism. Ind. Corp. Chang. 9, 443488.CrossRefGoogle Scholar
Herbsleb, J. D. & Mockus, A. 2003 An empirical study of speed and communication in globally distributed software development. IEEE Trans. Softw. Eng. 29 (6), 481494.Google Scholar
Herrmann, J. W. 2010 Progressive design processes and bounded rational designers. J. Mech. Des. 132 (8), 081005.CrossRefGoogle Scholar
Honda, T., Ciucci, F., Lewis, K. E. & Yang, M. C. 2015 Comparison of information passing strategies in system-level modeling. AIAA J. 53 (5), 11211133.CrossRefGoogle Scholar
Hutchison, N. & Henry, D. & Pyster, A. 2016 Atlas: understanding what makes systems engineers effective in the U.S. defense community. Syst. Eng. 19 (6), 510521.CrossRefGoogle Scholar
International Council on Systems Engineering (INCOSE). 2004 Systems Engineering Handbook. INCOSE.Google Scholar
Jacobides, M. G., Knudsen, T., Augier, M. 2006 Benefiting from innovation: value creation, value appropriation and the role of industry architectures. Res. Policy 35, 12001221.CrossRefGoogle Scholar
Jacobides, M. G., MacDuffie, J. P., Tae, C. J. 2016 Agency, structure, and the dominance of OEMs: change and stability in the automotive sector. Strateg. Manag. J. 37, 19421967.CrossRefGoogle Scholar
Jacobides, M. G., Cennamo, C., Gawer, A. 2018 Towards a theory of ecosystems. Strateg. Manag. J. 39 (8), 22552276.Google Scholar
Johnson, S. B. 1997 Three approaches to big technology: operations research, systems engineering, and project management. Technol. Cult. 38 (4), 891919.CrossRefGoogle Scholar
Johnson, S. B. 2002 The United States Air Force and the Culture of Innovation, 1945–1965. Air Force History and Museums Center.Google Scholar
Kannan, H., Mesmer, B. L. & Bloebaum, C. L. 2017 Increased system consistency through incorporation of coupling in value-based systems engineering. Syst. Eng. 20 (1), 2144.CrossRefGoogle Scholar
Kleinbaum, A. M., Stuart, T. & Tushman, M. 2008 Communication (and coordination?) in a Modern, Complex Organization. Harvard Business School.Google Scholar
Kraut, R. E. & Streeter, L. A. 1995 Coordination in software development. Commun. ACM 38 (3), 6981.CrossRefGoogle Scholar
Krayner, N. & Katz, R. 2018 Experimental method for measuring simplicity in mechanical design. J. Eng. Des. 29 (1–2), 119.Google Scholar
Krishnamachari, R. S. & Papalambros, P. Y. 1997 Hierarchical decomposition synthesis in optimal systems design. J. Mech. Des. 119 (4), 448457.CrossRefGoogle Scholar
Larsson, A. 2007 Banking on social capital: towards social connectedness in distributed engineering design teams. Des. Stud. 28 (6), 605622.CrossRefGoogle Scholar
Lewis, K. 2012 Making sense of elegant complexity in design. J. Mech. Des. 134 (12), 120801.CrossRefGoogle Scholar
Luo, J., Baldwin, C. Y., Whitney, D. E., Magee, C. L. 2012 The architecture of transaction networks: a comparative analysis of hierarchy in two sectors. Ind. Corp. Chang. 21, 13071335.CrossRefGoogle Scholar
Luo, J. 2018 Architecture and evolvability of innovation ecosystems. Technol. Forecast. Soc. Chang. 136, 132144.CrossRefGoogle Scholar
Mackay, D. & Zundel, M. 2017 Recovering the divide: a review of strategy and tactics in business and management. Int. J. Manag. Rev. 19 (2), 175194.CrossRefGoogle Scholar
Maier, M. W. & Rechtin, E. 2009 The Art of System Architecting (3rd ed.). CRC Press.CrossRefGoogle Scholar
Malone, T. W. 1987 Modeling coordination in organizations and markets, Manag. Sci. 33 (10), 13171332.CrossRefGoogle Scholar
Madni, A. M. & Sievers, M. 2014 Systems integration: key perspectives, experiences, and challenges. Syst. Eng. 17 (1), 3751.CrossRefGoogle Scholar
Malone, T. W. & Crowston, K. 1994 The interdisciplinary study of coordination. ACM Comput. Surv. 26 (1), 87119.CrossRefGoogle Scholar
March, J. G. & Simon, H. A. 1958 Organizations. John Wiley and Sons, Inc.Google Scholar
Martins, J. R. R. A. & Lambe, A. B. 2013 Multidisciplinary design optimization: a survey of architectures. AIAA J. 51 (9), 20492075.Google Scholar
McEvily, B., Soda, G. & Tortoriello, M. 2014 More formally: rediscovering the missing link between formal organization and informal social structure. Acad. Manag. Ann. 8 (1), 299345.CrossRefGoogle Scholar
McGowan, A.-M. R. 2014 Interdisciplinary interactions during R&D and early design of large engineered systems. PhD Thesis, University of Michigan.Google Scholar
Meluso, J. & Austin-Breneman, J. 2018 Gaming the system: an agent-based model of estimation strategies and their effects on system performance. J. Mech.Des. 140 (12), 9.CrossRefGoogle Scholar
Meluso, J., Austin-Breneman, J. & Uribe, J. 2020 Estimate uncertainty: miscommunication about definitions of engineering terminology. J. Mech.Des. 142 (7), 071401.Google Scholar
Metzger, L. S. & Bender, L. R. 2007 MITRE Systems Engineering (SE) Competency Model. The MITRE Corporation.Google Scholar
Michalek, J. J., Ebbes, P., Adigüzel, F., Feinberg, F. M. & Papalambros, P. Y. 2011 Enhancing marketing with engineering: optimal product line design for heterogeneous markets. Int. J. Res. Mark. 28 (1), 112.Google Scholar
Michelena, N., Scheffer, C., Fellini, R. & Papalambros, P. Y. 1999 CORBA-based object-oriented framework for distributed system design. Mech. Struct. Mach. 27 (4), 365392.CrossRefGoogle Scholar
Moore, J. F. 2006 Business ecosystems and the view from the firm. Antitrust Bull. 51 (1), 3175.CrossRefGoogle Scholar
Mosleh, M., Ludlow, P. & Heydari, B. 2016 Resource allocation through network architecture in systems of systems: a complex networks framework. In 2016 Annual IEEE Systems Conference (SysCon), presented at the 2016 Annual IEEE Systems Conference (SysCon), pp. 15. IEEE.CrossRefGoogle Scholar
National Aeronautical and Space Administration (NASA). 2007 NASA Systems Engineering Handbook. National Aeronautics and Space Administration.Google Scholar
National Science Board. 2018 Science and Engineering Indicators 2018, No. NSB-2018-1. National Science Foundation.Google Scholar
Obstfeld, D., Borgatti, S. P. & Davis, J. 2014 Brokerage as a process: decoupling third party action from social network structure. In Research in the Sociology of Organizations (Vol. 40) (ed. D. J. Brass, G. Labianca (JOE), A. Mehra, D. S. Halgin & S. P. Borgatti), pp. 135159. Emerald Group Publishing Limited.Google Scholar
Olson, G. M. & Olson, J. S. 2000 Distance matters. Hum. Comput. Interact. 15 (2), 139178.CrossRefGoogle Scholar
Page, S. E. 2015 What sociologists should know about complexity. Annu. Rev. Sociol. 41 (1), 2141.CrossRefGoogle Scholar
Panchal, J. H. 2010 Coordination in collective product innovation. In ASME 2010 International Mechanical Engineering Congress and Exposition, pp. 333346. American Society of Mechanical Engineers.CrossRefGoogle Scholar
Panchal, J. H., Sha, Z., Kannan, K. N. 2017 Understanding design decisions under competition using games with information acquisition and a behavioral experiment. J. Mech. Des. 139 (9), 091402.CrossRefGoogle Scholar
Papalambros, P. Y. & Wilde, D. J. 2017 Principles of Optimal Design: Modeling and Computation (3rd ed.). Cambridge University Press.CrossRefGoogle Scholar
Papalambros, P. Y. 2002 An enterprise context for design optimization. keynote presentation. In Proceedings of the 6th Biennial Conference on Engineering, Systems, Design, and Analysis (ESDA 2002), Istanbul, Turkey. ASME.Google Scholar
Parnas, D. L. 1972 On the criteria to be used in decomposing systems into modules. Commun. ACM 15 (12), 10531058.Google Scholar
Parraguez, P., Eppinger, S. & Parrag, A. 2016 Characterizing design process interfaces as organization networks: insights for engineering systems management. Syst. Eng. 19 (2), 158173.CrossRefGoogle Scholar
Patton, M. Q. 2015 Qualitative Research and Evaluation Methods (4th ed.). SAGE.Google Scholar
Perrow, C. 2009 Modeling firms in the global economy. Theory Soc. 38 (3), 217243.CrossRefGoogle Scholar
Piccolo, S. A., Lehmann, S. & Maier, A. 2018 Design process robustness: a bipartite network analysis reveals the central importance of people. Des. Sci. 4 (1), 129.CrossRefGoogle Scholar
Pietrzyk, V. J. & Handley, H. A. H. 2016 Outcome-based competency model for systems engineering training. In 2016IEEE International Symposium on Systems Engineering (ISSE), presented at the 2016 IEEE International Symposium on Systems Engineering (ISSE), pp. 17. IEEE.Google Scholar
Pimmler, T. U. & Eppinger, S. D. 1994 Integration analysis of product decompositions. In ASME Design Theory and Methodology Conference. ASME.Google Scholar
Poleacovschi, C. & Javernick-Will, A. 2016 Spanning information and knowledge across subgroups and its effects on individual performance. J. Manag. Eng. 32 (4), 04016006.Google Scholar
Ranganathan, R., Ghosh, A. & Rosenkopf, L. 2018 Competition–cooperation interplay during multifirm technology coordination: the effect of firm heterogeneity on conflict and consensus in a technology standards organization. Strateg. Manag. J. 39 (12), 31933221.CrossRefGoogle Scholar
Ren, Y., Bayrak, A. E., Papalambros, P. Y. 2016 EcoRacer: game-based optimal electric vehicle design and driver control using human players. J. Mech. Des. 138 (6), 061407.CrossRefGoogle Scholar
Reyer, J. A. & Papalambros, P. Y. 2002 Combined optimal design and control with application to an electric DC motor. J. Mech. Des. 124 (2), 183.CrossRefGoogle Scholar
Ryschkewitsch, M., Schaible, D. & Larson, W. 2009 The art and science of systems engineering. Syst. Res. Forum 3 (2), 81100.CrossRefGoogle Scholar
Rivkin, J. W. & Siggelkow, N. 2007 Patterned interactions in complex systems: implications for exploration. Manag. Sci. 53, 10681085.Google Scholar
Roundy, P. T. 2020 Do we Lead together? Leadership behavioral integration and coordination in entrepreneurial ecosystems. J. Leadersh. Stud. 14 (1), 625.CrossRefGoogle Scholar
Sage, A. P. & Lynch, C. L. 1998 Systems integration and architecting: an overview of principles, practices, and perspectives. Syst. Eng. 1 (3), 176227.Google Scholar
Salzberg, S. & Watkins, M. 1990 Managing information for concurrent engineering: challenges and barriers. Res. Eng. Des. 2 (1), 3552.CrossRefGoogle Scholar
Scott, W. R. & Davis, G. F. 2006 Organizations and Organizing: Rational, Natural and Open Systems Perspectives (1st ed.). Routledge.Google Scholar
Sheard, S., Cook, S., Honour, E., Hybertson, D., Krupa, J., MeEver, J., McKinney, D., Ondrus, P., Ryan, A., Scheurer, R., Singer, J., Sparber, J. & White, B. 2015 A Complexity Primer for Systems Engineers. INCOSE.Google Scholar
Simon, H. A. 1955 A behavioral model of rational choice. Q. J. Econ. 69 (1), 99118.CrossRefGoogle Scholar
Simon, H. A. 1973 Applying information technology to organization design. Public Adm. Rev. 33 (3), 268.CrossRefGoogle Scholar
Simpson, T. W. & Martins, J. R. R. A. 2011 Multidisciplinary design optimization for complex engineered systems design: state of the research and state of the practice - report from a national science foundation workshop. In Volume 5: 37th Design Automation Conference, Parts A and B, presented at the ASME 2011 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, pp. 835845. ASME.Google Scholar
Sobieszczanski-Sobieski, J. 1995 Multidisciplinary design optimization: an emerging new engineering discipline. In Advances in Structural Optimization, pp. 483496. Springer.CrossRefGoogle Scholar
Sosa, M. E., Eppinger, S. D. & Rowles, C. M. 2003 Identifying modular and integrative systems and their impact on design team interactions. J. Mech. Des. 125 (2), 240252.CrossRefGoogle Scholar
Sosa, M. E., Eppinger, S. D. & Rowles, C. M. 2004 The misalignment of product architecture and organizational structure in complex product development. Manag. Sci. 50 (12), 16741689.CrossRefGoogle Scholar
de Souza, C. R., Redmiles, D., Cheng, L.-T., Millen, D. & Patterson, J. 2004 How a good software practice thwarts collaboration: the multiple roles of APIs in software development. ACM SIGSOFT Softw. Eng. Notes 29 (6), 221230.CrossRefGoogle Scholar
Stevenson, A. & Lindberg, C. A. (Eds.). 2011 New Oxford American Dictionary (3rd ed.). Oxford University Press.Google Scholar
Strode, D. E., Huff, S. L., Hope, B. & Link, S. 2012 Coordination in co-located agile software development projects. J. Syst. Softw. 85 (6), 12221238.CrossRefGoogle Scholar
Sun, C. & Wei, J. 2019 Digging deep into the enterprise innovation ecosystem: how do enterprises build and coordinate innovation ecosystem at firm level. Chinese Manag. Stud. 13 (4), 820839.Google Scholar
Takai, S. 2010 A game-theoretic model of collaboration in engineering design. J. Mech. Des. 132 (5), 051005.CrossRefGoogle Scholar
Terrasi, E. M. 2015 Leaders who care: exploring empathy as an essential trait in 21st century corporate leadership. MS Thesis, Eastern Michigan University.Google Scholar
Thompson, J. D. 1967 Organizations in Action: Social Science Bases of Administrative Theory. McGraw-Hill, Inc.Google Scholar
Triantis, K. P. & Collopy, P. D. 2014 A comprehensive basis for systems engineering theory. In 2014 IEEE International Systems Conference Proceedings, presented at the 2014 IEEE International Systems Conference Proceedings, pp. 97102. IEEE.Google Scholar
Tushman, M. L. 1979 Work characteristics and subunit communication structure: a contingency analysis. Adm. Sci. Q. 24 (1), 82.CrossRefGoogle Scholar
United States Department of Defense. 2017 Systems Engineering, Defense Acquisition Guidebook. US Department of Defense.Google Scholar
Van de Ven, A. H., Delbecq, A. L. & Koenig, R. 1976 Determinants of coordination modes within organizations. Am. Sociol. Rev. 41 (2), 322.Google Scholar
Van Deth, J. W. 2008 Measuring social capital. In The Handbook of Social Capital (ed. D. Castiglione, J. W. Van Deth & G. Wolleb), pp. 150176. Oxford University Press.Google Scholar
Vermillion, S. D. & Malak, R. J. 2015 Using a principal-agent model to investigate delegation in systems engineering. In ASME 2015 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, p. V01BT02A046. American Society of Mechanical Engineers.Google Scholar
Vrolijk, A. & Szajnfarber, Z. 2015 When policy structures technology: balancing upfront decomposition and in-process coordination in Europe’s decentralized space technology ecosystem. Acta Astronaut. 106, 3346.CrossRefGoogle Scholar
Wagner, T. & Papalambros, P. 1993 A general framework for decomposition analysis in optimal design. In Advances in Design Automation DE65–2, presented at the ASME Design Automation Conferences. American Society of Mechanical Engineers.Google Scholar
Watson, M. D., Griffin, M., Farrington, P. A., Burns, L., Colley, W., Collopy, P., Doty, J., Johnson, S. B., Malak, R., Shelton, J., Szajnfarber, Z., Utley, D. R. & Yang, M. C. 2014 Building a path to elegant design. In Proceedings of the American Society for Engineering Management 2014 International Annual Conference,Virginia Beach, VA. ASME.Google Scholar
de Weck, O. L., Roos, D. & Magee, C. L. 2011 Engineering Systems: Meeting Human Needs in a Complex Technological World. MIT Press.Google Scholar
Weick, K. E., Sutcliffe, K. M. & Obstfeld, D. 2005 Organizing and the process of sensemaking. Organ. Sci. 16 (4), 409421.CrossRefGoogle Scholar
Williams, C. & Derro, M.-E. 2008 NASA Systems Engineering Behavior Study. National Aeronautics and Space Administration.Google Scholar
Woodcock, H. (Ed.). 2010 Systems Engineering Competency Framework. INCOSE UK.Google Scholar
Yao, W., Chen, X., Luo, W., van Tooren, M. & Guo, J. 2011 Review of uncertainty-based multidisciplinary design optimization methods for aerospace vehicles. Prog. Aerosp. Sci. 47 (6), 450479.CrossRefGoogle Scholar
Yin, R. K. 2003 Case Study Research: Design and Methods (3rd ed.). Applied Social Research Methods. SAGE Publications.Google Scholar
Zimmermann, T. & Nagappan, N. 2008 Predicting defects using network analysis on dependency graphs. In Proceedings of the 30th International Conference on Software Engineering, pp. 531540. ACM.Google Scholar
Figure 0

Table 1. Summary of interviewee demographics based on title and years of industry experience

Figure 1

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

Figure 2

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.

Figure 3

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

Figure 4

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).

Figure 5

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).

Figure 6

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.)

Figure 7

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).

Figure 8

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).

Figure 9

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

Figure 10

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

Figure 11

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 12

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).

You have Access Open access
1
Cited by