“Elegance” in engineering design is an ineluctable concept; it is immediately apparent when it exists, yet it is difficult to define, impossible to quantify… It is offered here that, properly understood, system[s] engineering at its core is concerned with attaining elegant designs.

– Former NASA Administrator Michael Griffin

Recall that in Chapter 1, we said:

We also said that in Chapter 3, you would find out those 15 specific roles. Well, the wait is over!

Systems engineers occupy positions in companies, such as chief systems engineer, systems engineer level 3, requirements analyst, or product architect. These are the job titles that human resources departments recognize or that appear on business cards. Every company has its own set of titles – there is no standardization across organizations or business segments.

Standardizing position titles is not important, but it is critical here that we have standard ways to describe what systems engineers really do. From the Helix interviews, 15 standard roles emerged. A role is a related set of systems engineering activities. A person occupying a single position usually plays several roles. For example, it is common for a senior systems engineer to simultaneously perform several roles such as being a TECHNICAL LEADER and an INSTRUCTOR/TEACHER, all wrapped into a single position. Over the course of their career, a systems engineer will normally hold many positions with different combinations of roles for each one. In fact, in our data, it was uncommon for a systems engineer to play only one role at a time. The exception is at the beginning of their career or during short, specialized assignments.

This chapter walks through how each role is defined, elaborating with examples. Many of the roles originated with Sarah Sheard’s seminal work [1, 2], although the terminology and descriptions have been updated or refined here in a few cases. Several roles are new, reflecting our learnings. Figure 3.1 shows the context in which systems engineering is performed. There are several important elements captured in the figure: (i) systems need to be developed; (ii) engineering teams develop these systems, and systems engineers play a role in these teams; (iii) these activities occur in the context of the organization that is developing the system; and (iv) that organization will have policies on how engineering is conducted as well as a definition and view on the value that systems engineering provides. This context impacts the engineering teams.

The roles themselves are divided into three categories reflecting their differing focuses:

• Roles focused on the systems being developed: In the context of Figure 3.1, these roles specifically support how systems are developed; they are defined by engineering processes. Eight of the 15 roles fit into this category. They align closely with the product development lifecycle and activities that systems engineers enable throughout the lifecycle. They match with other resources such as the ISO/IEC/IEEE 15288 standard [3] and the INCOSE Systems Engineering Handbook [4]. When people think of systems engineers and the technical work that they do, these roles are generally ones that first come to mind.
• Roles focused on systems engineering process and organization: In Figure 3.1, these roles are for individuals who influence the Engineering Process & Policy as well as the Definition & Value of Systems Engineering. These roles focus on the organizational context in which systems engineering occurs and the role of systems engineers in providing guidance on how systems engineering should be used. People performing these roles help others understand what systems engineering is, why it is important, and how an organization can use systems engineering to its best advantage.
• Roles focused on teams that build systems: If the Engineering Teams box in Figure 3.1 were expanded, it would reveal positions that make up the entire engineering team. Systems engineering is an intensely social discipline. As we have heard in many settings, “Systems engineering is a contact sport.” Today’s systems cannot be built by a single person. The roles in this category focus on enabling diverse, multidisciplinary teams to be successful.

Much has been written about what the “real” systems engineering roles are. Michael Griffin, for example, has said [5]:

Properly understood, system[s] engineering is concerned with context over structure, with interactions over elements, with the whole over the sum of the parts.

When this is understood, it becomes immediately apparent that the systems engineering ‘process’ bears the same relationship to system[s] engineering that financial ‘accounting’ does to financial management. Careful financial accounting is an essential element of a good financial management plan; however, accurate accounting cannot distinguish between a good plan and a poor one, and it cannot make a bad plan better. Similarly, understanding and control of system interfaces, development of comprehensive test and verification plans, and proper allocation of requirements are among the things which are crucial to good system[s] engineering; however, they do not help to distinguish a good design from a poor one, nor can they make a poor design better.

…

‘Elegance’ in engineering design is an ineluctable concept; it is immediately apparent when it exists, yet it is difficult to define, impossible to quantify … It is offered here that, properly understood, system[s] engineering at its core is concerned with attaining elegant designs.

As we interviewed many accomplished systems engineers, they viewed their discipline broadly – it encompassed all three types of roles. Griffin focuses on the first type – on the system being developed. He is correct that nothing will make up for a poor design. No process, no team, and no organization can compensate for a poor design. Good, even elegant, design is needed for a truly successful product. He properly bemoans the fact that, in some organizations, a focus on process, organization, and teamwork have overshadowed technical excellence. Yet, our research shows that performing well on all three types of roles is essential. Failing to do well in any role can negatively impact a business.

ROLES FOCUSED ON THE SYSTEMS BEING DEVELOPED

Table 3.1 presents the eight roles focused on the systems being developed, which align with the systems lifecycle shown in Figure 3.2.

To better explain these eight roles, we rely on the Vee systems lifecycle model, originally popularized by Kevin Forsberg and Harold Mooz. The Vee has subsequently been written about in many books and articles [7]. While there are many systems lifecycle models, the Vee is certainly one of the most popular. Yet, it is worth noting that there are seemingly as many variations of the Vee as there are users. People have routinely taken the original Vee model and adapted it for their own purposes – as we are doing here.

The left side of the Vee in Figure 3.2 shows the primary analysis and synthesis activities of development organized into phases up through design. Implementation of the various system components is at the bottom of the Vee and is not usually considered a systems engineering activity. Running up the right side of the Vee are the various activities to put components together and confirm they work as expected and needed. Simplistically, the Vee is written as if the phases are sequential. In practice they are done with varying degrees of parallelism and iteration. The Vee is really a relationship model rather than a temporal model.

When we first identified roles for systems engineers, CONCEPT CREATOR was absent. Early in our research, none of the people interviewed said they had invented the original concept from which the system eventually sprung. Others in their companies had that responsibility, or their customer might develop that vision and communicate it to them – but they did not personally shape the concept. Interestingly, most government systems engineers felt the same way – the vision for a system was decided before they became involved. All the systems engineers saw their lack of involvement in shaping the system vision as problematic because oftentimes the concepts they were given did not take into account holistic system perspectives.

When we reviewed the roles with several leading systems engineers and researchers, they stated that CONCEPT CREATOR was a legitimate systems engineering role. Yet, they recognized that people who play that role rarely hold the title systems engineer. In start‐up companies, the CONCEPT CREATOR is usually the founder(s). In more mature organizations, they may have titles with the word design or designer in them; e.g. Jony Ive’s title at Apple is Chief Design Officer. Sometimes the CONCEPT CREATOR is the chief technology officer, vice president of product development, or some such title that does not even include the word engineer. As we expanded the variety of organizations in our sample, we encountered individuals who played this role.

The person who performs the CONCEPT CREATOR role thinks up the ideas that shape the system. This is the most creative and inspirational role that anyone involved with a system plays. In its highest form, it is Henry Ford conceiving of the Model T and mass production of automobiles. It is Joseph Licklider conceiving of the computer network that would someday become the Internet [8]. It is Steve Jobs conceiving of the iPod and iTunes. These concept creations changed the world. It is Percy Spencer inventing the modern microwave oven in 1945 from radar technology developed during World War II (although legend has it that he discovered it by accident) [9]. We doubt any of these people ever described themselves as systems engineers.

Recently, the term design thinking has come into vogue, with many universities offering courses or even full programs on this topic. The term was popularized by Stanford University and the company IDEO. Today, courses and programs can be found at such leading universities as Harvard, MIT, Northwestern, Stanford, and the University of Southern California. Toshiaki Kurokawa identified 32 leading design thinking academic programs from around the world [10]. In 2015, Cliff Whitcomb, a professor at the Naval Postgraduate School, gave an excellent talk explaining the relationship between systems engineering and design thinking, which is defined as “the combination of the processes, skills, cognitive processes, and attitudes prevalent in design” [11]. The Naval Postgraduate School has long had a strong systems engineering program. They include design thinking as a particular systems engineering approach that has been successfully integrated into their curriculum. CONCEPT CREATOR is one of the key roles in design thinking, incorporating specific approaches, tools, and techniques.

In some communities, system architects are not considered to be systems engineers. For them, SYSTEM ARCHITECT is not a systems engineering role. Eberhardt Rechtin is often called the “Father of the Deep Space Network” for his work at the Jet Propulsion Lab. He held several leadership positions in both the US government and industry, including the Director of what would later be known as the Defense Advanced Research Projects Agency (DARPA). Rechtin was a pioneer of the field of systems architecting, authoring two definitive early books on the topic [12, 13]. Rechtin maintained that systems architecting began as part of systems engineering but evolved into its own separate discipline. His argument was somewhat analogous to that often presented for why CONCEPT CREATOR is not viewed by some as part of systems engineering – it is too much art to be considered engineering. However, INCOSE considers systems architecting to be part of systems engineering in its Handbook as does the SEBoK. We accept INCOSE’s perspective on system architecting – a perspective that also reflects our Helix data. Forty percent of interviewees played the role of SYSTEM ARCHITECT at some point in their careers.

Mike Celentano, in his interview, described a position he had at Roche several years ago where he had one of the biggest personal impacts of his career. That position included most of the roles that focus on the system being developed:

Several years ago, Roche Diabetes Care was working on their second‐generation technology. It was a completely new platform development with new analog front end, new chemistry, …, new meters, new interface. Everything was new, new, new. Every five to ten years or so we do that. … This was a new generation, which is an exciting time to be involved. I was the technical leader for the instrumentation – software and hardware. I had to work with technical leaders for strip production and … chemistry … to come up with the new platform. That was an exciting time. … It had a huge impact. It ended up giving us another ten years of life in our company. Billions of dollars worth of business. Helping millions of people out with their diabetes – that was good. I … help[ed] make tradeoff decisions [on how various elements of the design interacted] with the chemistry and the strip part … That was fairly complex … We still have product on the shelf sold in drugstores over the world, and that makes me happy.

ROLES FOCUSED ON SYSTEMS ENGINEERING PROCESS AND ORGANIZATION

Table 3.2 presents the two roles focused on systems engineering process and organization.

When Helix began, we did not anticipate the first role in Table 3.2. Interviews with many systems engineers revealed that in some organizations the value of systems engineering is not widely or consistently understood. In these organizations, systems engineers spend significant time articulating values that systems engineering brings. Starkly, one systems engineer said that her project manager would tell her to “go off in [her] corner and work on [her] requirements and he would let [her] know when he needed them.” Championing can occur at the individual project level up through the entire organization. The need to champion systems engineering reflects the immaturity of how systems engineering is viewed in some organizations. In contrast, in one organization, systems engineering was cited as “the way we do things around here.” There, where the value of systems engineering had been widely internalized, almost no interviewees reported playing the role of SYSTEMS ENGINEERING CHAMPION. This role is a reflection of the variation in how well systems engineering is understood by the broad engineering and management community. It is inconceivable that today’s electrical engineers, mechanical engineers, or software engineers would have to champion the value of their disciplines.

In his interview, Paul Schreinemakers highlighted an example of championing systems engineering during his days working on the Dutch Railway:

We created guideline[s] for systems engineering clarifying what systems engineering means for the rail, road and waterway industries in the Netherlands. We were introducing and really making the application of system architecture in the rail industry. It was quite amazing – that’s when they really started to understand how their system truly worked from a systems perspective.

A SYSTEMS ENGINEERING CHAMPION has to make the case for systems engineering in such a way that these benefits become visible.

When we talked with project managers about systems engineering, many shared that at some point earlier in their career they believed that systems engineering was all about process – an extra layer of required process that slowed down progress. It was, in effect, more of a “tax” on their projects than a benefit. This was felt to be particularly true when systems engineering work was measured by documents rather than the thought that went into creating those documents. As President Eisenhower once said, “Plans are useless, but planning is everything.” Likewise, in systems engineering, the benefit often comes from the thinking and work that goes into exploring the systems space. This benefit was often lost on others when all they saw were the resulting documents.

We asked project managers who supported systems engineering what had won them over. They offered different reasons, but there was a common pattern: a systems engineer who was assigned to their project somehow directly benefited the project and the manager. For one project manager, it was a systems engineer putting together a few slides and holding a 30‐minute discussion to explain how a persistent problem on the project could be solved through systems engineering. For another, it was someone solving a few gnarly problems directly – without calling the effort systems engineering. In this case, after the problems were solved, the systems engineer explained how the systems approach actually enabled solutions to be discovered and implemented. The pattern is simple: systems engineers help people get past their perceptions of systems engineering as a heavy‐handed process focused on generating documents. Instead, they show them true value.

Centered on how systems engineering “happens,” the second role in Table 3.2, PROCESS ENGINEER, is common in many organizations. Pyster played that role in several organizations in which he worked, either directly or by managing a group that included people who performed process engineering. For example, at SAIC, one of Pyster’s responsibilities was to lead systems engineering process improvement activities across the corporation. He chaired a committee with members from different business units. That committee developed tailorable process assets that were adapted and applied by projects in those business units.

Process engineers often partially rely on community‐developed process improvement frameworks to guide their efforts. Pyster oversaw the creation of the Systems Engineering Capability Maturity Model (SE‐CMM) [14], the product of a collaborative development across several organizations. The SE‐CMM extended to systems engineering the groundbreaking Capability Maturity Model for Software (SW‐CMM) [15], developed by a team led by the late Watts Humphrey at the Software Engineering Institute. The SW‐CMM has had broad impact on software development worldwide. It offered a specific and repeatable way to assess the maturity of a software development process. That assessment includes specific actions an organization can take to address shortcomings. The SE‐CMM was an important transitional step toward two subsequent multidisciplinary CMMs. The first, the FAA integrated Capability Maturity Model (FAA‐iCMM), first published in 1997, combined systems engineering, software engineering, and software acquisition processes. The model was developed by a team from across the FAA [16]. The second, the Capability Maturity Model Integrated (CMMI) [17], was published in 2000 by a community team led by the Software Engineering Institute and superseded the FAA‐iCMM.

The 1997 development and subsequent use of the FAA‐iCMM came about as a direct response to a variety of challenges that the FAA had been facing in delivering major new systems to safely and efficiently manage and control air traffic in the United States. The FAA had recently experienced a very public multi‐billion‐dollar failed acquisition – the Advanced Automation System (AAS) [18]. As a consequence of that failure, the FAA took a number of steps to revise how it acquired major air traffic systems, including a focused effort to improve its acquisition processes. One of those steps was to develop a single integrated framework that could be used to assess existing acquisition processes and to guide their improvement. It was increasingly recognized across the process improvement community at that time that having multiple separate process improvement frameworks was problematic. An integrated approach was needed. The FAA‐iCMM was the FAA’s response to that need and was subsequently used by many FAA organizations to improve their systems acquisition and systems maintenance processes. Each organization had its own team of systems engineers performing the PROCESS ENGINEERING role, guiding their organizational improvement efforts.

ROLES FOCUSED ON TEAMS THAT BUILD SYSTEMS

As stated throughout this book, systems engineers do not exist in isolation. Systems engineering is, by definition, a discipline that requires continual interaction with a diverse set of individuals. Table 3.3 presents the five roles focused on the teams that build systems.

Being an effective CUSTOMER INTERFACE is often hard work. During her interview, MITRE principal systems engineer Gina Guillaume‐Joseph recounted a recent experience:

I’m in the DC Metropolitan Area … doing … mission stakeholder analysis and requirements analysis for my sponsor. … About two years ago, we started on this project to … get an understanding of their systems, their stakeholders, the reason why the first crack at building this system failed. … We devised a framework to interview them, all the stakeholders, to find who the stakeholders are, to understand what their mission was and to tease out some of their requirements. … [When] we presented the framework …, they said that we were over‐engineering the task. They had the [Request for Information]; they had this core set of requirements; they thought that that was all that was needed. … We had to explain to them that … there’s more to it; we’ve got to understand your stakeholders; we’ve got to understand the mission; … we have to understand how each stakeholder interacts with the system, and then we want to then develop a robust set of requirements that would feed into [the] Request for Proposals. … They pushed back, but we moved forward; we included all the stakeholders in our requirements gathering; we reviewed requirements with them. They gave us feedback; they removed; they identified; they modified. …

We were able then to develop a robust set of requirements for incorporation to the acquisition package. … They were able to successfully select a vendor, award, on budget, on time. And yesterday I’m on another task for this sponsor …, and we were in the same room with our core stakeholders, and they said that they were really glad that we did the … type of analysis that we did up front, because the vendor that they selected has been doing a fantastic job in developing this system.

And they basically thanked our team – going from ‘you’re over‐engineering a task,’ ‘we’re not happy,’ ‘this is taking too long,’ ‘we’re not going to meet our award,’ to ‘Wow! Thank you.’ And the vendor is ahead of schedule, currently.

The inclusion of one role among these five elaborated here, INSTRUCTOR/TEACHER, may be surprising. However, many senior systems engineers teach in‐house training courses on the unique systems engineering variant practiced locally, the types of systems on which the organization works, and on key technologies on which those systems depend. These insiders are often valued as teachers over outside experts because they understand the organization’s products and services as well as its processes, structure, and culture. These insiders have credibility and authoritativeness that outsiders lack. For example, Roche principal systems engineer Mike Celentano, who helped lead the development of Roche systems engineering practices, said in his interview that he periodically taught internal systems engineering courses, something he enjoyed immensely. His deep experiences within Roche practicing systems engineering on a variety of their important products gave him added credibility when he taught. Those experiences enabled him to make the curriculum just right for the Roche engineers who were his students.

RELATIONSHIP BETWEEN ROLES AND VALUES

How do the roles described here relate to the values described in the last chapter? In essence, it is by playing these roles that a systems engineer will deliver the values identified in Chapter 2. There is not a 1 : 1 relationship, with a single role mapped to a single value. Instead, many roles come together to create value.

As an example, take Value 1: keeping and maintaining the system vision. There is no one role that fully addresses this. The CONCEPT CREATOR is part of this – a concept creator develops the overarching vision for a system that can address the problem space. But that vision, as discussed above, means nothing if people do not understand it. To keep and maintain this vision, it also has to be shared with and understood by the teams working on the system. This requires a COORDINATOR who will ensure that diverse interdisciplinary teams understand the vision. It requires that the vision be agreed to by the customer – requiring a CUSTOMER INTERFACE role; and this must be taken into account when trade‐offs are considered by playing the TECHNICAL MANAGER role.

It is important to note that no single individual will play all these roles at once. Systems engineers work in teams. Particularly in larger organizations that may have more staffing, it would be perfectly normal for team members to perform different roles. By recognizing that the total set of necessary roles must be performed by the team as a whole, everyone involved can better manage expectations. No single systems engineer has to be a superhero who can do everything. The team collectively gets the job done.

ART PYSTER AT DIGITAL SOUND CORPORATION

To illustrate several roles wrapped into a single position, consider a position held by Pyster. In the middle 1980s, Pyster worked at a commercial telecommunications company in Santa Barbara, California – Digital Sound Corporation (DSC). DSC was a pioneer manufacturer of voice processing computer systems, most prominently an early voicemail system that was sold to telecommunications service providers and to individual companies. Of course, today, voicemail is taken for granted as a relatively simple and ubiquitous application – but not back then. In the middle 1980s, voicemail was novel and a single instance that could interface with telephone switches cost tens of thousands of dollars. It included custom hardware, novel digital signal processing algorithms, a custom real‐time operating system, complex application software, and special user interfaces. Pyster served in the position of a multi‐hatted engineering director, with five primary responsibilities as shown in Table 3.4. At the time, Pyster did not use the term systems engineer to identify himself. Looking back, that is primarily what he was.

A few things are worth noting about Pyster’s position, which included these five responsibilities:

1. While holding this single position, Pyster performed 7 of the 15 standard roles. It is common for mid‐level and senior systems engineers to perform several roles simultaneously.
2. Four of the five responsibilities involved the role of TECHNICAL MANAGER, reflecting the fact that Pyster managed several people throughout in the performance of their technical responsibilities.
3. At that time, Pyster was a mid‐level manager in DSC, performing a mix of higher‐level and lower‐level activities. He personally wrote numerous system test scripts, conducted many of the system tests, and developed tools that automated many product tests. He also worked extensively with the Vice Presidents of Engineering, Manufacturing, and Marketing on strategies to develop, deliver, maintain, manufacture, and market voicemail products.
4. Pyster supervised people responsible for taking the “out‐of‐the‐box” version of Unix^® from Bell Labs, which was intended for time‐sharing, and turning it into a real‐time operating system, which could meet hard real‐time deadlines for critical functions of the voicemail system. The operating system was an important subsystem in the overall system architecture. Pyster did not personally architect or implement the changes. Those working for him did.
5. These five responsibilities, especially 1, 2, 4, and 5, had high degrees of interaction. DSC’s CEO demanded the system be developed so there was no significant delay between the end of engineering development and first product shipment. Test and manufacturing activities had to be done concurrent with engineering development to meet this direction. This concurrency required a lot of innovation in the engineering process at a time when Waterfall [19] was the normal model in system development projects. Pyster joined DSC from TRW, where he had worked under Barry Boehm developing what were at the time novel software development processes and tools [20], including an early prototype version of what became the Spiral process [21]. The DSC process expanded beyond software to a full systems process. It included a variant of spiral development, daily builds, rigorous configuration management of all aspects of the system, highly automated regression testing, and system test concurrent with engineering development. The result of this innovation was DSC being able to ship its first voicemail product with very few defects (almost all of which were known and categorized as low priority before shipment) soon after engineering development was completed. DSC regularly shipped low‐defect incremental releases thereafter that added features, improved system cost and performance, and addressed residual defects.

SYSTEMS ENGINEERS OFTEN PERFORM MANAGEMENT ROLES

Positions filled by systems engineers routinely involve non‐systems engineering roles as well. Two that we have commonly observed are both management related:

• ORGANIZATIONAL/FUNCTIONAL MANAGER: Individual who is responsible for the personnel management of systems engineers or other technical personnel in a business setting – not a project or program setting.
• PROGRAM/PROJECT MANAGER: Individual who has overall responsibility for the performance and success of a program or project but is usually not directly responsible for the technical content; the manager works closely with technical experts and systems engineers while maintaining overall project cost and schedule.

A recently published book, Integrating Program Management and Systems Engineering, edited by Eric Rebentisch, is a joint publication of INCOSE, MIT, and the Project Management Institute (PMI) [22]. PMI is well known for its Project Management Body of Knowledge [23] and certification of project managers [24]. As its title implies, the book explores the relationship between systems engineering and program management. It focuses on how they can be effectively integrated in both programs and projects and why that integration is so important. One key recommendation the book makes is that to achieve better program performance, organizations should be clear on what systems engineers do versus what program/project managers do, be clear what each is responsible for, and also identify where they have shared activities and shared responsibilities, e.g. in managing risk. Chapter 9 further explores the relationship between systems engineers and program/project managers.

SENIORITY

Some positions and some roles occur more naturally at the beginning of a career and some after many years of diverse experience and growing responsibility. For example, someone new to the profession typically spends time as a DETAILED DESIGNER, providing technical designs that elaborate the system architecture. That person usually works as an individual contributor. They would probably not think of themselves as a systems engineer. Neither would their employer. Rather, they are an electrical engineer or a software engineer, or some other classic engineer. As a new software engineer, they might be responsible for testing code written by others or writing code that implements modules designed by more senior software engineers. As a new electrical engineer, they might be responsible for testing circuits designed by others or implementing a circuit board designed by more senior electrical engineers.

New professionals do not generally have responsibility as a TECHNICAL MANAGER or INSTRUCTOR/TRAINER. They grow into those roles over time based on experiences, performance, and opportunity. They rarely start off in a CUSTOMER INTERFACE role. Such a role is challenging and can have enormous impact on project success; missteps can seriously harm a project. A deep understanding of the customer, the system, the business domain, and the company, a sense of maturity in dealing with difficult customers, judgment on how to negotiate and influence, and numerous other proficiencies are critical to success and are typically not possessed by people fresh out of college.

On the other hand, it is rare to see someone with 25 years of experience personally doing much, if any, detailed design. They are much more likely to be leading a team of more junior people who do that detailed design, or perhaps they will be part of the team responsible for the concept of operations for a system or for its overall architecture.

The roles defined here reflect the spectrum of systems engineering activities that an individual can perform, from the newest novice to the most seasoned chief systems engineer. This does not mean that systems engineers play all of these roles all of the time. More novice systems engineers are likely to play specific roles: a supporting role as a REQUIREMENTS OWNER, working as a SYSTEM ANALYST, or being a DETAILED DESIGNER and developing baseline engineering capabilities. Over time, these roles tend to become less frequent while others emerge. In our sample, systems engineers became TECHNICAL MANAGERS or SYSTEM ARCHITECTS usually in their third to fifth jobs. More detailed Roles Focused on the System Being Developed – SYSTEM ANALYST, DETAILED DESIGNER, V&V ENGINEER, and SUPPORT ENGINEER – become less common over time, while roles emphasizing leadership – CONCEPT CREATOR, SYSTEM ARCHITECT, and SYSTEM INTEGRATOR – become more common together with team‐focused roles such as COORDINATOR and CUSTOMER INTERFACE. Generally, only more seasoned systems engineers are asked to develop and manage processes. Interestingly, systems engineers at any stage of their career can be a SYSTEMS ENGINEERING CHAMPION. The scope of influence will be different, but a junior systems engineer who demonstrates how a systems approach provides insight is championing systems engineering on their team just as much as a chief systems engineer who interfaces directly with executives.

As systems engineers traverse their careers from entry into the workforce up through retirement, a continual maturation is reflected in the breadth and depth of their proficiencies, the types of roles and positions they play, and the values that they provide and that are expected from them. Categorizing systems engineers based on seniority that reflects that maturation enables patterns to be identified across systems engineers and insights to be drawn from them. Companies naturally do this, of course, using a variety of terms and differing number of seniority levels. Some companies have a minimalistic approach, with just three or four levels. Others have seven or even more levels in which they place their staff. People in different levels naturally find themselves with different pay scales, office conditions, bonus potential, job assignments, and a myriad other differentiators driven by culture and business practice. Such distinctions are important in the workplace. As will be described shortly, The Paradoxical Mindset of Systems Engineers takes a minimalistic approach – just three levels of seniority: JUNIOR, MID‐LEVEL, and SENIOR. That does not mean we recommend that a company have only three levels. It is just that our purposes here do not require the added complexity that comes from greater stratification.

Our seniority categorization framework reflects an integration of approaches from several sources, including data collected during Helix interviews, frameworks published by the INCOSE UK Chapter [25] and NASA [26], and a framework developed by a DoD‐sponsored research project led by Wilson Felder at Stevens Institute of Technology [27]. The latter project focused on how to develop technical leaders for DoD, but the findings are broadly applicable to other businesses and business sectors.

The INCOSE UK Chapter framework identifies four seniority levels, adapted as follows:

• Awareness: They can understand the key issues and their implications. They can ask relevant and constructive questions on the subject. This level is aimed at people who interface with systems engineers but may not be systems engineers themselves.
• Supervised practitioner: They display an understanding of the subject but require guidance and supervision. This level defines those systems engineers who are “in training” or are inexperienced.
• Practitioner: They display detailed knowledge of systems engineering, can operate independently, and can provide guidance to others.
• Expert: They display extensive and substantial practical experience and applied knowledge.

Note that the lowest of the four levels is intended for people who may not actually be systems engineers. This framework speaks about knowledge and experience but not explicitly about cognition or skills, which seem to be implicit consequences of knowledge and experience. The INCOSE UK Chapter framework goes on to examine specific proficiencies. For each one, it describes what is expected of a systems engineer at each seniority level.

The NASA framework, summarized in Table 3.5, also has four levels, which are tied to NASA’s specific position titles, e.g. technical engineer or project systems engineer. This contrasts with the INCOSE UK Chapter framework, which is more generic because it is intended for widespread application in many companies and business sectors.

The full seniority‐level descriptions summarized in Table 3.5 are more detailed than those in the INCOSE UK Chapter framework. They provide a steady ladder of growth around complexity of assignments, leadership roles, phases of the lifecycle in which the systems engineer has worked, and the enterprise level to which the systems engineer contributes.

Finally, Felder’s research on technical leaders offers three seniority levels – junior, mid‐level, and senior as captured in Table 3.6.

A very interesting and perhaps counterintuitive aspect of the three frameworks above is that none explicitly use years of experiences to categorize seniority. A systems engineer does not need to spend a minimum amount of time as less senior before they can become more senior. In many communities, years of experiences is an explicit requirement for a certificate, license, position, or promotion. For example, INCOSE certifies individuals as systems engineering professionals at one of three different increasingly demanding levels. A minimum number of years of relevant professional experiences is an explicit requirement for the highest two levels [28]. The underlying assumption driving this requirement is the belief that people must work a certain length of time to truly master a profession. There is no substitute for time on the job. Length of time in a profession becomes a surrogate for achieving a specific level of proficiency in a field.

We have held many discussions over time around the world with industry, academic, and government leaders on how much professional experience someone must have to even be considered a systems engineer at all. For Pyster, the oldest author, these conversations literally go back decades. This was an emotional topic for many, with voices raised and hands waving throughout the discussion. Many said that someone should not even be called a systems engineer without 15–20 years of professional experience. They argued that absent such extensive experience, a person simply could not have the perspective and wisdom that come from many successes and failures. The term scar tissue was often used, meaning that people learn best from the wounds of occasionally failing. A certain amount of scar tissue over those wounds is essential to being an effective systems engineer. Henry Petroski’s classic book, To Engineer Is Human: The Role of Failure in Successful Design, masterfully makes the case for repeated failure along the way to success. The second chapter of his book is insightfully titled “Falling Down is Part of Growing Up” [29]. We recall a discussion with the CEO of a company that, at the time, had more than 1000 employees whose position titles included the phrase systems engineer. He said the company had fewer than 100 people he considered to be real systems engineers (his term), i.e. people he considered capable of performing systems engineering activities well on large‐scale complex systems. On the other end of the spectrum, some individuals are hired as systems engineers immediately out of undergraduate education.

The question of how much experience someone needs to be a systems engineer has been a lively topic in academic circles. In the United States, about 11 universities offer a bachelor’s degree in systems engineering [30, 31]. This is miniscule compared with classic engineering undergraduate programs; e.g. for the 2014–2015 academic year, the American Society for Engineering Education (ASEE) listed 260 US schools offering a bachelor’s degree in electrical engineering and 288 offering a bachelor’s degree in mechanical engineering [32]. The tiny number of undergraduate systems engineering programs can be attributed to several factors. One that is particularly relevant here is that many in the systems engineering community do not believe in the validity of an undergraduate systems engineering degree. The reason often cited is the view that being an effective systems engineer requires several years of professional experience – scar tissue. Such a requirement, of course, is inconsistent with the general approach toward US undergraduate education, which normally requires no experience or only very modest experience (such as an internship) by the time someone graduates. While the number of undergraduate systems engineering programs continues to remain low, one of the authors, Henry, is now developing a new undergraduate program in systems engineering at Regent University in Virginia. Compelling reasons for this initiative can be traced back to the same interviews that contributed significantly to the writing of this book.

In April 2010, the US Air Force Academy hosted a two‐day workshop on US undergraduate systems engineering programs. That workshop explored the question of the validity and content of undergraduate systems engineering programs at that time [33]. The more than 60 people from US academia, government, and industry who attended did not settle this question – it remains unsettled and controversial even today. The workshop report offered eight key observations, three of which are especially relevant for our purposes and are summarized here. We note that these observations are US‐centric because of who attended the workshop. It would be valuable to host similar workshops outside the United States and see if these observations still hold:

1. Strong demand: Both industry and government have a strong demand for trained, experienced systems engineers, especially those who can think holistically about complex problems, are comfortable with the increasing complexity of systems that address those problems, can manage the uncertainty and complexity of the environment in which those systems are being built, and can respond to demands to shorten the time to deliver systems to the field.
2. Distinction lessens over time: Companies routinely hire engineers with bachelor’s degrees in disciplines other than systems engineering. Those companies subsequently develop them into systems engineers through a combination of in‐house training, graduate education, mentoring, and on‐the‐job experiences. They also hire engineers with bachelor’s degrees in systems engineering but in far fewer numbers. In either case, new hires are treated as apprentices, not as journeymen or experts. Yet, at the workshop, only a rough picture emerged of how those new hires are deployed and which proficiencies developed during their undergraduate education are the most valued. During the first two years after graduation, the distinction between a systems engineering degree and a classic engineering degree is sharpest. By the end of four years of work experience, when the apprenticeship period is often ending, the workshop attendees concluded there is little distinction between engineers who learn systems engineering on the job and those who first learn it as an undergraduate.
3. Real engineers: There was some concern voiced by skeptics of undergraduate systems engineering programs that the programs might be “watered down” with a predominant focus on process and weak on design. That does not appear to be the case. Undergraduate systems engineering programs generally produce “real” engineers, i.e. programs accredited by ABET [34], the official accrediting body for university engineering programs in the United States and more than two dozen other countries. The curricula usually incorporate traditional engineering courses in physics, electronics, calculus, mechanics, chemistry, etc. Graduates are generally prepared to sit for the Fundamentals of Engineering Exam that is required in most states in the United States to become certified as an Engineer in Training, along the way to eventually becoming a licensed Professional Engineer.

Further compounding the challenge of deciding who is a “real” systems engineer, many individuals we interviewed for Helix were introduced to systems engineering, or even to the term systems engineering only at their workplace. Many stated that it was only in hindsight that they recognized themselves to be systems engineers. Since this exposure comes much later in life, middle school or high school students do not generally aspire to become systems engineers. It was also common for individuals who were performing systems engineering roles to identify as classic engineers, reflecting their undergraduate field of study.

We offer three additional observations:

1. With an ABET‐accredited undergraduate systems engineering program, students gain sufficient foundations in science, math, and engineering to increase their depth of knowledge in another field at the graduate level. They are not expected to pursue a master’s degree in systems engineering, although they might pursue a doctorate in systems engineering.
2. In a four‐year undergraduate degree program, there is the possibility of offering 10 or more required or core courses in systems engineering. Thus, an undergraduate program will be able to produce a holistic systems engineer who truly understands and appreciates the breadth of systems engineering.
3. Currently, efforts by INCOSE and ASEE seek ways in which systems engineering can be introduced to every engineer and to expose systems concepts at the K–12 level.

Despite the controversy about how much experience is required to be an effective systems engineer, thousands of people with modest or even no experience hold such positions. We can have (and have had) the argument about whether these people are really systems engineers. These individuals, though young, play supporting roles to other systems engineers – perhaps helping a more seasoned REQUIREMENTS OWNER manage and update a requirements database or doing a small portion of the work for a SYSTEM ANALYST. The fact remains that though many would vehemently deny that these are “real” systems engineers, there are many individuals with five or fewer years of experiences. Both they and their companies believe they are systems engineers. We concluded that the controversy comes about, in part because people often clump all systems engineers together without distinguishing seniority. This clumping confuses everyone. Clearly, no one would trust a fresh graduate to be the chief systems engineer on a multi‐billion‐dollar program to build a huge dam or design a new wide‐body aircraft or a hybrid automobile. The actual chief systems engineers of such efforts have many years of experiences and a deep knowledge of the domain, the market, and key technologies needed for success. When we drew out people who said someone needs 15–20 years of experience to be a systems engineer, they invariably were thinking about people filling those kinds of very senior positions – people at the apex of their careers, exercising enormous authority over large complex projects – people we would call senior systems engineers. Hence the importance of having a way to distinguish the ways systems engineers contribute – junior being the appropriate modifier for someone fresh from undergraduate education but who is still performing systems engineering work.

The career path of physicians offers a good analogy. In the United States, when people graduate from medical school and pass their state medical licensing exam, they are physicians – medical doctors. No one would say otherwise. Yet, they typically are interns first with restrictions on what they are legally allowed to do. Eventually, they become residents who are licensed to practice medicine on their own. They may seek additional licensing as specialists or seek other credentials as part of their career growth. They may eventually become chiefs of staff in major hospitals or otherwise become leaders in their field. For physicians, the path is well structured and highly regulated – more so than in most fields, including either classic or systems engineering; but throughout, they are medical doctors and accepted as such by the community.

There are generally no specific licensing or other requirements that clearly indicate when someone has crossed a line and can officially be called a systems engineer and professionally practice systems engineering. Most systems engineers do not even have a systems engineering degree, creating yet more confusion.

THREE SYSTEMS ENGINEERS WITH INCREASING SENIORITY

To better illustrate what we mean by both roles and seniority, we describe three hypothetical systems engineers, who are largely based on insights from Helix interviews.

NOTES AND REFERENCES

1. 1 Sheard, S. (1996). Twelve systems engineering roles. Proceedings of the 6th Annual International Symposium of the International Council on Systems Engineering, Boston, MA (7–11 July 1996).
2. 2 Sheard, S. (2000). Systems engineering roles revisited. Proceedings of the 10th Annual International Symposium of the International Council on Systems Engineering, Minneapolis, MN (16–20 July 2000).
3. 3 ISO/IEC/IEEE 15288:2015 (2015). Systems and Software Engineering: System Life Cycle Processes. Geneva: International Organization for Standardization https://www.iso.org/standard/63711.html (accessed 29 November 2017).
4. 4 International Council on Systems Engineering (2015). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4. Hoboken, NJ: Wiley. http://www.incose.org/ProductsPublications/sehandbook (accessed 23 November 2017).
5. 5 Griffin, M. (2010). How do we fix system engineering? Proceedings of the 61st International Astronautical Congress, Prague, Czech Republic (27 September to 1 October 2010). https://www.aiaa.org/uploadedFiles/Events/How%20do%20we%20fix%20SE‐Griffin.pdf (accessed 16 December 2017).
6. 6 INCOSE (2014). A world in motion: systems engineering vision 2025. International Council on Systems Engineering. http://www.incose.org/AboutSE/sevision (accessed 24 November 2017).
7. 7 Forsberg, K., Mooz, H., and Cotterman, H. (2005). Visualizing Project Management, 3. New York: Wiley.
8. 8 Internet Hall of Fame (2018). Inductees. http://internethalloffame.org/inductees/jcr‐licklider (accessed 30 November 2017).
9. 9 Tweedie, S. (2015). How the microwave was invented by a Radar Engineer who accidentally cooked a candy bar in his pocket. Business Insider – Tech Insider. http://www.businessinsider.com/how‐the‐microwave‐oven‐was‐invented‐by‐accident‐2015‐4 (accessed 30 November 2017).
10. 10 Kurowaka, T. (2013). Design thinking education at universities and graduate schools. Science and Technology Trends 46: 50–63. http://www.nistep.go.jp/en/wp‐content/uploads/Science‐Technology‐Trends‐Quarterly‐Review‐No.46%EF%BC%8Dreport4.pdf (accessed 16 December 2017).
11. 11 Whitcomb, C. (2015). Design thinking: what is it and what does it mean for systems engineering? Engineering Management and Systems Engineering Videos. 7. http://scholarsmine.mst.edu/engman_syseng_videos/7/ (accessed 30 November 2017).
12. 12 Rechtin, E. (1991). Systems Architecting, Creating and Building Complex Systems. Englewood Cliffs, NJ: Prentice‐Hall.
13. 13 Rechtin, E. and Maier, M. (1997). The Art of Systems Architecting. Boca Raton, FL: CRC Press.
14. 14 Bate, R., Kuhn, D., Wells, C. et al. (1995). A Systems Engineering Capability Maturity Model, Version 1.1. Software Engineering Institute. CMU/SEI‐95‐MM‐003. Pittsburgh, PA. http://resources.sei.cmu.edu/library/asset‐view.cfm?assetid=12291 (accessed 30 November 2017).
15. 15 Paulk, M., Curtis, B., Chrissis, M., and Weber, C. (1993). Capability Maturity Model for Software, Version 1.1. Software Engineering Institute. CMU/SEI‐93‐TR‐024. Pittsburgh, PA. https://resources.sei.cmu.edu/library/asset‐view.cfm?assetid=11955 (accessed 7 March 2018).
16. 16 Ibrahim, L., Bradford, B., Cole, D. et al. (1997). The Federal Aviation Administration Integrated Capability Maturity Model (FAA‐iCMM^®), Version 1.0. Federal Aviation Administration, November 1997. Also, Version 2.0 published in 2001.
17. 17 CMMI Product Development Team (2000). CMMI for Systems Engineering/Software Engineering, Version 1.02, Staged Representation (CMMI‐SE/SW, V1.02, Staged). There have been numerous variations and updates to the CMMI published since it was first released. http://resources.sei.cmu.edu/library/author.cfm?authorID=4783 (accessed 30 November 2017).
18. 18 Gibbs, W.W. (1994). Software’s chronic crisis. Scientific American 271 (3): 86–95.
19. 19 The Waterfall model for software development is widely credited as being the first formal model describing a software development process. The main original paper describing the Waterfall model is: Royce, W. (1987). Managing the development of large software systems: concepts and techniques. Proceedings of the International Conference on Software Engineering, Monterey, CA. Los Alamitos, CA: IEEE Computer Society Press, pp. 328–338. https://dl.acm.org/citation.cfm?id=41801&dl=ACM&coll=DL#URLTOKEN# (accessed 7 March 2018).
20. 20 Boehm, B., Penedo, M., and Stuckle, D. (1984). A software development environment for improving productivity. IEEE Computer Magazine 17 (6): 30–44.
21. 21 Boehm is widely credited with inventing the Spiral model for software development, which has been adapted for use in systems engineering. The primary paper first describing the Spiral model is: Boehm, B. (1988). A spiral model of software development and enhancement. IEEE Computer Magazine 21 (5): 61–72.
22. 22 Rebentisch, E. ed. (2017). Integrating Program Management and Systems Engineering. Hoboken, NJ: Wiley.
23. 23 The PMBOK, published by the Project Management Institute, is the most recognized body of knowledge for project and program management and is widely used around the world. It is now in its 6th edition. Project Management Institute (2017). A Guide to the Project Management Body of Knowledge (PMBOK^® Guide). Philadelphia, PA: Project Management Institute https://www.pmi.org/pmbok‐guide‐standards/foundational/pmbok/sixth‐edition (accessed 30 November 2017).
24. 24 Project Management Institute (n.d.). Certifications. https://www.pmi.org/certifications (accessed 30 November 2017).
25. 25 INCOSE UK Ltd. (2010). INCOSE UK Framework: Systems Engineering Competencies Framework. UK Chapter of the International Council on Systems Engineering. http://incoseonline.org.uk/Normal_Files/Publications/Framework.aspx?CatID=Publications&SubCat=INCOSEPublications (accessed 30 November 2017).
26. 26 Academy of Program/Project & Engineering Leadership (2009). NASA’s Systems Engineering Competencies. Washington, DC: U.S. National Aeronautics and Space Association https://www.nasa.gov/pdf/303747main_Systems_Engineering_Competencies.pdf (accessed 7 March 2018).
27. 27 Felder, W., Yang, S., Pennotti, M. et al. (2016). RT‐149: Leadership Development Framework for the Technical Acquisition Workforce. Technical Report SERC‐2016‐TR‐111. Hoboken, NJ: Stevens Institute of Technology.
28. 28 INCOSE (n.d.). Certification. http://www.incose.org/certification (accessed 30 November 2017).
29. 29 Petrokski, H. (1992). To Engineer Is Human: The Role of Failure in Successful Design. New York: Vintage Books.
30. 30 Fabrycky, W. and McCrae, E. (2005). Systems engineering degree programs in the United States. Proceedings of the 15th Annual International Symposium, Rochester, NY (10–15 July 2005).
31. 31 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).
32. 32 Yoder, B.L. (n.d.). Engineering by the numbers. American Society for Engineering Education. https://www.asee.org/papers‐and‐publications/publications/college‐profiles/15EngineeringbytheNumbersPart1.pdf (accessed 30 November 2017).
33. 33 USAF Academy and SE Directorate (2010). Report of the 1st workshop on U.S. undergraduate systems engineering programs. United State Air Force Academy and Director, Defense Research and Engineering, Colorado Springs, Colorado (7–8 April 2010). http://www.acq.osd.mil/se/docs/ws/Undergraduate‐SE‐Program‐Workshop‐Report‐Final.pdf (accessed 30 November 2017).
34. 34 ABET (n.d.). www.abet.org (accessed 30 November 2017).
35. 35 SEBoK Authors (2017). Systems engineering and management. In: The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 1.9 (ed. R.D. Adcock (EIC)). Hoboken, NJ: The Trustees of the Stevens Institute of Technology. http://sebokwiki.org/wiki/Systems_Engineering_and_Management (accessed 2 January 2018).