It’s fun, it’s rewarding, and it’s entertaining.

– Courtney Wright on being a systems engineer

In 2007, Art Pyster attended a strategy session for the then new School of Systems and Enterprises at Stevens Institute of Technology. Faculty there were largely focused on the research and educational programs of either the “Systems” or the “Enterprises” aspects of the school. In a eureka moment, one of the faculty members said we were focused on the wrong thing. “Systems” were important, “Enterprises” were important, but the true strength of the school was the “and” that joins them. It was the juxtaposition and relationship between the two disciplines that would give the new school its greatest opportunity. A similar truth can be said about systems engineers. Systems engineers are “and” people. They understand the “big picture” and the details. They communicate well with engineers and executives. They know how to analyze complexity and how to design for simplicity. They balance budgets and make technical trade‐offs. They appreciate both the abstract and the concrete. The term we use for this uncommon and proficiency is paradoxical mindset – the ability to comfortably hold in your head and balance seemingly competing or contradictory concepts. Highly effective systems engineers are masters of paradoxical mindset.

Systems engineers play an increasingly important role in the twenty‐first century because systems are ever more interconnected, more complex, and more challenging to secure. Systems are changing at an astonishing rate in ways that are impossible to predict when first conceived. Cars today routinely have tens of millions of lines of software and dozens of microprocessors. They are becoming so “smart” that early self‐driving cars are in experimental use today and within a few years of being practical. The US National Academy of Engineering’s Fourteen Grand Challenges for Engineering in the twenty‐first century are really about creating and managing large complex ecosystems to solve such problems as providing access to clean water, preventing nuclear terror, and making solar energy abundant and economical [1].

Strong, highly effective systems engineers are required at the center of virtually every new and evolving product, service, and enterprise – that is, every system – in every business sector around the globe. Systems engineers understand how the various pieces fit together, where the technical risks are, and what customers want and need. They oversee the selection of critical technologies and decide the trade‐offs between highly demanding safety, security, and performance requirements. They determine which aspects of a system are so complex that they pose potentially crippling challenges to success and then develop strategies to manage that complexity and overcome those challenges. They look at the characteristics of a proposed system and define the engineering processes and organizational support needed to successfully develop it. They nurture systems engineers who are junior to them and guide development teams.

Highly effective systems engineers are multidisciplinary by nature – they are experts in a few technologies and system types, and critically, they understand just enough about every technology and discipline that are central to the systems on which they work. (Recall they are and people.) The term T‐shaped has sometimes been used to describe such people – they have depth in (at least) one technical area (the vertical stem of the “T”) and have a broad set of skills that cut across many disciplines at least lightly (the horizontal bar of the “T”) [2, 3]. However, for systems engineers, being T‐shaped is not enough. We prefer the term Π‐shaped (pi‐shaped) because systems engineers really have two “stems” – the first reflects depth in at least one technical area – the same as for T‐shaped people. The second stem reflects the systems engineering discipline – an understanding of how to manage technical risk, architect systems, establish requirements, and a myriad of other topics. Π‐shaped systems engineers have even greater demands placed on them than T‐shaped classic engineers. (We use the term classic engineer throughout to refer to engineers who are not systems engineers.)

Systems engineers have a deep understanding of the way in which a system might be used – they are the keepers of the system vision. Their value and the ubiquitous need for systems engineering expertise is reinforced in the 2014 report from the President’s Council of Advisors on Science and Technology (PCAST), Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering, which states:

systems‐engineering knowhow must be propagated at levels [in the US health‐data infrastructure]; PCAST recommends that the United States build a health‐care workforce that is equipped with essential‐systems engineering competencies that will enable [healthcare delivery] system redesign. [4]

Healthcare is only one of dozens of business sectors where aspects of what systems engineers know and can do must become ubiquitous among all engineers and technical experts.

If you recognize the importance of the activities described here but are not deeply familiar with the term systems engineer, you are not alone. Most systems engineers go by other names – product architect, product platform engineer, chief engineer, lead engineer, system architect, product engineer, and many other titles driven by such factors as company culture, business sector, and geography. In interviews that we conducted with more than 300 self‐identified systems engineers, fewer than half said they had ever held the official job title of systems engineer! But “a rose by any other name” – the people who perform all the demanding activities described above, no matter their titles, are systems engineers. Furthermore, millions of classic engineers and project managers are, in effect, secondarily systems engineers – often without realizing it. Electrical, civil, software, environmental, and numerous other engineers and project managers occasionally do systems engineering while spending most of their time designing circuit boards, writing code, conducting material stress calculations, getting budgets approved, or performing other traditional discipline‐specific activities.

Because systems engineers are so important to the successful development, manufacture, deployment, operation, and evolution of products, services, and enterprises around the world, it is vital that they be good at what they do. This book systematically walks through a series of topics explaining what enables systems engineers to be highly effective. It looks at what they do, how they are educated, what typical career paths they follow, the environments in which they work, their personal characteristics, and many other factors that influence their professional lives. The chapters are laid out in a logical order for you to gain an increasingly thorough understanding of these factors, how they influence effectiveness, and what you can do to improve your own effectiveness and the effectiveness of those around you. The last chapter of the book offers specific recommendations that you can follow to become a (more) highly effective systems engineer.

WHAT IS SYSTEMS ENGINEERING?

The International Council on Systems Engineering (INCOSE) [5] says that systems engineering is a perspective, a process, and a profession. The INCOSE Systems Engineering Handbook [6] includes three representative definitions:

1. Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeds with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. Systems engineering integrates all the disciplines and classic groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.
2. Systems engineering is an iterative process of top‐down synthesis, development, and operation of a real‐world system that satisfies, in a near optimal manner, the full range of requirements for the system.
3. Systems engineering is a discipline that concentrates on the design and application of the whole (system) as distinct from the parts. It involves looking at a problem in its entirety, taking into account all the facets and all the variables and relating the social to the technical aspect.

Based on this extended definition of systems engineering, the Systems Engineering Body of Knowledge (SEBoK) [7] identifies the overall goals of any systems engineering effort to be:

1. Understand stakeholder value
2. Select a specific need to be addressed
3. Transform that need into a system (the product, service, or enterprise that addresses that need)
4. Use that system to provide the stakeholder value.

Throughout a system’s lifecycle, many individuals and teams perform the systems engineering activities necessary to achieve those goals. These individuals are systems engineers even if they are not labeled as such by their organization. (Throughout, we use the term organization generically for a systems engineer’s employer. The organization could be private or public, a parent enterprise, or just a unit. Sometimes we are specific, for example, referring to a company or a university, when the particular type of organization is known.) In addition, there could be more than one individual who performs those activities. Hence, it is common for such systems engineers to be hidden in plain sight.

BEING A SYSTEMS ENGINEER

It is in some ways both alarming and dumbfounding that a profession with millions of practitioners worldwide has no general agreement on what criteria should be used to decide if someone is a legitimate member of that profession! Yet, that is the state of systems engineering today, although this is less a problem than it was 20 years ago. Most engineers earn a bachelor’s degree in some engineering field, which becomes their professional label for years and perhaps for life. According to the World Economic Forum, in ten of the most well‐developed countries, over 1,800,000 students graduated with engineering degrees in 2015 alone [8]. Those graduates almost certainly identify themselves as mechanical engineers, bioengineers, electrical engineers, and a multitude of other discipline titles. Moreover, the world recognizes their identity in that way. Yet, very few earn a bachelor’s degree in systems engineering. In 2009, there were only 11 US universities that offered a bachelor’s degree in systems engineering [9]. Professionals usually start off doing something else and gradually become systems engineers. This career migration is normal for systems engineers but anomalous for how other engineers progress in their careers – a fact that confuses many.

Given that most systems engineers begin their careers in another profession and that most practicing systems engineers do not ever have the formal title systems engineer, it is natural to ask how one spots a real systems engineer. If The Paradoxical Mindset of Systems Engineers does nothing else, we hope it helps the community answer that question. We explore this question in depth over the course of the book, but we could begin by defining a practicing systems engineer simply as someone who performs systems engineering activities most of the time in their current professional life [10]. This somewhat tautological definition begs the question – which activities are systems engineering activities? Chapter 3 answers that question by identifying the major systems engineering activities and grouping them into 15 different roles that systems engineers perform. Hence, the definition of a practicing systems engineer evolves into something more satisfying:

Of course, unless you peek ahead now to read Chapter 3, the specifics of those roles will just have to wait.

BOOK STRUCTURE

CAREER DEVELOPMENT “ECOSYSTEM” FOR SYSTEMS ENGINEERS

Figure 1.1 reflects the ecosystem in which systems engineers advance their careers [14]. This is the primary story of The Paradoxical Mindset of Systems Engineers. An EFFECTIVE SYSTEMS ENGINEER consistently delivers value while working in ROLES AND POSITIONS assigned by the ORGANIZATION. Proficiency is impacted by FORCES that an individual encounters – experiences, mentoring, and education & training. The INDIVIDUAL SYSTEMS ENGINEER conducts PERSONAL DEVELOPMENT INITIATIVES and can take advantage of ORGANIZATIONAL DEVELOPMENT INITIATIVES to improve proficiency. These initiatives generate FORCES that impact PROFICIENCY. The INDIVIDUAL SYSTEMS ENGINEER has PERSONAL CHARACTERISTICS that influence the impact of FORCES. The ORGANIZATION has ORGANIZATIONAL CHARACTERISTICS that influence the impact of the FORCES. Both PERSONAL ENABLING CHARACTERISTICS and ORGANIZATIONAL CHARACTERISTICS impact CONSISTENT DELIVERY of VALUE. Among all these influences and impacts, the challenge for the individual systems engineer and the organization is to improve the PROFICIENCY that enables CONSISTENT DELIVERY of VALUE to the organization.

Our research has shaped these perspectives, relationships, and insights into a theory we call Atlas, which explains what makes systems engineers effective. The name Atlas was chosen for two reasons: (i) systems engineers figuratively carry the systems world on their shoulders, and (ii) this theory euphemistically is a set of maps or guides that help systems engineers reach their career destination. This book is largely a telling of Atlas in a style intended for broad readership. We reference both Helix and Atlas throughout. It is worth reinforcing that Helix is the project in which we conducted most of the underlying research for this book. From Helix’s inception, Pyster, Hutchison, and Henry were the primary project researchers until Pyster left the project in summer 2016, followed by Henry in summer 2017. At the time of the writing of this book, Hutchison remains on Helix as its principal investigator.

Atlas is a theory of what makes systems engineers effective. Much of that theory was developed as an explicit product of Helix. There are many definitions of theory. Borrowing from Merriam‐Webster, here it means “a set of observations and principles that can be used to explain and predict a class of phenomena” – in this case, the phenomena of systems engineers performing effectively, delivering value.

A SHORT SUMMARY OF THE HELIX PROJECT

Because the data collected and analyzed by Helix is so central to this book, a short description of the project and its data is helpful. Systems engineering is a critical discipline for the US Department of Defense (DoD), and yet DoD does not believe its systems engineering workforce is large enough and effective enough for the many challenges it faces. To help address that belief, DoD has funded Helix through the Systems Engineering Research Center (SERC) [15]. The project name, Helix, came from the view that we would be figuratively examining the “DNA” of highly effective systems engineers. Several technical reports, conference papers, and one journal article have been published over the years. The complete list of publications and several of the publications themselves can be found on the Helix page of the SERC website [16].

Most of the primary data collected came through in‐person interviews with systems engineers, their managers, and their peers. From 2012 to 2015, the Helix team focused on a mixed‐methods approach, combining the development of basic research questions with a grounded theory approach. Grounded theory was invented in the social sciences as a method for developing theory that is “grounded” in systematically gathered and analyzed data [17, 18]. This approach allows the data itself to drive further inquiry, guide categorization, etc.; rather than starting analysis with an existing framework, all of the data is reviewed holistically, and potential areas of interest are coded. Over time, patterns emerge, guiding further data collection and analysis. Starting, as we did with overall research questions, makes the Helix project mixed method as opposed to pure grounded theory.

The project is still ongoing as of the writing of this book. Hence, the dataset continues to grow and evolve. Some basic numbers about the dataset at the start of 2018 are as follows:

1. 363 people, from 23 organizations, were interviewed. Most interviews lasted around 90 minutes and were recorded. Participants were interviewed in individual or group settings, with many participating in a follow‐up interview.
2. Practicing systems engineers and their managers make up 92% of the sample; the other 8% are peers of systems engineers, such as electrical engineers or mechanical engineers, as well as project managers.
3. More than 6000 pages of transcripts and summaries were produced from interview recordings.
4. Around half of the participating organizations are in the defense business sector, either commercial or government; the others are from a mix of the healthcare, transportation, telecommunications, and information technology business sectors.
5. 65% of the systems engineers are categorized as senior, 18% as mid‐level, and the remaining 17% as junior.

Every organization is located within the United States. Several are headquartered outside the United States. In those cases, we engaged with systems engineers at a US location. Because the initial motivation for Helix was to understand the effectiveness of systems engineers in the defense community and because DoD funded the work, most of the organizations are from DoD and their contractor community. Nevertheless, data collected from the nondefense organizations is largely consistent with that of the defense companies; e.g. the values that systems engineers delivered and the roles that systems engineers played do not vary across business segments.

Individuals that we interviewed were selected by their organizations based on criteria provided by Helix; i.e. the sample is a reasonable representation of the population as a whole with respect to gender, seniority, diversity of systems worked on, and the diversity of roles played. Moreover, every organization was asked to provide only systems engineers that the organization viewed as effective. The rationale for this constraint was our belief that individuals who were ineffective would likely not provide useful insights or would provide insights that would result in inappropriate recommendations. The Helix team also asked participants to assess their own effectiveness in order to verify the organization’s perspective.

To analyze the thousands of pages of transcripts, we used qualitative data analysis techniques, primarily through data coding. Coding is “a systematic way in which to condense extensive data sets into smaller analyzable units through the creation of categories and concepts derived from the data” [19]. Codes can be layered and evolve over time. The analysis was assisted by the use of a popular qualitative analysis tool, NVIVO [20].

VIGNETTES

As part of our research in writing this book, we also reached out to seven systems engineers from different backgrounds and at different points in their careers. They graciously agreed to be interviewed and provide on‐the‐record accounts of their professional lives and their thoughts on the future of systems engineering, e.g. how they became systems engineers, who their most important mentors were, and what their greatest impact has been. We have inserted short vignettes from these seven people at various places in the book to amplify different points: Michael Celentano, Gina Guillaume‐Joseph, John Hearing, Garry Roedler, Paul Schreinemakers, Jon Wade, and Courtney Wright. More background about them appears in the Appendix.

NOTES AND REFERENCES

1. 1 National Academy of Engineering (2017). NAE Grand challenges for engineering, originally published in 2008 and revised in 2017. https://www.nae.edu/grand‐challenges‐project.aspx (accessed 29 November 2017).
2. 2 Michigan State University (2017). T‐Academy 2017. http://tsummit.org/t (accessed 29 November 2017).
3. 3 Hanson, M.T. (2010). IDEO CEO Tim Brown: T‐Shaped stars: the backbone of IDEO’s collaborative culture. http://chiefexecutive.net/ideo‐ceo‐tim‐brown‐t‐shaped‐stars‐the‐backbone‐of‐ideoae%E2%84%A2s‐collaborative‐culture (accessed 29 November 2017).
4. 4 President’s Council of Advisors on Science and Technology (2014). Report to the President – Better health care and lower costs: accelerating improvement through systems engineering. https://obamawhitehouse.archives.gov/sites/default/files/microsites/ostp/PCAST/pcast_systems_engineering_in_healthcare_‐_may_2014.pdf (accessed 29 November 2017).
5. 5 International Council on Systems Engineering. www.incose.org (accessed 29 November 2017).
6. 6 International Council on Systems Engineering (2015). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4e. Hoboken, NJ: Wiley http://www.incose.org/ProductsPublications/sehandbook (accessed 23 November 2017).
7. 7 BKCASE Editors (2017). Systems Engineering Body of Knowledge, version 1.9. Hoboken, NJ: Stevens Institute of Technology www.sebokwiki.org (accessed 16 December 2017).
8. 8 Myers, J. (2015). Which country has the most engineering graduates. World Economic Forum. https://www.weforum.org/agenda/2015/09/which‐country‐most‐engineering‐manufacturing‐and‐construction‐graduates (accessed 29 November 2017).
9. 9 Fabrycky, W. (2010). Systems engineering: its emerging academic and professional attributes. Proceedings of the 2010 American Society for Engineering Education Conference and Exposition, Lexington, KY (20–23 June 2010).
10. 10 We consistently use the gender‐neutral plural pronouns they and their in singular form throughout the book when not referring to someone specific. This style has become increasingly common over the past couple of decades, with the practice actually originating hundreds of years ago. Retrieved from https://en.oxforddictionaries.com/usage/he‐or‐she‐versus‐they (accessed 29 November 2017).
11. 11 Dreyfus, S. (2004). The five‐stage model of adult skill acquisition. Bulletin of Science, Technology & Society 24 (3): 177–181. http://bst.sagepub.com/content/24/3/177 (accessed 29 November 2017).
12. 12 Throughout the book, we use the plural form experiences rather than the singular form experience. We are grateful to Nic Torelli, the original government sponsor of the Helix Project, for emphasizing that it is a collection of experiences that shapes an individual, and it is more powerful to emphasize that fact in how we refer to them.
13. 13 INCOSE offers the largest and most well‐known certification program for systems engineers. At the start of 2018, there were approximately 2700 INCOSE certified systems engineers. Retrieved from http://www.incose.org/certification (accessed 29 November 2017).
14. 14 Hutchison, N., Henry, D., Verma, D. et al. (2016). Atlas: The Theory of Effective Systems Engineers, v. 1.0. Hoboken, NJ: Stevens Institute of Technology http://www.sercuarc.org/wp‐content/uploads/2014/05/Helix‐Atlas‐1.0_final.pdf (accessed 16 December 2017).
15. 15 The Systems Engineering Research Center is a Department of Defense University Affiliated Research Center operated by Stevens Institute of Technology. www.sercuarc.org (accessed 29 November 2017).
16. 16 Helix (n.d.). Helix – developing effective systems engineers. Systems Engineering Research Center. http://www.sercuarc.org/projects/helix/ (accessed 16 December 2017).
17. 17 Creswell, J. and Clark, V.P. (2011). Designing and Conducting Mixed Methods Research. Thousand Oaks, CA: SAGE Publishers.
18. 18 Goulding, C. (2002). Grounded Theory: A Practical Guide for Management, Business and Market Researchers. Thousand Oaks, CA: SAGE Publishers.
19. 19 Lockyer, S. (2004). Coding Qualitative Data. In: The SAGE Encyclopedia of Social Science Research Methods (ed. M.S. Lewis‐Beck, A. Bryman and T. Futing Liao). Thousand Oaks, CA: SAGE Publications.
20. 20 Managing and analyzing large unstructured datasets efficiently is daunting without automated support. There are a number of tools available to support such management and analysis. One of the more popular is NVIVO. Retrieved from http://www.qsrinternational.com/nvivo/nvivo‐products (accessed 29 November 2017).