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

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.

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 2011; Papalambros & Wilde 2017).

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 2012; Madni & Sievers 2014). 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 2012; Page 2015). Coordination also requires different disciplines to work together effectively (Sage & Lynch 1998; Madni & Sievers 2014) and to share information between the tasks of analysis, design and test (Johnson 1997; Blanchard and Fabrycky, 2011).

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 2011). This inherent mutiobjective nature of LSCES design can be addressed in the standard ways of combining them into a scalar substitute function (Papalambros & Wilde 2017) 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 (2003)). Modelling such single objectives goes beyond engineering models and includes marketing and finance models (see, e.g., Michalek et al. (2011)). 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. (2004)).

Coordination is often entangled with related concepts. McGowan (2014) 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 2009; McGowan 2014).

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 1995). 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 2009). Thus, the solution requires coordination: ‘the task of guiding subproblem solutions towards an optimal system design’ (Allison, Kokkolaras & Papalambros 2009).

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 (2013), 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 2013). 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 1990; Alyaqout et al. 2011), improved computational efficiency through suspension of weakly coupled subproblems or reformulation of subproblem optimizers (Alyaqout et al. 2011; Alexandrov & Lewis 2002) and the inclusion of uncertainty (Yao et al. 2011).

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 2011; Bloebaum, Collopy & Hazelrigg 2012).

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 1955), 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 2016), behavioural experiments to identify what causes designers to shift between exploration and exploitation of alternatives (Panchal, Sha & Kannan 2017), exploring the potential upsides of bounded rationality to improve design solutions (Gurnani & Lewis 2008) and using bounded rationality as a baseline for evaluating the impact of selecting different overall objective functions in a design process (Herrmann 2010). 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 1973; Galbraith 1974; Gulati & Singh 1998). 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 2006).

The foundational literature on coordination largely builds on the rational system model – that every organization has a central goal (March and Simon 1958; Blau 1974; Scott & Davis 2006). 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 1974). Coordination in organizations is about managing interdependencies between groups of people (Malone & Crowston 1994). 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 1958; Thompson 1967; Van de Ven, Delbecq & Koenig 1976). 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 1958; Galbraith 1974; Tushman 1979; Malone 1987). 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 1998). 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 2010). 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 2010). Anticipated coordination may also drive the creation of new organizational channels for information transfer (Gulati & Singh 1998), but unplanned, unexpected or infrequent coordination needs are more difficult to address (Sosa, Eppinger & Rowles 2004). 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 1974; Barnard 1964). The concepts of ‘soft’ systems methodology emphasizing systems thinking (Checkland 2000), social capital emphasizing development and leverage of social networks (Larsson 2007; Adler & Kwon 2002; Esser 2008; Van Deth 2008; Agneessens & Wittek 2012), brokerage emphasizing bridging communities or ‘structural holes’ (Burt 1992; Obstfeld, Borgatti & Davis 2014; Burt & Merluzzi 2014) and positive leadership emphasizing empathy and optimism (Baker, Cross & Wooten 2003; Terrasi 2015) 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 2015; Honda et al. 2015). 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 2015) – 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 2016), game theory (Vermillion & Malak 2015; Takai 2010), miscommunication (Meluso, Austin-Breneman & Uribe 2020) and exploration of the cognitive processes of systems engineers (Greene, Papalambros & McGowan 2016; McGowan 2014). 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 1972; de Souza et al. 2004; Maier & Rechtin 2009; Panchal 2010; Bayrak et al. 2018). 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 1994; Cataldo et al. 2006) and is one driver for developing a more modular design process (Bosch & Bosch-Sijtsema 2010). 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 2001; Asikoglu & Simpson 2012; Borjesson & Hölttä-Otto 2014; Bayrak et al. 2018).

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 2000). The remaining elements can be divided into modules using design rules (Baldwin & Clark 2000) or graph partitioning (Wagner & Papalambros 1993; Krishnamachari & Papalambros 1997).

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 2009) and software design (Parnas 1972); 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 1972). 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. 2004). Communication tends to follow organizational boundaries (Kleinbaum, Stuart & Tushman 2008), and interfaces across those boundaries are often sources of interteam communication lapses (Kraut & Streeter 1995; Sosa, Eppinger & Rowles 2003, 2004; Dossick & Neff 2010; Galviņa & Šmite 2012) Many such interfaces are potential sources of defects (Piccolo et al. 2018; Zimmermann & Nagappan 2008). Geographically distributed teams and organizations face further challenges due to communication delays and differing norms (Olson & Olson 2000; Herbsleb & Mockus 2003).

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 1996; Johnson 2002; Maier & Rechtin 2009; Blanchard & Fabrycky 2011; de Weck, Roos & Magee 2011). Most systems engineering process standards include some variant of requirements definition, detailed design, test and integration, verification and validation and operation and maintenance (Johnson 2002; INCOSE 2004; Doran 2006; 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 2002; NASA 2007; Blanchard & Fabrycky 2011). 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 2009; Griffin 2010; Triantis & Collopy 2014; Bloebaum & McGowan 2012).

These tasks reiterate the notion that systems engineers have a managerial role, with responsibility to ensure successful system integration throughout the lifecycle (Sage & Lynch 1998). 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 1996) or as enablers of elegant design (Griffin 2010). For a review of elegance and simplicity in LSCES and product design, see Lewis (2012); Watson et al. (2014); Krayner & Katz (2018); Efatmaneshnik & Ryan (2019).

Coordination between different groups in an organization is typically reserved for specific coordination roles within the organization (Cataldo & Herbsleb 2008; Grubb & Begel 2012); 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 2012; Bloebaum & McGowan 2012). The existence of a social component to systems engineering has been recognized in multiple systems engineering competency models (Metzger & Bender 2007; Williams & Derro 2008; Woodcock 2010; Frank 2012; Hutchison, Henry & Pyster 2016; Pietrzyk & Handley 2016). 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 2007; Williams & Derro 2008; Woodcock 2010; Frank 2012; Hutchison, Henry & Pyster 2016; Pietrzyk & Handley 2016). 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 2006; Perrow 2009; de Weck, Roos & Magee 2011; Jacobides, Cennamo & Gawer 2018). In these ecosystems, firms and organizations exchange material, energy and information (Baldwin 2007) and each organization’s successes and challenges impact others in their ecosystem (Adner & Kapoor 2010).

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. (1999) 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 (2002) and Jacobides, MacDuffie & Tae (2016) 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. (2012) 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 2010; Sun & Wei 2019).

The variance in ecosystem architectures, or the division of agents in the ecosystem and their pattern of connections (Helper, MacDuffie & Sabel 2000; Jacobides, Knudsen & Augier 2006; Luo 2018), 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 2018; Ranganathan, Ghosh & Rosenkopf 2018) and individual leadership behaviours in turn can impact the behaviours of the group and ecosystem to effect that coordination (Roundy 2020).

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 2011; Bloebaum & McGowan, 2012). Another prominent source of complexity is the social system engaged in system design and development work (de Weck, Roos & Magee 2011; Bloebaum & McGowan, 2012; McGowan 2014; Sheard et al. 2015; Grogan & de Weck, 2016). Distributed knowledge (Cumming 2002; McGowan 2014), inconsistent preferences (Kannan, Mesmer & Bloebaum 2017; Bhatia, Mesmer & Weger 2018) and multiple incentives (Vermillion & Malak 2015; Grogan et al. 2018; Meluso & Austin-Breneman 2018) 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 (2019). 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 2008). 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 2017). 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 2015). Our thematic analysis approach followed the methodology outlined by Braun & Clarke (2006). 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 (2006) 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, 2015, 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 2011). 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 1992; Adler & Kwon 2002). 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 2005) 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 1958; Thompson 1967; Van de Ven et al. 1976; Tushman 1979; Malone & Crowston 1994; Herbsleb & Mockus 2003; Sosa, Eppinger & Rowles 2003; de Souza et al. 2004; Cataldo, Herbsleb & Carley 2008). 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. 1990; Alyaqout et al. 2011), the existence and need to account for multiple preferences and incentives (Vermillion & Malak 2015; Bhatia, Mesmer & Weger 2018; Grogan et al. 2018; Meluso & Austin-Breneman 2018), use of social capital (Adler & Kwon 2002; Larsson 2007; Agneessens & Wittek 2012), brokerage and working across organizational boundaries (Sosa, Eppinger & Rowles 2004; Burt & Merluzzi 2014;Obstfeld, Borgatti & Davis 2014) and positive leadership (Baker, Cross & Wooten 2003; Terrasi 2015). 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 2008; Hutchison, Henry & Pyster 2016). 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. (2004). 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 2009), design and control decisions (Reyer & Papalambros 2002), formal and informal organization (McEvily, Soda & Tortoriello 2014) and strategy and tactics selection (Mackay & Zundel 2017), 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. 2004; Grubb & Begel 2012). 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 2010). Recommended resolutions to these apparent challenges with the Passive strategy for facilitating coordination focus on increasing communication and awareness of parallel work (Herbsleb & Mockus 2003; Espinosa, Armour & Boh 2010).

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 1995). 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 2003; Dossick & Neff 2010) and identifying and accessing relevant information out of a large possible set (Salzberg & Watkins 1990). To address these challenges, defining formal coordinator roles is often recommended (Strode et al. 2012; Parraguez, Eppinger & Maier 2016; Poleacovschi & Javernick-Will 2016). 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 2003) 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 (1979) and design activity as in Strode et al. (2012)] 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 2004; Rivkin & Siggelkow 2007; Allison, Kokkolaras & Papalambros 2009; Vrolijk & Szajnfarber 2015). 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 (1998); Helper et al. (2000); Baldwin (2007); Baldwin (2012); Luo et al. (2012); Jacobides, MacDuffie & Tae (2016)] and how these coordination-facilitation strategies apply to an organization’s outward behaviour.