To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the Systems Engineer, the glass is twice as big as it needs to be. – Anonymous

I’ve spent a couple decades watching systems engineering mutate across industries like some kind of evolutionary experiment nobody asked for. So here’s the field report.

To be clear, when I say systems engineering, I’m referring to the classical discipline, the one grounded in lifecycle theory, requirements analysis, architectural decomposition, interface definition, and verification planning. Not the IT flavor that resets passwords and configures VPNs. That’s a different ecosystem entirely.

The modern twist, of course, is the rise of software‑intensive systems, which forced organizations to confront an inconvenient truth: you can’t treat software as an afterthought when it’s 80–95% of the system’s functional behavior. Thus emerged the software systems engineer, a practitioner who applies traditional systems principles to systems where the “mechanics” are algorithms, state machines, and distributed architectures instead of gears, bearings, and combustion cycles.

In theory, software systems engineers follow the same methodologies as their mechanical and electrical predecessors: requirements elicitation, functional analysis, allocation, modeling, risk assessment, and V&V strategy.

In some organizations, software systems engineer team is formed separately under the software function, which absolutely makes no sense as systems engineer need to participate across the entire lifecycle including concept, feasibility, architecture, design, implementation, integration, verification, validation, release, sustaining, and retirement. If your “software SE” only shows up during development stage, you haven’t hired a systems engineer.

Do you need experience as an SE?

This comes up constantly. And yes, there are exceptions (some are actually really good), but let’s be honest, systems engineering is about breadth and depth, earned over years of building actual systems. You don’t get this from reading a book, watching a webinar, or printing out the INCOSE handbook and sleeping with it under your pillow.

Experience isn’t everything, but it’s one of the core ingredients. You don’t become a chef by reading a cookbook. You become a chef by burning things, under‑seasoning things, and eventually learning why none of that works.

How do you expect somebody to create an Italian cookbook if they’ve never boiled pasta before? – Vanilla Rice

Yet universities now offer systems engineering degrees and companies hire fresh graduates straight into SE roles. This goes against the very nature of the discipline and explains why so many organizations have systems engineering teams that perform like a Roomba trapped under a couch.

If you’ve never built a system, you’re going to struggle defining one, and the development teams will notice, immediately.

Final thoughts

There are countless reasons why systems engineering teams underperform. Some are organizational, some cultural, and some just a big misunderstanding. But if you want systems engineering to perform, then maybe treat it like a career path.