One of the things we could benefit from is a little bit more attention to apprenticeship – on the job learning, the student becoming the master kind. … When I do see that happening, I think it is usually a very positive thing.

– Roche systems engineer Mike Celentano

As the old adage goes, “Nothing is constant except change.” In the previous chapter, we saw how someone could document and visualize their PROFICIENCY PROFILE – a snapshot of their strengths and weaknesses at any moment in time. Gradually, that PROFILE will change in ways determined primarily by the application of the three forces explored in this chapter – experiences, mentoring, and education & training – which are listed in order of importance for a systems engineer’s growth based on interviews with more than 350 Helix participants. Figure 7.1 shows a sequence of PROFICIENCY PROFILES that reflect the impact of forces over time.

In this example, proficiency strength changes dramatically over time. For example, TECHNICAL LEADERSHIP begins rather weak as 2 in the first PROFILE but grows to 3 in the second PROFILE and to 5 in the third. However, Figure 7.1 does not reveal the specific forces that caused that sequence of changes to happen, such as earning a master’s degree or taking on a challenging new position. A visualization that captures PROFICIENCY PROFILES at key milestones in someone’s life, together with the specific forces most responsible for those changes, is a map of that person’s career. Figure 7.2 shows such a CAREER MAP (or just MAP, for short) for hypothetical chief systems engineer (CSE), Cathy.

There is a lot of information in Figure 7.2, which will be unpacked incrementally later in this chapter, but first we look more carefully at the three forces.

FORCE 1: EXPERIENCES

For entry‐level professional positions, education is almost always a key hiring criterion – where the new hire went to school, what they majored in, and what grades they got. But even for entry‐level positions, employers look for something else to distinguish between candidates. Were they interns at a local company? Did they participate in student research projects? Did they hold leadership positions in a university club? Any of these extra activities gives the candidates invaluable experiences practicing some of the lessons learned in the classroom. They offer employers a way to differentiate between what may be a large pool of candidates.

Not surprisingly, experiences are by far the most critical force that strengthens proficiencies and has the largest impact on the overall growth of systems engineers [1]. One of the most prominent ways employers judge how effective a candidate might be in a position is the extent and nature of their previous experiences. Well‐written resumes lay out someone’s experiences in a way that catches the eye of a hiring manager. Nearly every job application offers plenty of room for the candidate to explain their experiences in the context of the position being sought.

Experiences matter most; however, there is no clear agreement within the community on how to characterize experiences in a way that provides insight into how they affect proficiencies over time. Experimental literature on experiences has primarily focused on two metrics: time and the frequency of times a specific task or activity of interest was performed. For example, a study by Robert Stuart and Pier Abetti in 1990 (admittedly a bit old, but the primary finding is still quite relevant) looked at what had the greatest impact on the performance of entrepreneurs [2]. Their conclusion was clear:

The number of previous new venture involvements and the level of management role played in such ventures was by far the most significant factor. Other experience factors such as age, years of business, management, and technical experience … were not significantly related to performance.

Heidi Davidz, Deborah Nightingale, and Donna Rhodes explored how to accelerate the development of senior systems engineers [3]. Reinforcing Stuart and Abetti’s findings, they observed that exposure to many diverse job experiences was often the most effective accelerant.

Several organizations we interviewed offered rapid rotational assignments for their high‐potential junior systems engineers. They would typically spend 18–24 months rotating through three or four projects or departments, exposing them to different systems, customers, roles, and technical challenges, all in a compressed timeframe. Individuals who had participated in high‐potential programs, whether they had completed them or were still in them when interviewed, thought the programs were excellent. They valued the diversity and variety of experiences. Rotational assignments are common among leading companies and are even used as a recruiting tool [4]. Interestingly, many senior systems engineers who commented on these high‐potential programs disagreed with their junior colleagues. They believed junior systems engineers moved too quickly from program to program and did not get a proper appreciation of the consequences of their decisions; e.g. if a junior systems engineer played a key role in selecting a controversial technology for a system design, that engineer would be off the project before they could understand how well the selected technology actually worked out. One person said that “you don’t get that emotional punch to the gut” when dealing with a bad decision that was made by someone else.

Additional literature in the field of systems engineering, such as Sarah Sheard’s two papers on systems engineering roles [5, 6] and the Graduate Reference Curriculum for Systems Engineering (GRCSE) [7], argue that while diversity is important, a more refined characterization of experiences is critical to understanding how experiences enable growth. We framed a characterization of experiences first by defining a common unit of measure for experience. Although time is an obvious measure, it was not precisely identified in the interview data we collected. For example, people typically stated a position was held over a five‐year period but did not specify the portion of time spent on particular roles in that position. Because of data limitations, we chose to use a position as the unit of measure for experience.

The employing organization defines roles and responsibilities to be performed by someone filling a position. Throughout their careers, systems engineers typically hold many positions, sometimes in a single company but often across several companies. For example, Pyster has worked as a full‐time employee for eight companies in academia, government, and industry since graduating with a bachelor’s degree in 1971 and has consulted for many more. On the other hand, Henry performed various roles and responsibilities relating to multiple disciplines – over time, all within the same organization. He started with experimental aerodynamics but quickly moved on to aircraft performance, aircraft design, flight testing, project management, program management, finance, and employee welfare as well. During these transitions, he also grew from a junior systems engineer to a mid‐level systems engineer, but never had a systems engineering title.

Someone who is now a systems engineer usually started their career as a classic engineer with a position title such as Electrical Engineer or Software Engineer, perhaps with a qualifier to reflect the type of system on which they worked, such as Communications Software Engineer. Every company has its own position titles. A September 2017 search through job websites monster.com and indeed.com on the term engineer produced such titles as Mechanical Design Engineer, Lead Software Developer, Automation Test Engineer, Project Engineer, and RF Applications Laboratory Engineer. A similar search through monster.com and indeed.com on the more specific term systems engineer produced such titles as Systems Engineer, Cloud Systems Engineer, Engineer Systems 4, and Healthcare Systems Engineer. The variety is endless. We have standardized 15 systems engineering roles in this book, but we have not attempted to standardize position titles, which our interviewees explained were not always consistently applied even within the same organization. To further analyze experiences, we identified the following characteristics:

1. Relevance: Every position contributes to their growth as a person and a professional – some more than others. Not every position is significantly relevant to a systems engineer’s development. For example, an individual might have worked in a bookstore in college – they can certainly learn about professionalism, punctuality, and responsibility, all of which are valuable. But none of those are specifically critical to systems engineering. A relevant position is one that significantly contributes to the strengthening of systems engineering proficiencies identified in Chapter 4. That position need not be one in which systems engineering activities dominate, but it should impact systems engineering proficiencies.
2. Chronological time: The amount of calendar time spent in any particular position or performing a role. This is useful for mapping experiences. One refrain we heard repeatedly in interviews was that “you want someone with 20 years of diverse experience, not one year of experience 20 times over.” Someone who does the same job for 20 years does not bring to an organization the same rich insights from diverse positions as someone who has tried different things and learned from them over time. At the same time, and as noted above, having too little time on particular experiences can also be a detriment. A combination of diversity and some measure of depth – the T‐shape described in Chapter 4 – is critical.
3. Organizational context: The organization in which an individual works has a huge impact on their work and is a critical piece of a systems engineer’s experiences. The most insightful elements of organizational context include:
   • Number of organizations: The number of different organizations at which an individual has worked, not counting internal movement within an organization across departments or divisions, reflects the variety of experiences that one may possess. In large corporations that have multiple business units, or in situations where there are mergers and acquisitions, this number may underestimate the variety of experiences. A person may find it useful to count such organizations separately in such cases.
   • Organizational sectors: There are many differences in an organization based on its business sector. For simplicity here, we only identify three organizational sectors – government, industry, and academia, but clearly, this can be generalized. For example, the US government relies on the North American Industry Classification System (NAICS) to classify millions of businesses in the United States [8] as well as the older Standard Industrial Classification System (SIC) [9]. The more widely used International Standard Industrial Classification System (ISIC) is published by the United Nations [10].
4. Roles: The 15 roles identified in Chapter 3.
5. Lifecycle phases: We use the phases offered by the SEBoK. The titles and descriptions of lifecycle phases or stages vary across different systems engineering processes and frameworks available in literature or in use at an organization. Regardless of which framework and language are used, the phases reflect the “cradle‐to‐grave” engineering approach and the technical management that supports it.

Armed with this framework to analyze experiences, let’s revisit Figure 7.2, Cathy’s CAREER MAP. The x‐axis of the MAP is time in Cathy’s career, marked by years, beginning with entry into professional life and continuing to the current time. While not shown here, a MAP could project into the future to reflect forward planning. The y‐axis of the MAP shows various events – experiences, mentoring, and education & training – that took place during Cathy’s career, organized into different groupings. Let’s examine the elements of Cathy’s MAP from bottom to top:

1. Milestones: The diamonds and circles show key education and experience milestones in her career, respectively. Six are highlighted in the MAP: (i) graduation with a Bachelor of Science in Mechanical Engineering, (ii) graduation with a Master of Business Administration (MBA), (iii) first position as a systems engineer, (iv) first position as a CSE, (v) first time as an organizational manager, and (vi) second position as a CSE, which is important because she stepped away from being a CSE to become an organizational manager and then returned to the more technical role when she moved to a new company.
2. Organizations: Above the milestones are the three telecommunications companies in which Cathy has worked, correlated with the timeline of her career. She has worked only in the telecommunications sector her entire career. She switched to a new organization at the 8‐year point in her career when she first became a CSE and again at the 18‐year mark when she started her second position as a CSE. Identifying some of the organizational characteristics here can also be helpful. Cathy started in a large defense‐focused telecommunications company, moved into a government position, and then moved again into a small company. Why does this matter? Different types of organizations offer different opportunities, exposure to different cultures, systems, technologies, roles, etc. Particularly when planning future career movement, understanding the types of organizations that might offer desired opportunities is important.

   Pyster has had similar variety in his career. Among others, he worked for TRW and SAIC, both large defense contractors; for the FAA, a 50,000‐person US federal agency; and for Digital Sound Corporation, a small telecommunications commercial start‐up company. He benefited from experiencing a breadth of culture, scale, system types, technologies, and other dimensions of those organizations.

3. Positions: Sitting above the bar showing organizations is a second bar showing the 14 positions that Cathy has occupied during her career. Here they are just numbers for ease of viewing in a static figure, but one can imagine tool automation that would allow someone to select a position number and have a window pop‐up providing more information about it. This sequence of positions reveals how quickly Cathy has moved in her career and, to some extent, how much those positions have changed over time. But titles can be tricky – as mentioned earlier, over 40% of the systems engineers we interviewed who identified themselves as systems engineers never had the formal title of systems engineer. In the government, for example, most systems engineers we interviewed were labeled by human resources as general engineers. Boeing senior systems engineer, John Hearing, explained it this way:

   It is one of those things that I … see across industry. Oftentimes, people will not use [the] term ‘systems engineering,’ but will call it something else. I think that is one of our challenges. As an example, I am not trained as a systems engineer. That is not what my degree is nor is it what HR describes me as, but it is the role I fulfill. My master’s degree says space systems and my bachelor’s degree says political science. … There are very few people educated as systems engineers. Many of us have grown into being systems engineers. A lot of times people look at systems engineering as one of those things that is hard to define, and therefore it is easier to define these people as something else – a system analyst, an aerospace engineer, a customer rep or something that is easier to put a label to. A lot of people are doing systems engineering without being called systems engineers.

4. Roles: The roles that Cathy performed are displayed as dark gray bars, which indicate she played the corresponding role in a particular position. Cathy performed 11 of the 15 roles at some point in her career. Note that she was a DETAILED DESIGNER only once – in her second position, but she has been a TECHNICAL MANAGER nine times. This is a common pattern among CSEs. In fact, as reported in the Atlas Career Path Guidebook (or simply “the Guidebook”), most of the CSEs who participated in the Helix study have performed at least 10 of the 15 roles, with TECHNICAL MANAGER being the most common [11].
5. Lifecycle phases: Above the roles are light gray bars showing the lifecycle phases in which Cathy worked at different points in her career. Of the six SEBoK lifecycle phases, Cathy has worked in all of them, something that is uncommon for most systems engineers but certainly reasonable for someone who is a CSE. As reported in the Guidebook, all CSEs in the study have worked in the SYSTEM DEFINITION, SYSTEM REALIZATION, and SYSTEMS ENGINEERING MANAGEMENT phases. In this example, Cathy has worked in the earliest phases of the lifecycle most; in fact, she has worked in the SYSTEM DEFINITION phase in every position she filled throughout her 25‐year career.
6. PROFICIENCY PROFILES: At the top of the MAP is a series of PROFICIENCY PROFILES at the level of abstraction of the six proficiency areas. We show three PROFILES: the leftmost for when she finished her first position one year into her career, the second when she assumed her first role as a systems engineer about 12 years into her professional career, and the third for her current day self. These are Cathy’s self‐assessments – her views on her strengths and weaknesses at different points in her career. Her PROFILE changes significantly over time, reflecting the impact of the three forces through the years. As suggested earlier, with suitable automation, one could imagine selecting a PROFILE and being presented with additional information about categories and topics.

   The role played by Cathy in the position corresponding to the leftmost PROFILE was SYSTEM ANALYST – specifically applying mathematics, physics, and engineering principles to a real system. Her strength for MATH/SCIENCE/GENERAL ENGINEERING, therefore, probably rose during that first year relative to what it was when she just graduated. In Position 1, Cathy gained early experiences, growing to moderate strength working in the SYSTEM’S DOMAIN & OPERATIONAL CONTEXT proficiency area. She was also exposed to the concept of systems engineering and how a system analyst can support systems engineering activities, gaining a moderate level of strength in SYSTEMS ENGINEERING DISCIPLINE.

   The middle PROFILE shows Cathy’s strength as she enters her first CSE position. Analyzing the roles Cathy performed during her first 9 positions, it is clear that she gained strong exposure to a variety of lifecycles and system types. In fact, going into her first CSE position, Cathy has relatively high strength in most areas. Her weakest proficiency is TECHNICAL LEADERSHIP, which is scored at a medium level.

   Finally, the rightmost PROFILE shows that with additional responsibilities and experiences, Cathy generally maintained or strengthened her proficiency with just one exception – MATH/SCIENCE/GENERAL ENGINEERING. This decline results because as Cathy took on increasing leadership responsibilities, she personally performed fewer and fewer detailed engineering and analyses. These skills atrophied somewhat, although they certainly were not lost completely. This was a common pattern seen in many senior systems engineers we interviewed. One senior systems engineer explained that he did not need to do detailed engineering or calculations at his level. He needed to know who could do that work, but he must have a “gut feeling” for whether the answers he receives from those individuals were sensible. Note, however, that as stated in Chapter 2, some community leaders, such as Michael Griffin, strongly frown on systems engineers stepping too far from their technical roots. The better the team surrounding CSEs, the easier it is for them to stay more deeply engaged technically.

One final observation about experiences: A majority of our interviewees said experiences with failure were quite valuable. Several said they learned more from their failures than from their successes. Perhaps Thomas Edison said it best when he described an experience while trying to create an incandescent light bulb:

After we had conducted thousands of experiments on a certain project without solving the problem, one of my associates, after we had conducted the crowning experiment and it had proved a failure, expressed discouragement and disgust over our having failed to find out anything. I cheerily assured him that we had learned something. For we had learned for a certainty that the thing couldn’t be done that way, and that we would have to try some other way. We sometimes learn a lot from our failures if we have put into the effort the best thought and work we are capable of. [12]

FORCE 2: MENTORING

Mark Zuckerberg, the founder of Facebook, considered Steve Jobs to be his mentor. Mother Teresa found a mentor in Catholic Priest Father Michael van der Peet. American singer‐songwriter and musician Ray Charles mentored Quincy Jones. Mentors significantly influence the lives of their mentees. Each one of us probably has had one or more individuals whom we consider to be mentors who positively influenced our professional or personal lives.

Mentoring means so many different things. When mentoring happens in the context of an organization, it adds another dimension to the variety of what mentoring is. Everyone agrees that there are two individuals involved: a mentor and a mentee (or protégé). A mentor is usually the more senior of the two – senior in age, knowledge, experience, and expertise. There is a personal relationship between these two individuals, where the mentor usually gives and mentee receives. Here ends the commonality in what mentoring means.

Many of the distinctions in what people mean by mentoring come from differences in terminology and definitions. Some people use the term mentoring interchangeably with the terms coaching, shadowing, advising, training, and counseling. Others use those terms differently. For example, in discussions with one senior systems engineer, he was surprised that we did not draw a sharp distinction between mentoring and coaching. To him, coaching is done by someone who is part of a systems engineer’s team and works with that person day to day, while mentoring is done by someone from outside the team and works with that person occasionally. We pointed out that for every reference he could cite that distinguished between mentoring and coaching, we could cite one that did not. For example, the National Society of Professional Engineers publishes a variety of online mentoring resources. They offer a very general definition of mentor – “a wise and trusted counselor or teacher” – and state that a mentor provides “coaching” among other benefits [13]. For our purposes here, the more general definition offered by the National Society of Professional Engineers is suitable.

In the context of an organization, there are two broad types of mentoring arrangements: formal and informal. Within a single organization, both types may be offered:

• In formal mentoring arrangements, the organization plays an active role in establishing the mentor–mentee relationship. It lays down guidelines for sustaining that relationship for a specified period of time. This could require the mentor and mentee to explicitly state and mutually agree to objectives and expectations. In some organizations, it is mandatory for senior employees to serve as mentors. Mentoring can also be included in annual performance reviews and considered for awards and promotions. The relationship and its progress tend to be monitored by the organization in some way.
• In informal mentoring arrangements, the participating individuals establish the mentor–mentee relationship by themselves. It happens when either a mentor adopts a mentee or a mentee seeks out a mentor. It is upon both of them to drive the relationship. Formal objectives or expectations are usually not stated explicitly. Even when it happens within an organizational context, the organization plays a less active role in informal mentoring.

Even though formal mentoring programs are common, their effectiveness is controversial. A study by Lonnie Inzer and C.B. Crawford [14] showed that:

A formal mentoring program is beneficial if it promotes informal mentoring and involves good mentors. The goal of a formal mentoring program should be to promote the protégé’s career and to create a mentoring environment in the organization where informal mentoring is increased, because informal mentoring is the most effective.

An effective mentoring relationship is usually a combination of formal and informal mentoring. Even when an organization establishes a formal mentoring relationship, it is the informal nature of the relationship that really makes it work. Most people we interviewed valued informal mentoring far more than formal mentoring for the reasons cited above.

In her interview, Courtney Wright offered several interesting insights into how she was mentored, especially at the beginning of her career. She mostly looked to managers, team leads, or senior members of the same team. She did not reach far afield to find mentors. There was one person in particular who stood out. He did not come across as a great technical expert. Wright now realizes he was showing great humility to draw the best out of the team. He had great people skills and recognized well the work of others. Wright learned far more from him by observing what he did and how he behaved than by any explicit advice he offered. He mentored her informally by example. She still stays in touch with him 15 years later.

When a mentoring relationship is established and when the mentor and mentee meet, what will they talk about? Broadly, there are three different types of mentoring:

• Career mentoring focuses on topics related to the careers of mentees, who may be in the early stages of their careers. The mentor can help set career goals and identify ways and means to achieve those goals. Career mentors are usually in the same discipline but could also be from another group or division in an organization. Mentees may also be groomed on management and leadership‐related topics.
• Technical mentoring focuses on technical details of the systems being engineered. The mentor also acts as a subject matter expert, answering questions mentees might have on various subjects, systems, or programs. The mentor teaches lessons that are typically not found in books or other published material. Mentors provide crucial insights on technical tools and processes. This type of mentoring is also commonly referred to as “coaching.”
• Organizational mentoring largely benefits those mentees who are new to an organization, irrespective of their age or seniority. While closely related to career mentoring, organizational mentoring focuses on the organization itself – its culture, procedures, practices, promotion policies, unwritten rules, politics, power players, etc. The value of this type of mentoring tends to be short‐lived, mostly taking place soon after the mentee joins an organization. Junior systems engineers we interviewed generally stated that they understood the overall processes of the organization but not necessarily why things were done in a certain way or how to accomplish specific systems engineering tasks within a process. “I need to learn how ‘x’ task is done here” and “I don’t yet know who to call or who I’m not supposed to include in this task” were common refrains from interviewees when they were new to their organizations. Generally, junior systems engineers said that mentors helped them navigate these issues and begin to understand the organizational work processes.

A typical mentoring arrangement is expected to be most beneficial to the mentee. However, there are benefits to the mentors as well, and, of course, well‐done mentoring benefits the organization by growing its employees. Many good mentor–mentee relationships last for life. Even as individuals move on to different organizations or even different careers, some personal relationships are sustained and cherished. That is how it worked for Courtney Wright with her early mentor.

• Benefits to mentees: A mentee is often a new or younger employee of the organization. Although mentees may have formal education or training that qualifies them for their jobs, there is much to be learned in the context of the organizational environment and culture and in the nature of the systems being engineered. A mentee could also be a senior engineer who is either new to the organization or has moved from another part of the organization and whose experience and expertise could be in a different discipline or system. In either case, the mentee gains significantly through mentoring.
• Benefits to mentors: A mentor is usually a senior experienced engineer or manager who has spent more time in the part of the organization into which the mentee has entered or in dealing with the type of system that may be unfamiliar to the mentee. Though the mentee stands to benefit the most, the mentor also benefits, which tends to motivate the mentor to engage in a mentoring a relationship. For example, mentees may learn by shadowing or apprenticing, providing support to their mentors in exchange for their learning. The mentor may even decide the mentee is suitable as their successor.
• Benefits to organization: Effective mentoring not only benefits the mentees and mentors involved in the relationship but also the workforce as a whole. When this happens, the organization at large benefits as well. One of the early motivations for our research was the fact that a significant number of senior systems engineers in the DoD would soon be eligible for retirement. There was a concern by DoD leadership whether organizations would be able to effectively manage the resulting gap. Mentoring is a way to help address this concern.

Pyster had just one formal mentor in his career, a situation that lasted only briefly because there was little chemistry between them despite good intentions. On the other hand, he had several important informal mentors, especially early in his career. One stands out and is worth elaborating. Barry Boehm has been Pyster’s most important mentor. Pyster worked for him at TRW in his first full‐time industrial position after leaving the University of California in Santa Barbara, where Pyster was an assistant professor in the Computer Science Department. At the time, TRW was one of the largest defense contractors in the United States, renowned for its software and systems engineering. Boehm is a legend in both of those fields – deservedly so – and Pyster viewed it as a great honor to work for him. Pyster’s position was a manager of systems engineering and the chief architect of an integrated software development environment that would serve large projects at TRW. At that time, in the early 1980s, such environments were novel, and this was a major corporate initiative for TRW, intended to give it a proprietary advantage over its competitors. Boehm continually offered all three types of mentoring to Pyster – career, technical, and organizational. They would meet regularly, and Boehm would routinely help Pyster grow his professional network, navigate TRW corporate culture, introduce him to leaders in the software and systems engineering fields, write papers with him, and teach him about prototyping, software economics, and a variety of other technical topics. Pyster has been fortunate to maintain that relationship with Boehm for more than 35 years and still seeks his counsel on career and technical matters.

Henry has also had a number of informal mentors over his professional and academic career, many of whom continue to provide counsel and advice. His mentors played critical roles in major career steps. It was through his mentors that he came to know that something called “systems engineering” even existed and was surprised to find it very familiar. It was then that he realized that he had always been a systems engineer, and that is exactly what his mentors saw in him. His mentors facilitated his master’s degree in systems engineering and even paved the way for his move to the United States to pursue a PhD in systems engineering. When Henry joined Regent University in summer 2017, he was part of a formal mentoring initiative where new faculty members were paired with senior faculty members from other departments. Henry’s mentor was a veteran of the Virginia State Police who was then teaching courses on government and criminal justice. The university chose this mentor for Henry so that the focus of their interactions would not be about their fields of expertise but rather on tenure process, career development, teaching effectiveness, work–life balance, and other such topics. When the university asked if the two were willing to sign an optional formal mentoring agreement, Henry and his mentor chose not to, preferring to keep their relationship as informal as possible. The university offered some guidelines for the interactions but has not stepped in to direct or monitor them. This confirms the observations from Helix interviews that formal mentoring alone does not usually work out and needs to be combined with informal mentoring. Henry continues to derive much value from his mentor – they meet every other week and focus their conversations on a mutually agreed topic while also allowing for open‐ended and personal conversations. This has helped Henry feel welcomed and valued at Regent, better equipped to navigate the organizational landscape.

Hutchison has had several mentors in her career, though none through formal mentoring relationships. Pyster was, at first, Hutchison’s supervisor on a project but quickly became a powerful mentor for her, providing insights into the “whys” behind particular actions and approaches and encouraging her to try new roles and responsibilities. Though they no longer work for the same employer, Hutchison still considers Pyster a great mentor. In addition, Hutchison has had several peer mentors – individuals who may not have a higher position or considerably longer experience, but who provided critical insights and reflections. For example, one peer mentor helped Hutchison begin to view her work on large‐scale emergency response exercises as a system of system rather than focusing on all of the disparate agencies involved. Another continues to provide insightful questions, forcing Hutchison to think beyond the boundaries of current situations to explore the whole space and environment, including her reactions to it. These mentors have been invaluable throughout her career.

Mike Celentano, in his interview, spoke about his first and perhaps most important mentor:

Even when I was first starting as an electro‐optics engineer, I can remember the first mentor I had. … We used to call him “Uncle Miltie.” Uncle Miltie was in charge of the electro‐optics department. ... He actually had a working knowledge of all these disciplines. He wasn’t only an electro‐optics guy. He could explain the chemistry; he could explain the mechanics; he could explain the fluid dynamics. … This guy kinda knew enough about everything that he really understood the whole system. It is rare to find someone that is really an expert on such a complex system head to toe. He really didn’t talk down to people. He was always helpful and inspirational.

Although not shown in Figure 7.2, our hypothetical CSE, Cathy, has had three noteworthy mentoring milestones. The first was when she started her professional career. This is often when young professionals most need guidance from a more senior person. Many companies facilitate such pairings, as did Regent University for Henry. At the second milestone, she got her first position as a systems engineer, which occurred in her second company. The shift from mechanical engineer to systems engineer was gradual in her assigned roles, but the formal position of systems engineer presented enough new challenges that she sought out a senior systems engineer to guide her. Finally, when she made the leap to CSE, she took on far more responsibility than she previously had held and found a vice president in her organization as a mentor. In each case, the arrangement was informal. In her interview, Gina Guillaume‐Joseph spoke kindly of her most important mentor, one she has stayed in touch with even after he retired. Soon before her interview, Gina went fishing with his family. He helped her reach major career decisions, encouraging her to pursue a doctorate in systems engineering.

FORCE 3: EDUCATION & TRAINING

Formal education plays two key roles in the development of systems engineers:

• It provides foundational knowledge to support engineering‐related work. Typically, this takes the form of undergraduate education in an engineering discipline, technical field, mathematics, or science.
• Graduate‐level education is an avenue to develop more advanced skills, explore more in‐depth knowledge, and help systems engineers grow as they move through their careers. Increasingly, systems engineers earn a master’s degree in systems engineering. In 2010, approximately 1500 people in the United States graduated with master’s degrees in systems engineering [15]. Graduate degrees are even more important in systems engineering than in most classic engineering disciplines because very few people earn a bachelor’s degree in systems engineering.

In addition to formal academic programs leading to undergraduate and graduate degrees, individuals obtain graduate certificates in an area closely related to their work. For example, Stevens Institute of Technology, where Hutchison works, offers several graduate certificates in such areas as systems engineering of embedded/cyber–physical systems and in space systems engineering. Both certificates require four graduate courses. A small percentage of systems engineers seek doctorate degrees in systems engineering. In 2010, approximately 40 doctorate degrees in systems engineering were awarded across all of the United States. We looked at the education of systems engineers who participated in our study as well as who applied for INCOSE systems engineering practitioner certification. In both datasets, doctoral degrees were not common, with fewer than 10% of the participants reporting a PhD.

Systems engineers typically begin full‐time work after obtaining an undergraduate degree and seek graduate degrees after a few years of professional work – in our study on average after three to eight years on the job. A formal degree directly strengthens proficiency in the relevant areas and categories. An undergraduate degree in engineering typically provides strength in MATH/SCIENCE/GENERAL ENGINEERING in addition to several categories under the SYSTEM’S DOMAIN & OPERATIONAL CONTEXT proficiency area. Graduate degrees in systems engineering tend to focus heavily on proficiencies in SYSTEMS ENGINEERING DISCIPLINE and to a lesser extent on SYSTEMS MINDSET but will usually address aspects of all six proficiency areas. For example, it is common in systems engineering programs for students to do team projects, give formal presentations, write substantial technical reports, learn about a business sector, etc. Such learnings strengthen a student’s PROFILE in several categories.

Paul Schreinemakers earned a master’s degree in engineering product design, which, in his view, was largely a systems engineering degree with a different name. At that time, he was already doing systems engineering on space systems, but he did not yet have a formal education in systems engineering. Schreinemakers said that this period was perhaps the time of greatest personal growth for him – “a real eye opener.” Through his education, he came to understand the reason behind the processes he was doing and why systems engineering was so important to project success. Schreinemakers strengthened greatly the SYSTEMS ENGINEERING DISCIPLINE and SYSTEMS MINDSET proficiency areas through his master’s education.

A number of people that we interviewed had earned a master’s degree in systems engineering, especially younger systems engineers. They often reported that the greatest value their master’s degree gave them was perspective on topics they had learned piecemeal over the years on the job. The degree provided a framework to understand and appreciate the value of system architectures, requirements management, and other topics that they had previously encountered. Paul Schreinemakers said that his master’s degree made explicit what choices he was making when executing the development process. Having that explicit understanding made him more thoughtful when making those choices.

While academic programs are offered by universities, many companies offer tailored training programs for their employees. These programs typically focus on building skills required to perform specific positions within the company. Training courses are often just a few hours long. Topics vary widely across organizations, with some training focused on technical aspects of systems development, other training focused on organization‐specific approaches and processes, and still other training focused on leadership or interpersonal skills. Each type of training has the potential to expand an employee’s PROFILE. For example, at SAIC, Pyster managed a variety of training courses for project managers and systems engineers, typically one‐ or two‐day events. The classes, which were normally taught by SAIC employees, covered such topics as requirements management, lifecycle management, process improvement, and risk management. They focused on SAIC‐specific processes, methods, and tools, rather than on general principles and techniques that might be taught in a university. Sometimes internal training programs augment their employee instructors with external trainers. Hutchison, for example, occasionally teaches one‐ or two‐day short courses for government agencies and private companies, covering such systems engineering topics as technical risk management.

Once more referring to Figure 7.2, Cathy noted two key education milestones, shown as diamonds. The first milestone was her bachelor’s degree in mechanical engineering. The second, earned four years later, was an MBA that she earned with tuition assistance of her company, another common benefit for engineers; nearly a quarter of the participants in our study held MBAs. It is common for rising systems engineers to seek an MBA as their second degree rather than deepening their technical credentials with another engineering degree. Senior systems engineers often engage in business strategy and benefit from an MBA. Many CSEs that we interviewed highlighted the importance to their career development of strengthening business proficiency.

FORCE MULTIPLIERS

Some people are just ill‐suited to be systems engineers, while others thrive at it. Put two people through the same experiences, expose them to the same mentors, and offer them the same education and training, and you will get dramatically different effects. Why? What distinguishes them? Similarly, systems engineers thrive in some organizations and wilt in others. The culture, structure, reward system, and other organizational characteristics can either help or hinder the effectiveness of systems engineers. Figure 7.3 shows the influence that eight personal and five organizational characteristics or traits have on the forces. Here we use the terms characteristic and trait interchangeably.

Both lists of characteristics in Figure 7.3 are largely derived from Helix interviews. However, we did not conduct any personality tests of specific individuals to derive or validate the list of personal characteristics. Such testing was simply not possible. We did spend considerable interview time asking each interviewee what they thought were the most critical personal characteristics of an effective systems engineer and why they believed those particular characteristics were critical. The list in Figure 7.3 is the result of our analysis of that data. Similarly, we did not look at detailed substantiating documents and data to derive the list of organizational characteristics that impact the three forces. Instead, we spent considerable interview time asking each subject what they thought were the most critical organizational characteristics affecting the ability of systems engineers to be effective. The list in Figure 7.3 is the result.

Note that the arrows between the boxes depicting the forces and characteristics are bidirectional. Not only do characteristics affect the strength of the forces, but the forces can also affect the characteristics. For example, mentors can highlight blind spots to their mentees in ways that raise the mentees’ self‐awareness. A series of positive experiences can increase someone’s confidence, while a series of disastrous experiences can lessen or even shatter someone’s confidence. A handful of very senior systems engineers who have been instrumental in highly successful projects – strong positive experiences – can influence senior management to alter the reward system or organizational structure to benefit systems engineers.

NOTES AND REFERENCES

1. 1 In 1996, Michael Lombardo and Robert Eichinger described the 70 : 20 : 10 model for learning and development, which stated that 70% of lessons learned for successful and effective managers come from challenging assignments (experiences), 20% from developmental relationships (mentoring), and 10% from coursework and training. The model should not be taken as prescriptive but as a practical guideline that is qualitatively consistent with the interview data we collected. The book has been updated and is now in its fifth edition. Lombardo, M. and Eichinger, R. (2010). Career Architect Development Planner, 5. New York: Korn/Ferry International.
2. 2 Stuart, R. and Abetti, P. (1990). Impact of entrepreneurial and management experience on early performance. Journal of Business Venturing 5: 151–162.
3. 3 Davidz, H., Nightingale, D., and Rhodes, D. (2005). Accelerating the development of senior systems engineers. Proceedings of the 2005 INCOSE International Symposium, Rochester, NY (10–14 July 2005). Hoboken, NJ: Wiley.
4. 4 Glassdoor (n.d.). Mechanical engineer: rotational program. https://www.glassdoor.com/Job/engineering‐rotational‐program‐jobs‐SRCH_KO0,30.htm (accessed 3 December 2017).
5. 5 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).
6. 6 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).
7. 7 Pyster, A., Olwell, D.H., Ferris, T.L.J. et al. (2015). Graduate Reference Curriculum for Systems Engineering (GRCSE®) Version 1.1. Hoboken, NJ: Stevens Institute of Technology http://www.bkcase.org/grcse (accessed 30 November 2017.
8. 8 NAICS (n.d.). North American industry classification system. United States Census Bureau. https://www.census.gov/eos/www/naics/ (accessed 3 December 2017).
9. 9 SIC (n.d.). Standard industrial classification (SIC) system. United Stated Department of Labor. https://www.osha.gov/pls/imis/sicsearch.html (accessed 3 December 2017).
10. 10 ISIC (n.d.). International standard classification system: detailed structure and explanatory notes. https://unstats.un.org/unsd/cr/registry/regcst.asp?Cl=27 (accessed 3 December 2017).
11. 11 Hutchison, N., Verma, D., Burke, P. et al. (2017). Atlas Career Path Guidebook: Patterns and Common Practices in Systems Engineers’ Development. Hoboken, NJ: Systems Engineering Research Center (SERC), Stevens Institute of Technology SERC‐2018‐TR‐101‐C.
12. 12 Forbes, B.C. (1921). Why do so many men never amount to anything? American Magazine. https://babel.hathitrust.org/cgi/pt?id=mdp.39015056072385;view=1up;seq=105 (accessed 29 January 2018).
13. 13 NSEPS (n.d.). Mentoring resources. National Society of Professional Engineers. https://www.nspe.org/resources/career‐center/mentoring‐resources (accessed 3 December 2017).
14. 14 Inzer, L. and Crawford, C.B. (2005). A review of formal and informal mentoring: processes, problems, and design. Journal of Leadership Education 4 (1): 31–50. http://www.journalofleadershiped.org/attachments/article/137/JOLE_4_1_Inzer_Crawford.pdf (accessed 3 December 2017).
15. 15 Lasfer, K. and Pyster, A. (2011). The growth of systems engineering graduate programs in the united states. Proceedings of the Conference on Systems Engineering Research, Los Angeles, CA (15–16 April 2011). Hoboken, NJ: Wiley.
16. 16 Sackett, P. and Walmsley, P. (2014). Which personality attributes are most important in the workplace? Perspectives on Psychological Science 9 (5): 538–551.
17. 17 Duckworth, A. (2013). Grit: the power of passion and perseverance. Ted Talks Education. https://www.ted.com/talks/angela_lee_duckworth_grit_the_power_of_passion_and_perseverance#t‐356914 (accessed 2 January 2018).
18. 18 McCrae, R. and Costa, P. Jr. (1997). Personality trait structure as a human universal. American Psychologist 52 (5): 509–516.
19. 19 Lewis Goldberg is often credited with solidifying the validity of describing personalities using the Big Five Factors. His seminal paper is: Goldberg, L. (1990). An alternative ‘description of personality’: the big‐five factor structure. Journal of Personality and Social Psychology 59 (6): 1216–1229.
20. 20 Cherry, K. (2017). The big five personality traits. Verywell. https://www.verywell.com/the‐big‐five‐personality‐dimensions‐2795422 (accessed 3 December 2017).