*(this text comes from a paper that was supposed to be published in some journal but never made it)* # Introduction A group of people pursuing the design of a complex technical artifact can be thought of as a _system_, called here an _Engineering Design Team_. That is, a system whose main mission is to design complex artifacts. This is an open system: it engages in transactions with larger systems: the organization, society, and markets. An Engineering Design Team is also a sociotechnical system; it consists of the organization of people around technology. This means, among other things, that human relations are not an optional feature of the organization: they are a built-in property. Fundamentally, engineering design is a social activity. An analysis of how these social constructs evolve and react, what stocks and flows can be found, and how their structure interacts with the technical artifact under design is presented and discussed, along with some proposed questions. While trying to avoid falling into what John Gall caustically calls _systemism_—a state of mindless belief in systems—there undoubtedly is a tendency to describe human organizations using a broad way of thinking called Systems Theory, whose foundations can be found in the works of Von Bertalanffy[^1] in the 1940s and J.W Forrester[^2] in the 1960s. The theory uses certain concepts to analyze a wide range of phenomena in the physical sciences, biology, and behavioral sciences. These phenomena are common in many different systems, ranging from the atom to the galaxy, from the cell to the organism, from the individual to the society. An industrial organization can be analyzed within this framework. What is a system, generally speaking? A system is an assembly of interdependent parts (subsystems), whose interaction determines its survival. Interdependence means that a change in one part affects other parts and thus the whole system. Such a statement is true for atoms, molecules, people, plants, formal organizations, and planetary systems. In Systems Theory, the behavior of the whole (at any level) cannot be predicted solely by knowledge of the behavior of its subparts. Conventional organizational theory, however, does attempt to predict the behavior of the organization based on assumptions about individuals. An engineering design team is an open system. It engages in transactions with larger systems: the organization, society, and markets. There are inputs in the form of people, materials, money, and in the form of political and economic forces arising in the larger system. There are outputs in the form of products, services, and rewards to its members. Similarly, subsystems within the organization down to the individual are open systems. As said, an engineering design team is a socio-technical system. It is not merely an assembly of buildings, manpower, money, machines, and processes. The system consists of the organization of people around technology. This means, among other things, that human relations are not an optional feature of the organization: they are a built-in property. The system exists by virtue of the motivated behavior of people. Their relationships and behavior determine the inputs, the transformation, and the outputs of the system[^3]. # Systems Thinking In modern engineering, social skills are just as important as technical skills. Systems thinking, with its emphasis on social and technical interactions and influences, enables engineers to better mobilize, organize, and coordinate resources (human, financial, and physical) towards the completion of a systems design[^4]. The skills and benefits of systems thinking enhance problem-solving ability[^5]. Traits of systems thinking include the ability to understand dynamic systems behavior and to identify patterns resulting from interactions[^6][^7]. The identification of feedback processes, or closed-loop thinking, is used to explain the observed patterns of behavior, thus enabling action to influence behavior. The ability to recognize stocks and flows—sometimes referred to as structural thinking—is also a skill of systems thinking. Systems thinkers are also able to identify and understand the impact of time delays between system inputs and reactions, enriching their understanding of feedback loops. Recognizing the limits of assumptions and the presence of non-linearities in a system are also important to effective systems thinking. Finally, to be an effective systems thinker, one must be familiar with the specific knowledge required by the problem’s context and have the ability to leverage both quantitative and qualitative data toward its solution[^8]. # Systems Dynamics System dynamics is a methodology for mathematical modeling techniques for complex issues and problems. Originally developed in the 1950s to help corporate managers improve their understanding of industrial processes, Systems Dynamics is still being used throughout the public and private sectors for policy analysis and design. System dynamics emerged from within systems theory as a method to understand the dynamic behavior of complex systems; for this, it heavily relies on control theory. The basis of the method is the recognition of the many feedback loops that the structure of any system presents, and the many circular, interlocking, sometimes time-delayed relationships among its components, are often just as important in determining its behavior as the individual components themselves. Examples are chaos theory and social dynamics. It is also claimed that because there are often properties of the whole that cannot be found among the properties of the elements, in some cases the behavior of the whole cannot be explained in terms of the behavior of the parts. Stocks and flows, along with feedback, are the two central concepts of Systems Dynamics. Stocks are accumulations. Stocks give systems inertia and provide them with memory. Stocks create delays by accumulating the difference between the inflow to a process and its outflow. By decoupling rates of flow, stocks are the source of disequilibrium dynamics in systems. Stocks and flows are familiar to all of us. Stocks are altered by inflows and outflows. Failure to understand the difference between stocks and flows often leads to underestimation of time delays, a short-term focus, and policy resistance[^9]. In a design team, knowledge can be represented as stock accumulated in a distributed way across the social structure. The inflow of knowledge comes from training and experience, while the outflow comes from actors leaving the organization or knowledge obsolescence. Engineering design teams grow this stock of knowledge and experience as a shared resource; lessons learned are also a heuristic type of stock for design teams. This text bases its analysis on these three enabling, cornerstone concepts as foundations: Systems Theory, Systems Thinking, and Systems Dynamics leading to a combination close to the definition of “Engineering Systems” from MIT: Engineering Systems combines engineering with perspectives from management, economics, and the social science to address the design and development of the complex, large-scale, sociotechnical systems that are so important in all aspects of modern society[^11]. # Design Team Emergence In a hypothetical design experiment, twenty experienced design engineers are hired. Competitive salaries are paid but no details about the work to be done are provided. These engineers are carefully selected with a variety of different skill sets. The engineers are gathered together in an office, and without specifying any roles and teams, they are told to design a complex system. What would happen next? Left alone, design teams react in basic, fundamental ways. For example, they might ask these basic questions: - What resources are available? How much time? What's the budget? - What specifications to design for? - Why? (design goal) These questions are ultimately seeking feedback. Feedback is essential for the design process since design is a closed-loop activity: as the design team feeds the stakeholders, the stakeholders are expected to feed information back which will be used to adjust the design process. Without such information, the design team would be working in open loop. A design team working in a closed loop will still have to adjust according to the information gathered and iterate to produce an outcome that will hopefully match what was desired (or specified), or alter the design if the objective is not achieved. It could not be straightforward to analyze what direction should be taken to adjust a design to match objectives. For example, a system design flagged as unreliable will require adjustments to make it more reliable. This will introduce changes to the current design, which means introducing new, unknown features, which might only decrease reliability even further. The last question from the list above: Why? It is probably the most subjective, less technical, but the most socially meaningful and impactful question a design team can face. What is the reason behind pursuing a design effort in a social construct as a team? The reasons can be many different: innovation, to fulfill a market need (probably the most typical), technology maturation, and a long etcetera. The answer as to why the design is happening needs to be known by all its actors. Needless to say, design teams must also measure or gauge their designs, and if design objective(s) have been met or not. This is done by verification. Verification will take the form of an analysis, an actual test on a prototype, or a design review with the end customer. # Design Life Cycles The next step for the design team is to capture a high-level description (architecture) of the artifact, where the main building blocks are identified, along with all the interfaces interconnecting these blocks. Synthesizing an architecture is the first default milestone in the life cycle of a technical artifact. There are several ways of specifying and choosing life cycle models. What life cycle model a design team would naturally choose? As an example, a team may follow an approach that starts off designing on top of very coarse requirements, prototyping and integrating in quick cycles, verifying, adjusting, and repeating the process as many times as possible. As design teams mature and evolve, they eventually choose more formal, heavyweight life cycle models (V-Model, Agile, etc) which will introduce overhead and time delays. The approach incorporates techniques stemming from what research calls improvisation principles. Improvisation here must be understood as improvisation in music and art, defined as a creative act composed without a deep prior thought; this process includes creative collaboration, supports spontaneity, and learns through trial and error[^12]. After synthesizing the architecture of the artifact, the design team continues describing in a more granular way the subsystems and parts that compose the top-level architecture. This process is recursive since subsystems can be thought of as artifacts on their own, meaning they can also have an architecture and so forth. All these activities are described as tasks and are to be carried out by the different actors in the social structure of the design team, headed by a Chief Designer. The chief designer coordinates the work of the team of designers, arbitrating should conflicting ideas appear. On larger projects, the chief designer focuses increasingly on architectural or conceptual design, and the detailed design will be performed by a team of designers. The designers design the components and subsystems within the architectural constraints. The designers should be experienced in component and sub-system design and several different disciplines. The role of the Chief Designer is to be a pathfinder of new ideas that can prove to be useful and applicable for the organization, but the design process has to be democratically shared with the rest of the design team since Chief designers can also be prone to bias. The chief designer should be the most experienced designer in the team and have good interpersonal communication skills[^13]. # Feedback Loops and Decision-Making Any engineering design team is decision-making intensive. Designing means deciding. Decisions require information. Context is information, constraints are information, legislation and/or regulations are information, lessons learned from the past are information, and market forces are information. A design team is an information processing engine that distills all those disparate sources to make better decisions. Design not only means creating non-existent artifacts from scratch but also adding or integrating existing artifacts into the architecture. The rationale behind this decision ([[Product Management#Make vs Buy|make vs buy]]) is usually more complex than just time, the rest usually being vertical integration or some similar strategic reasons. Engineering design teams struggle to discern what to create versus what to integrate since oftentimes this decision requires multivariable analysis, including financial reasoning and a fair amount of extrapolation. The design team's main endeavor is to realize the goal^[14], not to create all parts of the artifact from scratch. The aerospace industry, for instance, designs the most complex and reliable technical artifacts found. Their design teams are principally strong integrators[^15] more than component designers. To successfully create an efficient decision-making environment, a general methodology needs to be formulated that will require the application of advanced methods to find the best set of strategies possible. One potential technique is game theory. Game theory presents a logical and mathematically based means of approaching problems involving competing strategies and decision-making. A game is a model of a competitive situation, and game theory is a set of mathematical methods for analyzing these models and selecting optimal strategies. Game theoretic methods also provide a basis for enumerating decisions available, evaluating options or "moves", ruling out "moves" that do not make strategic sense, determining the viability of partnerships, and conducting "what-if" analysis for various scenarios[^16]. # Spontaneous vs Constructed Order in Design Teams The design team can be thought of as a system designing another system, with a parent-child relationship. Given that no hierarchy or grouping is actively established, how shall this structure emerge? Is spontaneous order possible in engineering design teams? There is a known, symbiotic interaction between the technical artifact and the social structure which designs it. This has been treated by literature and called the “mirroring hypothesis”[^17], and captured by Conway's law[^18] (an observational adage more than a law): > [!quote] > *Organizations which design artifacts are constrained to produce designs which are copies of the communication structures of these organizations.* This adage observes that the way people group and interact towards creating a technical artifact is reflected in the design and architecture synthesized, but what about vice versa? Can the technical artifact structure introduce some tension in the social structure which synthesizes it and reshape it? Let’s assume that engineers will team up according to background affinity (provided no other ethnic or culture-related characteristics will overpower this). This indicates we will end up with a typical functional type of organization, where people gather around what they know to do. Is the functional approach the right one for designing a multi-disciplinary complex technical machine? According to the mirroring theory, a social structure following the artifact structure seems to be the most efficient form factor. One conclusion from this observation: spontaneous order in engineering design teams is intrinsically inefficient if analyzed from a mirroring hypothesis perspective, which means engineering design teams may benefit from constructed order (active control) to work more efficiently since otherwise it will naturally converge to a functional, more inefficient type of structure. The paradox behind this is that the structure of the artifact is only known at a later time compared to when the design team structure is chosen. The fact that the social structure requires active control to make it more stable suggests that design teams are unstable by nature and can acquire stability only if actively constructed and controlled. Will “big picture” thinkers naturally emerge as leaders versus reductionist thinkers? The multidisciplinary nature of complex artifacts suggests that people with the capability to reason and understand more than one discipline will have a strong advantage over more specialized mindsets. The complexity of technical artifacts can only grow in the future, this means design teams' complexity can only follow the trend and also get more complex. The most apt profile to cope with such complexity seems to be a polymath engineer with a systemic worldview. Engineering schools are still producing only specialized resources. Can ‘polymath’ engineers be educated or trained? Is design ‘polymathy’ attainable? The multidisciplinary nature of engineering design teams creates communicational gaps since actors with different backgrounds and education (even though they are all engineers) will often struggle to communicate on technical topics. There have been some efforts recently on trying to help close this gap by creating graphical languages to describe artifacts from high levels of abstractions, such as SysML. This is linked to a trend in Engineering called Model-Based Systems Engineering (MBSE), which aims for a model-centric approach to creating complex technical artifacts. MBSE (and Systems Engineering in general) proposes a solution to the multidisciplinary communication gap by creating a more generalist role that is supposed to “translate” between all the different actors, a sort of architect of the technical artifact. There is a large bibliography on MBSE, but little evidence of its true success outside of big, heavyweight organizations. Small organizations try to imitate this practice, to very poor results, due to different contexts. Engineering design is intrinsically model-based, which makes a model-based methodology redundant. Scientists and engineers naturally try to understand a complex, real-world phenomenon by first constructing a simplified or idealized model of it. Sometimes they might construct a physical model, such as the scale models that engineers build to test new structures. Often, however, scientists simply write down a set of assumptions or equations, and so come up with a theoretical model. A scientist might try to understand the solar system by assuming that the planets are perfect spheres subject only to the gravitational field of the sun, for example, or treat the molecules of a gas as if they were a collection of tiny billiard balls. Modeling is extremely important in the sciences[^19]. In my personal experience, when the structure of the engineering design team was left to be spontaneous, it unsurprisingly converged to a purely functional structure, grouped by engineers with the same background (categorical hierarchy). As the organization grew in size and project diversity, the tension between the artifact under design and the social fabric designing it started to surface, until the organization reached a point where action was required (spontaneous order needed to give way to constructed order). The solution was to implement Integrated Product Teams (IPTs) to ease the friction, by creating “subsystem projects” mapping to the artifact's hierarchical structure and populating the teams with people from different functional areas. This is not the same as turning the organization into a matrix. Functional team leaders retained their decision-making power, while the functional team members had full leverage to control and impact the subsystem project timeline, usually boosting their morale. There is still very little research on IPTs applied to small organizations. Integrated Product Teams poorly implemented can create overhead if loosely controlled. # Conclusions Making machines is more of a social endeavor than a technical one. Multidisciplinary design teams evolve by asking a set of fundamental questions, which ultimately aim to gather information for decision-making, in a closed-loop manner. Spontaneous social constructs are inefficient since they naturally grow as categorical hierarchies, which are misaligned with the artifact structure (which follows a containment hierarchy), creating tension. This calls for the creation of small integrated multidisciplinary teams assigned to specific components of the architecture. Systems thinkers and “jack of several trades” are well suited in these multidisciplinary teams as complexity grows; this is paradoxical since engineering schools generally provide specialist profiles. [^1]: Ludwig von Bertalanffy, General System Theory: Foundations, Development, Applications [^2]: Jay Forrester, Industrial Dynamics, M.I.T. Press, Cambridge, Mass.; Wiley, New York, 1961 [^3]: D. McGregor. The Professional Manager. McGraw-Hill, 1967 [^4]: S. Beder. Beyond Technicalities: Expanding engineering thinking. Journal of Professional Issues in Engineering Education and Practice, 125(1):12–18, January 1999 [^5]: P. Jansma and R. Jones. Advancing the Practice of Systems Engineering at JPL. Proc. AIAA Aerospace 2006, Big Sky, MT, March 2006 [^6]: B. Richmond. Systems Thinking: Critical thinking skills for the 1990s and beyond. System Dynamics Review, 9(2):113–133, 1993. [^7]: L. Sweeney and J. Sterman. Bathtub Dynamics: Initial results of a systems thinking inventory. System Dynamics Review, 16(4):249–294, 2000. [^8]: Collaborative Systems Thinking: An exploration of the mechanisms enabling team systems thinking - Caroline Marie Twomey Lamb PhD thesis, MIT, 2009 [^9]: Business Dynamics, John D. Sterman, Irwin-McGraw-Hill [^11]: Engineering Systems, Meeting Human Needs in a Complex Technological World, Christopher L. Magee, Daniel Roos, and Olivier de Weck. [^12]: Improvisation Principles and Techniques for Design, Elizabeth Gerber. Stanford University [^13]: ‘Design Synthesis: Integrated Product and Manufacturing System Design’, Britton, Torvinen. [^14]: ‘Technical Functions. On the Use and Design of artifacts’, Wybo Houkes · Pieter E. Vermaas [^15]: ‘Hundreds suppliers, one Boeing airplane’,: https://www.nbcnews.com/id/wbna36507420 [^16]: ‘Applications of game theory in a Systems Design approach to strategic engine selection’, Simon I. Briceno, Dimitri N. Mavris Aerospace Systems Design Laboratory, Georgia Institute of Technology [^17]: Lyra Colfer & Carliss Y. Baldwin: The Mirroring Hypothesis: Theory, Evidence, and Exceptions, Harvard Business Review [^18]: How Do Committees Invent? Melvin E. Conway [^19]: Models as make believe, Imagination, fiction and scientific representation; Adam Toon.