Rather watch than read? Check out the recording!
Systems engineering careers do not all follow the same path. Today’s systems engineers come from a wider range of educational backgrounds, industries, and technical disciplines than ever before, and emerging technologies such as artificial intelligence are continuing to change what engineers need to know and how they develop those skills.
In Part 1 of our Engineering the Future webinar series, Courtney Wright, SPEC Innovations Director of Solution Engineering, spoke with Nicole Hutchison, Editor-in-Chief of the Systems Engineering Body of Knowledge (SEBoK), about career paths in systems and digital engineering.
Below are highlights from their conversation.
You did not go through the most common engineering background for a systems engineer, which is a traditional engineering degree, work for a while, and then find out that what you've been doing is systems engineering.
So what is your background? How did you become a systems engineer, and would you recommend that path to someone else?
I definitely did not come to systems engineering through a “typical” path. Particularly, people who are in senior systems engineering positions now are very similar to what you said; not necessarily electrical engineering, but electrical, mechanical, very traditional engineering disciplines, get some experience, and then learn, “Oh, this stuff I've been doing has a name.” But a lot more people, if we're talking mid-level or junior, are taking different paths.
I have a BS in biology and a BA in classical studies from Virginia Tech. My first master's degree was in biohazardous threat agents and emerging infectious disease.
What I loved about that program, but I didn't have the language to explain, is that it was looking at that from a systems lens. We looked at public health. We looked at disease progression. We looked at pharmacology and immunology. We looked at public policy. It was a really systematic way of thinking through those things, which was incredibly appealing to me.
My first real job decided to do a cohort of systems engineering. They were going to send people through to get a master's. Someone said, “Hey, you need to apply for this.” And I said, “I'm not an engineer. I don't know why on earth I would apply for this.” Finally, someone said, “Go down the hall and talk to Larry. At the end of an hour with Larry, we'll know whether you should do this or not.”
He had this giant schematic on the wall. I think it was for a fighter jet. Big giant diagram with lots of boxes and lines. He said, “So what do you see?” We just started talking and thinking about, “Oh, well, this connects over here, and that goes over there.”
At the end of the hour he said, “What'd you think of that?” And I said, “I mean, it was kind of fun.” He said, “Good. Go take the class. If you're interested in all of those connections and how those things work together and why it matters that we put them together in this way, then you can think in systems, and you should go do it.”
So I did. I really enjoyed it and ended up getting my PhD in systems.
There is no single educational route into systems engineering. Traditional engineering disciplines remain common, but Hutchison’s experience demonstrates that systems thinking can develop in many different fields.
For people considering a systems engineering career, the better question may be whether they are naturally interested in connections, interactions, and how different pieces work together as part of a larger system.
The people who are senior today earned their undergraduate degrees 20-plus years ago, pretty commonly 40 years ago. The path that was right for them may not be the same thing that would be right for us with the offerings today. Systems engineering wasn't offered as an undergraduate degree for most of those people.
Do you think that for getting started, the degree matters? Is there any degree that's off limits or any degree that you would say is definitely a good one?
I'm going to give the traditional systems engineering answer: it depends.
I think it depends a lot on the person and what they find interesting and what drives them. Wanting to know the next step, what this connects to, and what's next; I think that mindset lends itself really well to systems.
I've interviewed people who are amazing systems engineers whose undergraduate degree is in music or math. I think there was one that was archaeology and anthropology.
This brings up the debate: Do you have to be an amazing engineer to be a systems engineer? I've had people stand up at conferences and tell me, “You are so wrong.” And that's okay.
There used to be this idea that you can't possibly be a systems engineer unless you have 20 years of experience. That was coming from very senior people who got there through that pathway.
Over time, I think the community has become more open to the idea that the chief systems engineer isn't the only systems engineer. You can have junior people. You can have mid-level people. It's a question of what the scope of that is.
Now there are undergraduate degrees or graduate degrees in systems engineering, and I think we're seeing a lot more of that.
I think systems engineers are pi-shaped. We talk about pi-shaped professionals: you've got depth, and then you've got some cross-cutting knowledge.
Systems engineers really have depth in systems and depth in either a discipline or a domain. Maybe you're not an electrical engineering guru, but you have a lot of experience in space systems and understanding how those things fit together. And then all of the things we talk about, systems thinking and such, are kind of that bridge across.
I would say all of those are valid pathways. It's just figuring out what the right role is to fit.
The conversation points toward a broader definition of what a successful systems engineer can look like. Instead of expecting every engineer to follow the same educational sequence, organizations can look for a combination of systems knowledge, domain or technical depth, and cross-cutting systems thinking.
That flexibility may become increasingly important as more students enter systems engineering directly rather than discovering the discipline midway through their careers.
You have been told that, to be a systems engineer, you need 20-plus years of experience. They have to have scars. We use the term “gray beard.”
What do people mean when they say, “Let's bring a gray beard in here?”
What they really mean is someone who has seen some stuff and been able to get through it, and therefore has the scar tissue, if you will, to help you get through something that's harder, challenging, or complex. That's really what we mean.
A lot of times we used to just equate that with age. The expectation was, if you've been doing this for 20 years, then you're older, and you know how to do these things. It doesn't do a very good job of understanding people as individuals.
I've met a chief systems engineer who only had 10 years of experience and was by far the best in the company. Everyone said it, because that's just who they are and that's how they think.
I think we're looking at a little bit of a problem of equating age to experience to quality of performance.
We say, “Oh, this person has 20 years of experience.” Well, sometimes they have the same experience 20 times rather than growing and developing. Someone with 10 amazing years might be more useful.
One problem we run into with the concept of needing years of experience to be an expert is using that as a proxy for quality, depth, or difficulty of experience, or maybe even success overcoming the difficulty. How do we measure that someone has those scars?
That's part of the objection. It's substituting quantity for quality.
Years of experience can be valuable, but time alone does not equal competency. Engineers develop through the variety, complexity, and quality of the experiences they encounter.
For workforce development, this suggests organizations should think beyond tenure and give engineers opportunities to work across different projects, lifecycle stages, disciplines, and problems.
I've had a couple of conversations with senior systems engineers who felt embarrassed that they were not doing MBSE, that they were not in a tool all the time, that they did not know SysML.
What is your reaction to that? Can they manage the folks who are doing that stuff? Do they need to go and catch up?
I am someone who doesn't know SysML very well. It's not my favorite. So I can certainly identify with people who feel that way. But let's take a step back and think about systems as a discipline.
Systems engineers are the people who can put the expertise in a lot of different areas together in a way that we get synergy and something greater than we could have achieved individually. From that perspective, I never expect a systems engineer to be the expert in everything. It's those cross-cutting skills that can often be really helpful.
We're supposed to be bringing people together who know more than we do.
I wouldn't expect a senior person to be - and I hate to use this term, but I'll use it because it's the one sticking in my head - kind of a “tool jockey.” I don't expect them to know the ins and outs of every single tool. I expect them to know what the tool can do, what the tool's not good at, and to have enough insight to ask good questions. I think that's what you need.
So if a senior chief systems engineer came to me and said, “I think I'm going to take a month off and learn SysML,” I would say, “Okay, why? I'm not sure that's going to give you what you think it's going to give you."
Hopefully we will get to the point where tooling is just how we do things, and we don't have to talk about MBSE anymore because that's just the way we do things.
But there are still programs out there that have requirements in Word and Excel, and they're still doing the work. It maybe isn't as modern as we would like, but they're still doing systems engineering.
Digital engineering tools and MBSE are becoming increasingly important, but the necessary level of expertise depends on the role.
A senior systems engineer may not need to build every model personally. Instead, they need enough understanding to recognize what the tools can and cannot do, communicate with practitioners, and ask the questions that support good engineering decisions.
Any tips that you have from the perspective of, “Here's a competency systems engineers should have, and here's a good way to develop it?”
Any examples from yourself or other people where this was a cool side quest that improved them as a systems engineer?
I love the example of a hackathon because several people have done things like that just to get their feet wet.
It should not be surprising given the way systems engineering works, but diversity of experiences is important. For a lot of people, it's finding that short-term assignment where, “Hey, I'm going to go over and work on something I've never worked on because they need help here.”
Sometimes people will do things in their volunteer work. We're really good at systems thinking and understanding how things connect, and we can help a nonprofit figure out something that isn't working very well.
I think it's more just looking for those opportunities and not being afraid to jump on them if it's going to diversify what you've been doing.
It sounds like you're pretty much in favor of on-the-job learning. Let's go do a project, and we're going to pick up some skills that way.
Hands down, we learn the most through things that we experience. That's just how humans are built.
But training is still useful. Apprenticeships or rotational assignments can be very helpful. Education can be helpful as long as you apply it. With education and training, mentoring and coaching are also valuable.
The biggest gap I see in anything that's not experience is not being able to apply it. If you go take a training class and it's really cool, but in six months you haven't done any of it in your volunteer work or your day job, it's gone.
I wouldn't say on-the-job training is the only way, because it isn't. But I do think finding ways to apply what you're learning is very critical.
Training, education, mentoring, and coaching can all contribute to systems engineering competency, but application is critical.
Engineers can deliberately seek out assignments, projects, volunteer opportunities, or other experiences that expose them to unfamiliar problems. Those “side quests” can become an important part of building breadth over the course of a career.
Is there a bare minimum amount of AI that systems engineers need to understand?
Let's start with those senior systems engineers. How dumb can they be about AI and survive today and five years from now?
You can't be completely ignorant of it. You have to at least understand what the landscape is and where things could benefit and where there are pitfalls.
I see a lot of organizations doing the “We need to do AI because we're doing AI and everybody's doing AI. If we're not doing AI, what are we doing?” And they're not taking a very systems view of, “What capability is this giving us? How is it helping us?”
You can say, “Look how efficient this could make us,” but what are we giving up in order to do that?
To me, it's more about understanding what the trade-offs are and the governance space. What is it that we think this can help us with? Where should it not be used? And how do we keep track of that over time?
I think that's exactly what I think of as the minimal role, and perhaps the desired role, for the senior engineer.
When someone says, “We'll just reach out to the LLM,” they put the brakes on.
They don't have to know much of what happens within AI, but they need to know the interface of their work with AI: what is okay, what's not okay, and what needs to go for further consultation to the expert who is not them.
Yeah, that's it. I want to separate two things. There's AI for SE versus SE for AI.
If you're working on systems that use AI heavily, you probably need to know a little bit more about how the AI works.
To me, the biggest thing is that decision-making still needs to reside with the human. We can talk about checks and balances and checking for hallucinations. There are all kinds of metrics out there to help with those things. But for me, the biggest issue is, at least based on where the technology is now, it should not be making any engineering decisions.
AI can be used to review stuff, like, “Hey, do you see any gaps here?” You might be able to tailor it against your workflows so it can help you work through those things. But I'm wary of full automation that doesn't include human decision-makers.
We're really focused, at least in some of the work we've done at NSI, on augmentation. How do we make the AI part of the team?
Just like when you and I work on a team, sometimes we disagree and you go, “Nicole, I just don't think that's what we need to do.” You have to be able to interrogate the AI the same way.
For systems engineers, AI literacy may be less about becoming an AI specialist and more about developing enough understanding to evaluate when AI is appropriate, recognize its limitations, and challenge its output.
The distinction between automation and augmentation is especially important. AI can help engineers process information and identify possible issues, but engineering judgment and decision-making still require human involvement.
There are certainly things systems engineers used to need to be able to do that AI can help with.
If the mid-level engineer thinks, “Rather than asking my junior employee to go through the 500 requirements, it's easier for me to write the prompt. I don't think I'm going to convince them to continue to do it the inefficient way." So what should the junior engineer be doing for their own personal development?
The whole team wants them to be useful five years from now. The tasks they're involved with have to change because we're not willing to give them those old tasks that something else can do for us.
If AI takes over some of the stuff that we used to call systems engineering, what are we going to have them do?
If you think of systems engineering as a spectrum, we've said junior, mid-level, senior. That's a useful construct for discussion, but it really is a spectrum.
I think the junior level just moves a little further on the spectrum. They're not just typing requirements into DOORS. They're doing an analysis, maybe supported by AI, of what those requirements mean. Maybe they're flagging things where there's conflict between stakeholder requirements, and we need to get in there and do that.
My hope is that we augment with things that AI is really good at. Go through these 500 requirements, because by the time I get to 450, I don't remember what number one was. AI can do that, and then have the junior engineer take the next step with it.
It's not that they're not doing anything. It's just the things that really do make sense for a computer to do faster and more efficiently than a human; let the computer do that and let them take the next step, rather than that being their whole job.
I'm going to challenge your premise. I don't think there is a world where there are no junior systems engineers. I think they just become slightly more advanced earlier.
AI may change the starting point for junior systems engineers rather than eliminating the role altogether.
Instead of spending as much time on manual or repetitive work, early-career engineers may move more quickly into analysis, stakeholder conflicts, interpretation, and other higher-value activities. The challenge for organizations will be making sure engineers still develop enough foundational understanding to evaluate AI-supported work as they progress in their careers.
One of the things that I like in looking at junior career paths, if I were to design one, is the idea of someone starting off on the verification or operations side of things. They see what goes wrong before they inch their way back to the requirements side, where they're the ones who have the opportunity to fix it.
Are there preferences you have along those lines of career path progression? Which things are a better fit for junior career folks versus senior career folks?
It is evolving. We saw two really clear patterns.
You said, “Start at the end of the lifecycle and work your way forward because you've lived with the pain of other people's bad decisions.” Several other people say, “No, start at the beginning and then live with your own decisions as you work through.”
I think it comes back to this idea of scar tissue. You have to deal with that pain. You have to see when it's messed up and understand what it takes to fix it. And the next time you'll be a little bit better. You will make mistakes, but you won't make the same mistake.
I don't think there's one optimal way. Certain things like requirements and V&V, very specific tasks in those areas, tended to be where a lot of junior folks were starting. It may be that AI makes it easier for them to start in other places.
There may not be one ideal systems engineering career progression.
What appears more important is that engineers gain exposure to the consequences of engineering decisions. Whether they start earlier or later in the lifecycle, seeing what works, what fails, and what it takes to correct problems can help build the experience needed for future roles.
During the webinar Q&A, one attendee asked whether AI could push more professionals toward systems engineering principles such as clearly defining requirements and following structured verification processes.
We as systems engineers have to decide: Do we want people to do systems engineering, or do we want people to give credit to systems engineering? Do we want them to call it systems engineering?
I think our heart wants them to do things well, and we think our principles will help them be more successful. I think that's the direction we're heading: getting systems engineering woven in and accepted in academic curriculum.
Maybe they call it "SE." Maybe they stick with the terms they've been calling it. But they say, “It's a best practice to define the problem before we proceed.”
I'm concerned that if we try to say, “Hey, do systems engineering,” they're going to say, “No, we are this other thing. That's you.” Then that causes us not to grow acceptance.
The first thing I was going to say is: Don't say you're trying to make them do systems engineering. What tends to be effective is showing people where they're already doing it anyway.
"What's a hard problem you solved? How did you solve that problem?" You will hear the systems principles that they're demonstrating, or they haven't solved the problem, maybe partially because they're not doing that. At the end of the day, helping people understand how what we're doing solves their problems is the key.
If we're tied to them having to say, “Oh, it's systems engineering,” I think we lose a lot more than we can potentially gain. We've got to have the humility to say, “We're helping solve cool problems, and I don't care if you call it systems.”
The future influence of systems engineering may extend well beyond the number of people carrying the title “Systems Engineer.”
If systems thinking, requirements discipline, verification, collaboration, and problem definition become more common across engineering disciplines, the practices can have an impact regardless of what individual organizations choose to call them.
The final audience question compared academic systems engineering degrees with professional certifications.
If someone has an INCOSE Systems Engineering Professional certification, you know what it is. Everyone who has that has met the knowledge, experience, or reference qualifications.
If they have an academic degree, it can vary based on the university. One university might say, “We're really on the theoretical side.” One might be very much on the industry side. So what that person has been educated in could have some variation.
Also, a degree could mean no experience at all. A CSEP or ESEP is going to say they have a certain amount of experience.
A master's in systems engineering or a PhD in systems engineering is one piece of that. You can be an ESEP without either of those things, or you can have those things and be an ESEP.
I think it's separating out the education from the experience. They mean different things. They have different purposes. It's really dependent on what it is that you're hoping to get out of it.
In general, education is going to give you more of the theoretical understanding. ESEP and CSEP prove that you've also applied that. Having one year of experience 20 times over doesn't work for things like ESEP.
What you are getting is that, at least by the INCOSE definition, they have enough depth and breadth that we think this person qualifies.
They just mean different things.
Degrees and certifications serve different purposes, so one does not necessarily replace the other.
Academic programs can provide deeper theoretical education, while professional certifications demonstrate that systems engineering knowledge has also been applied through experience. The best choice depends on what an engineer wants to learn or demonstrate at that point in their career.
There may be no single blueprint for the systems engineer of the future.
Some will enter through traditional engineering disciplines. Others will study systems engineering directly. Some will build deep expertise in a technical discipline, while others will develop deep domain knowledge. AI and digital engineering tools will continue to change the tasks engineers perform and potentially allow early-career professionals to take on more analytical responsibilities sooner.
Across those paths, however, the conversation between Wright and Hutchison points to several skills that remain important: understanding connections, asking good questions, learning through experience, collaborating across disciplines, and knowing when technology should support, not replace, engineering judgment.
The systems engineering career path may continue to change. The need for systems thinking is unlikely to disappear.
This webinar was Part 1 of SPEC Innovations’ Engineering the Future series.
Explore the full Engineering the Future webinar series for more conversations about the skills, education, technologies, and approaches shaping the next generation of systems and digital engineering professionals.
You can also join SPEC Innovations for Ask a Systems Engineer, our weekly live session where attendees can bring questions about systems engineering, MBSE, digital engineering, career development, and more.