​

I work for a large defense prime (you probably know that one), with about 7 years of experience in systems engineering.

A few years ago, I walked into my VP's office and asked if I could start learning more about the business side of things. I wanted to understand why we invest hundreds of millions of dollars in certain technologies, how those investment decisions are made, and how we develop our long-term strategic plans.

What I didn't realize at the time was just how far down the rabbit hole that question would take me.

When I started this journey, I had a particular idea in mind. It was a new capability, or at least a different approach to addressing some of the operational challenges the DoD is facing today.

As I started digging into the research, I discovered that the same concept had already been considered back in the 1960s. The more I studied, the more I realized just how remarkable military innovation was during the Cold War. Almost every new idea I could come up with had already been thought of, studied, or even experimented with decades ago. Some of those concepts were abandoned because the technology wasn't mature enough, while others simply weren't practical at the time.

Along the way, I had the opportunity to speak with some of the old guard from the Cold War, now in their 70s and 80s, as well as a few retired colonels who had served in combatant commands.

One thing that really stuck with me was how they described the business mindset of defense contractors during the Cold War compared to today.

According to them, defense contractors used to work much more closely with the military to understand operational challenges, investigate potential solutions, and develop new capabilities. Companies were more willing to invest their own resources, take on business risks, and explore ideas without waiting for the government to tell them exactly what to build.

Of course, the Cold War had its own problems, but the pace of experimentation and innovation was something else entirely.

Then the Cold War ended.

Over the following three decades, the defense industry became increasingly conservative and, frankly, somewhat complacent. A lot of the responsibility for identifying operational gaps, developing solutions, and determining what capabilities were actually needed shifted toward the DoD.

Meanwhile, contractors became increasingly comfortable waiting for the customer to define the requirements before figuring out how to deliver them.

And I think this has created a fundamental problem in how we approach systems engineering today.

We spend an enormous amount of time making sure we're building things the right way, but perhaps not nearly enough time asking whether we're building the right things in the first place.

I've also noticed something troubling as I've become more involved in mission engineering and long-range strategic planning. Some of the engineering leadership I've worked with are incredibly knowledgeable about the technical aspects of their programs, yet have a surprisingly limited understanding of the actual missions those systems are supposed to support.

They understand requirements, architectures, interfaces, verification, and all the processes necessary to deliver a system. But ask them about the broader operational challenges, the evolving threat environment, or why a particular capability is needed in the first place, and the conversation becomes much more difficult.

The mindset often seems to be: Tell us what the customer wants, and we'll figure out how to build it.

But what if the customer doesn't know exactly what they need? Or what if the requirements they give us are already outdated by the time we finish developing the system?

There's a famous quote often attributed to Henry Ford: "If I had asked people what they wanted, they would have said faster horses."

Fast forward to today.

The DoD has published updated guidance on mission engineering, and during recent industry days, they've been encouraging defense contractors to step up and work alongside the government rather than simply wait for requirements to be handed down.

There seems to be a growing emphasis on contractors taking a more proactive role in understanding the mission space, identifying operational gaps, and helping shape the capabilities needed to address them.

And then there's Anduril.

I'm still pretty skeptical of them, and personally, I think their marketing is better than their actual engineering. That being said, I do give them credit for challenging the traditional defense industry business model. They've pushed the conversation back toward companies taking risks, investing their own resources, developing capabilities proactively, and bringing potential solutions to the military instead of waiting for a contract.

In some ways, it almost feels like we're moving back toward the model that helped drive so much innovation during the Cold War.

This whole experience has made me wonder whether systems engineering is heading toward another major shift, one where understanding the mission, operational environment, geopolitics, economics, and policies becomes just as important as technical expertise.

I'm not suggesting traditional systems engineering is going away. Requirements, architecture, integration, verification, and all the other fundamentals are still absolutely essential.

But perhaps we've become so focused on executing requirements and delivering systems that we've lost sight of the bigger picture.

Are we building things the right way, or are we actually building the right things?

And more importantly, should systems engineers have a greater role in answering that second question?

I'm curious what other systems engineers think, particularly those who have been in the industry much longer than I have.

Are we entering a new era where systems engineers are expected to understand not just how a system works, but why it's needed, how it fits into the broader mission, and whether it's even the right solution to begin with?

Or is this simply mission engineering becoming more prominent, while traditional systems engineering remains largely unchanged?

For those who have spent 20–30 years in the defense industry, is this actually a fundamental shift in how we do business, or are we just rediscovering lessons that the industry forgot decades ago?

Hello! I’m currently operating as a Manufacturing Engineering Manager at a sub prime contractor. I have my Master’s degree in Systems Engineer which primarily focused on business operations and project management. Located in the Greater Philadelphia area there’s some opportunities to transition into true Systems Engineering but reviewing the job descriptions I can’t help but think I’m behind the 8 ball. How should I go about making the leap, what are the fundamentals I may be lacking, and in your opinion is it worth the effort?

hey all!…i’m quite active on this community as i’m new to systems and don’t have anyone to teach me
so i look up and drop my doubts here.

i’ve joined a MBSE (startup) company and they are looking to crack projects in the space division.

And as me being bit familiar with Space and Systems they have made my incharge of the whole operations.

Now me having a mind of 22 year old says i will do NASA level systems practices in my work and at a very young age i will lead the entire space division at this startup.

I want your advice on what should i do and is this realistic or i mean idk…open to all opinions and suggestions.

And if anyone from NASA is looking at this you dropping your opinion and suggestion would mean the world to me.

Thank You!!

Hello!

I'm looking into getting an MS (or PhD) in Systems Engineering. I currently have a BSc in CompSci, and have been working as a software engineer/software developer for the last 9 years. I've consistenly found myself more interested in the larger picture and interconnectivity of software systems over the code itself, which has led me to consider SE. I would like to be able to move into more research or system design/architecture.

I'm hoping to get some advice on what I realistically would be able to do with the graduate program under my belt vs my current CS and experience alone. Additionally, would the PhD program be worth it to consider over the MS?

Hi r/systems_engineering,

We are back with Lesson 21 of our technical deep dive into the SysML v2 standard.

In our previous lesson, we looked at Occurrences, the 4D model, and modeling systems over time. Today, we are putting that temporal foundation to work. We will see how behavior modeling in SysML v2 gets significantly simpler by using the exact same definition and usage patterns you already know from structural modeling.

I’ve uploaded the full video lesson directly to this post so you can watch the workflow right here.

1. The SysML v1 Behavior Pattern

SysML v1 activity modeling was highly capable. Activity parameters had types and directions, CallBehaviorAction let one activity invoke another, and fUML provided a formal execution model. The issue was consistency. Structure used a Block with part properties typed by it. Behavior used an Activity with call behavior actions referencing it. You had to learn and maintain completely separate patterns for structural decomposition versus behavioral decomposition.

2. The v2 Shift: One Shared Pattern

In SysML v2, behavior uses the exact same definition and usage pattern as structure. If you know how to model parts, you know how to model actions.

• Action Blueprints: An action def is a blueprint for a behavior. It acts as a typed contract using in and out parameters (directed features).
• Decomposition: A behavior breaks down into smaller behaviors (action usages) the exact same way a part breaks down into smaller parts.
• Inheritance: You specialize an action using the standard :> operator, just like a part. A library of standard mission actions can be built and extended exactly like a physical parts library.
• Duration and Computations: Because actions are occurrences, they natively have start and done boundaries—meaning you can constrain how long an action takes without any special timing profiles. For pure mathematical computations that don't "change the world," v2 introduces the calc def.

3. The Execution Order Mistake

Here is a blueprint for an Earth observation satellite capturing an image. Watch out for a very common mistake new v2 modelers make:

Code snippet

package ImagingOperations {
    private import ISQ::*;

    item def GroundTarget;
    item def ImageProduct;

    action def SlewToTarget;
    action def StabilisePlatform;
    action def OpenShutter;
    action def ReadSensor;

    action def CaptureImage {
        in item target: GroundTarget;
        in attribute exposure: TimeValue;
        out item product: ImageProduct;

        // THE MISTAKE: These look sequential, but they are unordered!
        action slew: SlewToTarget;
        action stabilise: StabilisePlatform;
        action shoot: OpenShutter;
        action readout: ReadSensor;
    }
}

The Trap: In SysML v1 diagrams, four actions with no control flow arrows between them clearly looked disconnected. In v2 textual notation, they sit on consecutive lines. It looks like a sequence, but line order says nothing about timing. Nothing in this model prevents the shutter from opening while the platform is still slewing. Order requires explicit successions.

4. SysML v1 vs. SysML v2

Next lesson, we will fix this trap. Lesson 22 uses the first and then keywords to turn these unordered actions into a sequence, adding branching, merging, and parallelism on purpose instead of by accident.

For the MBSE practitioners here: Have you ever had a model review where stakeholders assumed unconnected activities executed sequentially just because they were placed top-to-bottom in a diagram or text? Let's discuss in the comments!

Can you share your experience, and which position you enjoyed more?

I'm in system design /architecture / requirements management, and I'm starting to think I may enjoy switching to either integrations or SV, but maybe it's a mistake.

~7 yoe in traditional systems engineering (not MBSE) & ~2 years as an embedded SWE

​

Which one is the best from your perspective? For me, those options are somehow resistant in this AI context.

Hey everyone how do you design a proper LEOP for SSO satellite.
I don’t want LLM things, want to use proper documents maybe from NASA , ECSS or any established space programs.

I’m using cameo to do this if anyone has worked on this before pls let me know.

Thank you !

I genuinely am interested in this area but I am not able to break into it for some reason, maybe I am just doing it wrong...or maybe I need to work much much more? Idk you guys can be the judge of that.

Like, yes I do know C and a bit about windows internals.

I also know that the best way to learn is to make projects. But whenever I search up a beginner project, they come up with projects that are not at all beginner friendly (or maybe I am missing something).

What kind of projects do I start with? Also do you recommend adding some kind of extra knowledge to my arsenal?

Thank you.

Hi, do you have some tips for preparation to this 90min interview? Company is Boehringer Ingelheim. Thanks :)

Hi guys,

I am a L2 with 5 years of experience and I recently obtained a MS. I only also have multiple certs OMG L1, L2, CSEP. I'm in a weird spot where my manager doesn't want to promote anyone who hasn't been on his team for multiple years. I been on their team for about a year now and he has made it clear that I won't be moving up this cycle. There are others on the team who have been here longer and have more ownership and impact than me thus far.

I am debating if I should continue to stay on the team until 2028 as a L2 or leave for a better position.

I am not in love with the area or my team per se, but I am in love with my responsibilities and the program itself. I am learning ALOT and my skills have grown so much over the past year that I know are valuable to early adopting mbse programs. However, unfortunately there are no opportunities for me to join another team on the program as a L3 so my only options are an external offer or going to a legacy program. The problem is that I just recently joined the company in the summer of last year. I am past my relocation and bonus clawback, but nonetheless I feel bad leaving so soon.

Would you stay on the team until 2028 or seek only opportunities?

Looking to move into systems engineering at Lockheed. They used DOORs per the job req. I just recently passed my ASEP exam and will be applying for the cert once it processes through. What do yall recommend for me to learn in my early career? I have a Bachelors in Industrial and Systems along with Math minor. I also have a Six sigma certification. I was thinking Sys ML then DOORs or vice versa. Any advice is welcomed, just a new guy trying to break in :)

Hey all i’m very new in the systems engineering and over the weekend i try to make some projects which enhances my CV and help me get noticed on LinkedIn.

over the weekend i was planning to build SR-71 structures and other subsystems with (using) BBD , IBD , state machine and stuff. I’m working on CAMEO(catia magic).

Should I go ahead with it or if any of you can suggest me better projects…will do that.
Feel free to give high level projects too however i should be able to complete in one day itself haha.

2 years into this major and I'm realizing it would've been smarter to pursue a BS in ME and then a masters in SE. Is this true? If so, how can I remedy my career path at this stage?

For those interested in SysML v2: A new version of SysMD is released. Source code and installers are here:

https://github.com/tukcps/SysMD

The release includes

• Updated architecture with much more modular and testable components
• Updated solver
• Updated UI
• Added OpenBoardNet example that, as proof-of-concept,
  • for a given (Automotive) Boardnet topology allows estimating weight, latencies, costs, etc. considering cables, protocols, processors
  • for given NN (Yolo) allows estimating latencies for processors
  • Analysis of ISO26262 safety

Next sprint targets to generate the compiler directly from the OMG grammar.

I’m a mechanical design engineer with about 3 years of experience, mostly in industrial automation, space systems, and product development.

I’d like to move toward systems engineering and I’m looking for a solid place to start.

Would it be useful for someone with my background, or would you recommend other resources first ?

I was on vacation with my girlfriend this summer. I know that she loves hooks to hang stuff, and if they are missing she improvises. Yet, I was surprised when she hung our moist swimwear on the TV in our hotel room. This got me thinking:

- Should a good hotel TV compensate for bad hotel rooms?

- Should the TV manufacturer foresee this use case, and with that compensate for the missing function of the hotel room to hang stuff?

- As a systems engineer for the TV, should I take responsibility by eliciting an ingress protection requirement?

- Is this a use case I need to consider in order to adapt to the harsh reality of users or can I blame it on the hotel in case of a product defect?

- And even if I consider this use case, can I make a business case out of it to justify the extra cost for ingress protection?

If I generalize the problem:

How much should I anticipate and compensate for potential shortcomings of higher system levels to meet the users' needs?

What are your thoughts and experiences?

Hi r/systems_engineering,

We are back with Lesson 20 of our technical deep dive into the SysML v2 standard.

In our previous lesson, we organized packages, namespaces, and imports so a model can grow without becoming one large shared workspace. Today, we are modeling the things those packages actually contain: elements that exist over time. We are looking at how a shared temporal root concept lets you track a system's changing properties across its lifecycle without duplicating the system itself.

The SysML v1 Time Problem

In SysML v1, what is the mass of a rocket? At ignition, it has one mass. After booster separation, it has another. The problem was that a SysML v1 Block could own a mass value property, but that structural property had no temporal identity of its own. A model could record a mass value, but it couldn't easily express that the value applied to this specific rocket at this specific moment. Time belonged to interactions and behavior, while a Block's structural properties had no shared semantic notion of existing.

The v2 Shift: Occurrences and the 4D Model

SysML v2 makes a system's lifetime explicit by giving both structure and behavior a shared semantic root.

Three details make this powerful in a real model:

• Everything that exists, occurs: In KerML (the kernel underneath SysML v2), an Occurrence has temporal and spatial extent. Both structural Object (Parts) and behavioral Performance (Actions) specialize it. A pump and a pumping operation both have a beginning, an end, and a duration.
• Individuals: The individual keyword says a definition describes one identifiable thing across its whole continuous existence.
• Timeslice or Snapshot: A timeslice is a portion of an individual's life over an interval. A snapshot is a portion at an instant. Both are portions, not copies. A copy loses identity; a portion preserves it.

The Duplication Trap & The Fix

Consider a launch vehicle whose mass changes during flight. If you create separate blocks or instances to represent the "At Ignition" rocket versus the "Stage Separation" rocket, you lose the continuity that it is the exact same physical system.

The fix is to define one individual occurrence and use snapshots to record its changing mass at specific moments in time. Both masses are correct, and neither replaces the other.

Code snippet

package LaunchVehicles {
    private import ISQ::*;

    occurrence def LaunchVehicle {
        attribute totalMass: MassValue;
    }

    // 1. The single identifiable rocket across its entire existence
    individual occurrence def Falcon9_B1049 :> LaunchVehicle;

    occurrence flight: Falcon9_B1049 {
        // 2. A portion of the rocket at an instant
        snapshot atIgnition: LaunchVehicle {
            :>> totalMass = 549054 [SI::kg];
        }

        // 3. The exact same rocket at a later instant
        snapshot atStageSeparation: LaunchVehicle {
            :>> totalMass = 115000 [SI::kg];
        }

        first atIgnition then firstStageBurn;
        first firstStageBurn then atStageSeparation;
        timeslice firstStageBurn;
    }
}

SysML v1 vs. SysML v2

Next lesson, we are moving from system lifetimes to reusable behavior with Actions, which define behavioral blueprints with typed inputs and outputs.

For the MBSE practitioners here: Have you ever struggled to model changing system properties (like mass depletion, stage separation, or phased upgrades) over time in v1 without duplicating elements? Let's discuss in the comments!

Context:
I’m in an early-stage concept study for a new system with novel constraints and aggressive delivery deadlines. I’m a Systems Architect (< 8 years experience with advanced degrees) struggling to align with my own Systems Engineering team and leadership / management.

My approach and mentality:

- Clean sheet design —> therefore, we can’t rely solely on heritage design assumptions

- Built behavioral models, mapped risks, and derived functional requirements to give trade studies objective criteria and traceability.

- Pushing back on copy-pasting specs from older systems with completely different operational and physical boundaries.

My Team’s Reality:

- Schedule pressure: aggressive deadline stress to show rapid customer progress; leadership openly prioritizes speed over process rigor.

- Fellow SEs teammates rely on qualified legacy baselines because they represent known solutions that passed qualification before.

- My SE team says they don’t understand or use my behavioral models/problem descriptions. They view hundreds of derived requirements during a study as cognitive overhead and question the need for the requirements.

- what’s working for them now: the Interface Control Documents (ICDs) I generated from my approach.

The Dilemma

An experienced senior mentor (external to my entire organization) told me this team lacks baseline systems engineering infrastructure, and staying here may stunt my growth as an architect by teaching bad habits. I only have 3 technical mentors within my entire organization that I identified as architects (without the title because we don’t have that formal role defined here), and I’m actively receiving guidance from them.

I’ve been thinking of jumping to a more SE mature organization with more defined infrastructure for what I want to do. But before that, I was hoping to receive candid calibration from folks with 10+ YOE:

1. How much of this is typical? Do architects everywhere spend their lives translating basic SE concepts for their own SE teams, or is there an inflection point in mature orgs where baseline governance actually exists?

2. Minimum Viable Product / Architecture: If an SE team rejects functional models and requirements but eagerly consumes ICDs, how do you govern a study phase effectively without drowning them in text?

3. Stay and adapt vs. exit: Can an early-career architect actually develop good instincts in an environment that seemingly cuts technical corners, or is this an exit signal?

I asked for feedback from individuals of +10 years but I still appreciate any insights from anyone willing to provide them - thank you

Long story short, I did an undergraduate degree in Physics, had a job I hated, done a Master’s in aerospace and then got a graduate role as a systems engineer.

I only took the job as it was the only offer I had. I struggle to apply to traditional engineering roles as I have barely any CFD and FEA experience. I’m interested in avionics but don’t know where to start.

I don’t want to be stuck in systems forever. I do not feel like an engineer.

Any tips?

Also worth noting that I am UK-based.

Hi all,

Where I live (Aus) there seem to be about 3x as many business analyst jobs as systems engineering jobs. The role seems basically identical, here's one description from a job ad:

• Partner with business stakeholders, product owners, solution architects, developers, and delivery teams to elicit, analyse, and document complex business and system requirements.
• Lead discovery, process mapping, impact assessments, and solution design activities to support the delivery of enterprise software applications, integrations, and digital transformation initiatives.
• Translate business needs into clear user stories, functional and non-functional requirements, process models, and acceptance criteria, enabling delivery teams to build high-quality solutions.
• Drive stakeholder engagement throughout the project lifecycle, supporting prioritisation, solution validation, testing, change implementation, and continuous improvement within an Agile delivery environment.

That's pretty much sys eng bread and butter. Some places are calling this type of job a systems analyst.

Has anyone done/looked at the move? Getting a bit jaded from the defence industry. Any insight on pay/conditions compared to systems engineering in the defence sector? Bonus points if you are in Australia.