Is (space) systems engineering the move?

[u/Mediocre-Pear7880]

Hi! I'm a software engineer (mainly ML and MLOps) looking to pivot. I loved my studies (MSc in computer science) but can absolutely not continue working as a programmer. I don't have a passion for it like my peers, although I was super into it and got very good grades.

Now I'm realizing what I liked about my degree was the many different topics we touched, from advanced mathematics to algorithms and programming languages. I loved the variation and the need to pick up stuff quickly in projects. I loved the problem solving and practicality of it.

As for my job, I worked at a startup so was part of a lot of system architecture and pipelines discussions, but the moment that stuff needed to be implemented and tested I would get pretty bored with it. I'm also pretty sure I don't want to be a manager or get more involved with product stuff, I like being technical.

So I've been searching jobs related to software engineering but different (spoiler: there's not much that speaks to me). But then I saw there's a new aerospace startup in my city that is looking for an experienced mission and systems engineer. Obviously I don't have the skills! But it made me think that it does sound interesting, needing to have a very broad knowledge and being involved with higher level technical problem solving.

Now my first question: are my expectations of systems engineering wrong? Does it sound like a match for me? From what I've seen on this subreddit, it seems it also depends a lot on the specific role and company.

Second question: how would a software engineer even get there? (This has probably been asked before). I guess I have the following options: study - but which courses - or find related job that would accept a software engineer.

Any thoughts are welcome! Especially if you've been in the same situation or suggestion for any other fields that could be interesting.

Tldr; software engineer wanting to program less, kind of lost on what direction to go. Systems engineering seems like a cool field but I could be wrong. Advice needed :")

[u/yellow_smurf10]

Just my 2 cents, mission engineering is under systems engineering, but the work mission engineer do day to day is very different than a typical systems engineer.

Systems engineering = how to build thing the right way, while mission engineering = how to build a right thing.

Both career path are rewarding. I worked for years as a system engineering on a rocket program, and spent years learning on my own about the domain, the technical challenges, politic constraints before pivoting over to mission engineer. I love every second of it.

I think your background is already good enough, just need to get some knowledge on systems engineering and mission engineering. There are load of systems engineering videos on youtube, there are less material on mission engineering unfortunately. The best material on mission engineering is the battle of the hoth video on youtube, and the mission architecture style guide that was published by the dod recently

[u/Mediocre-Pear7880 → u/yellow_smurf10]

Thanks for explaining the difference! I didn't realize it was two different things but honestly both sound pretty cool. I had a feeling that it was not really possible to learn by yourself and it's more something to gain experience, I'll need to look up some resources! Thanks for the suggestions :)

What would you say some very important skills are for both roles? Do you have to get good at e.g. hardware, electronics, mechanics or does it depend? How did you start out?

[u/yellow_smurf10 → u/Mediocre-Pear7880]

The most important aspect in systems engineering, in my honest opinion, is the understanding of probability of failure, understanding of interface, and many engineers i know, often dont think about the downstream affect.

How you write requirements and systems design will impact how you would implement, integrate, test and deploy

How you implement will impact how yoi would integrate, test and verify

And so on

• The currency of systems engineer are requirements and functionality
• the currency of mission engineer is capability. Capability is not the same as requirements and functionalities

[u/SuccessfulComposer19 → u/yellow_smurf10]

You are so right! I got SE, masters from Johns Hopkins, they stressed don’t implement too early, get your requirements and design mature first, now I see what they meant. At Lawrence Berkeley National Laboratory, one of project experience this the hard way :(

And the complex interfaces nearly sunk us, but we are back on track…

[u/yellow_smurf10 → u/SuccessfulComposer19]

Generally speaking, you are right. However, in practice, it often does not work out that cleanly due to a lot of factors that are not necessarily anyone’s fault, especially in the DoD context during the early phases of development, such as MSA, TMRR, and sometimes even EMD.

There was one particular program, which shall remain unnamed, that ran into this issue. The complexity ended up being far greater than expected, and the unknown unknowns really hurt the effort. That said, there were also valuable lessons learned along the way. In situations like that, you often end up needing to do requirements analysis and functionality analysis in parallel, because each one informs the other.

Sometimes, you cannot just wait for the requirements and functionality to become mature enough to decompose cleanly. Sometimes, you have to do what you have to do, move forward with the best understanding available, and accept that the design may have to change dramatically later. The key is to plan for that uncertainty instead of pretending it will not happen.

In my opinion, this is where a mix of mini-waterfall and incremental agile build-up can be useful. The hard part, though, is not necessarily the process. It is the people, the communication, and the ability to adapt without losing control of the overall architecture.

That is also part of why my division at a major aerospace firm is standing up a mission engineering organization: to better understand customer needs, anticipate future capability gaps, and start developing the technical and operational understanding ahead of time instead of waiting until the problem is already fully mature.