Long ago, I was hired as a "systems engineer." My boss described it loosely as a super-technician who doesn't fit into any of the traditional engineering disciplines such as electrical and mechanical. The unspoken expectation was that the traditional engineers would design the pieces, and then the systems engineer would be the one to get them all working together.
That was a lot of fun for a while, but it was pretty clear that I needed to get in front of projects, rather than behind them, to have any useful impact on new products. Also, I hit a couple of home runs: Creating the architectures for a couple of successful products because nobody else wanted to learn the theory. So I was invited to have a more front-end role.
This led to a new informal definition of "systems engineer." I've become the person who understands how products work in their entirety, when it requires synthesizing knowledge from multiple disciplines. I create and test the theory of operation. This is a good use for physicists in industry, by the way. Physics research, especially in small labs, is multidisciplinary. We don't really have any of our own techniques, so we constantly borrow from others. My graduate research involved optics, electronics, programming, mechanics, and data analysis. In fact, I've dropped the "systems engineer" title, and am now a "scientist."
Today, I'm at a level where I am much more focused on onboarding and development of junior colleagues. I'm also finding and developing talent within the organization for people who might like to have more of a systems role. It is a hard role to fill, because engineers tend to specialize -- perhaps for good reason based on job markets. And if traditional engineers get good enough at coding to do it for money, they get sucked up by the software industry.
> This led to a new informal definition of "systems engineer." I've become the person who understands how products work in their entirety, when it requires synthesizing knowledge from multiple disciplines. I create and test the theory of operation.
How is that an informal definition of it? It's almost identical to the Wikipedia description of it:
> Systems engineering focuses on analyzing and eliciting customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem, the system lifecycle.
Damn, that sounds like an extremely cool career. Have you written about it in more detail before? Would love to hear more specifics (as allowable) about your path.
That was a lot of fun for a while, but it was pretty clear that I needed to get in front of projects, rather than behind them, to have any useful impact on new products. Also, I hit a couple of home runs: Creating the architectures for a couple of successful products because nobody else wanted to learn the theory. So I was invited to have a more front-end role.
This led to a new informal definition of "systems engineer." I've become the person who understands how products work in their entirety, when it requires synthesizing knowledge from multiple disciplines. I create and test the theory of operation. This is a good use for physicists in industry, by the way. Physics research, especially in small labs, is multidisciplinary. We don't really have any of our own techniques, so we constantly borrow from others. My graduate research involved optics, electronics, programming, mechanics, and data analysis. In fact, I've dropped the "systems engineer" title, and am now a "scientist."
Today, I'm at a level where I am much more focused on onboarding and development of junior colleagues. I'm also finding and developing talent within the organization for people who might like to have more of a systems role. It is a hard role to fill, because engineers tend to specialize -- perhaps for good reason based on job markets. And if traditional engineers get good enough at coding to do it for money, they get sucked up by the software industry.