This past week I just started a new role as a Systems Engineer from my previous job as a Software Engineer. I had worked with Systems Engineers in the past, however at the time I never really got a good view into what they did. Were they just ‘big picture’ engineers with project manager-like responsibilities? Or was there more to it?
Honestly, I had some reservations on what a Systems Engineer did at my previous company. Every company has their own methods that work well for them, and the way what they had was certainly an efficient process for getting things done. When requirements are vague, so will the software vaguely work for what you want.
It always seemed that the Systems Engineers I worked with were closer to managers with technical backgrounds- mostly concerned with the deliverables we had to meet and asking Software Engineers to create documentation and follow processes that seemed like a lot of overhead and extra effort to follow. Not something I was particularly interested in- given time constraints. I even got questions from colleagues asking “Why would you want to switch?” and “Once you go, you never come back- you’ll find it hard to write software again.”
HOWEVER…
Even only after the first week of working as Systems Engineer, I really regret those reservations and wish I could’ve worked more closely with what a good Systems Engineer has to offer. One could say I’m ‘drinking the koolaid’. The reality of the matter is as I get closer to understanding my newfound role is that Systems Engineers can wear many hats depending on the need. This could just as easily mean filling in as a Project Manager, Software Engineer, or Requirements Engineer if that role requires filling or supplementing. Heck, if you’re the only engineer on a project (which happens a good bit in smaller operations), you ARE the Systems Engineer. The only question is, are you a good Systems Engineer?
What I had done before as a Software Engineer was a fantastic way to get a solution to solve a problem quickly. Very much what I would call Cowboy Programming. He’s sexy initially, and quick on the draw, but you can’t depend on him except for that one duel/project demo at high noon. There’s a chance he’ll die, or quit as the only one who knew how to even run his software.
The Cowboy Programmer isn’t all that bad though. After all, he’s excellent at what he does- making something that will work for you in a very short period of time. All he needs is a little organization to funnel the creativity down a path that’s manageable for the rest of us to follow. Ideally, very little overhead is created. A meeting a week to go over current progress and configuration management processes such as peer review will keep from things getting too wild in the code base.
Some proponents of things like Agile say that’s too long, and it should be a daily activity. I think most software engineers will agree that a ‘good day at work’ is a day where they did nothing but their job- program. I’m inclined to agree that as good for visibility morning standup meetings are, I personally think they’re a waste of time. But that’s another topic for another time.
A Band Nerd Analogy
Since we’re playing with analogies, the Systems Engineer is analogous to a conductor, and every engineer working with them is a musician who knows how to play a different instrument. The conductor himself has played an instrument in the past- as a systems engineer probably came from another engineering discipline. He can read sheet music and has a basic understanding of how the rest of the orchestra is meant to sound, and can adjust accordingly when he hears the flute section getting behind again.
You really want everyone to be chief engineer.” – Elon Musk
In the role of someone playing an instrument, you want to be paying attention to the things the director sees. Everyone should have visibility on a project, its overall goals and their part in the big picture. I find in the limited projects I’ve worked on the one of the indicators of a project with longevity is everyone on the team knowing what they’re working towards and how their part in the system fits with the bigger picture. Things like Model Based Systems Engineering (MBSE) can help in seeing what the finish line looks like and tracking how we came to the solution we have today. Was it a “I think this should be required because I’ve used it before” kind of requirement, or was it backed by data?
The issue with that is, everyone needs to know how to read the sheet music. MBSE can quickly become as spaghetti-like as your code if you aren’t intentional about it. Below is a real Use Case diagram from a whitepaper by the Systems Engineering Research Center. I want to say it’s just an example, but this is actually the research team that wrote it and their roles all mapped out.
So a Systems Engineer is just superman, he can do anything? No, quite the opposite. A director doesn’t make much music without an orchestra. Don’t get me wrong, the systems engineers that I’ve met are incredibly talented and typically experienced in a field outside of systems engineering, but the best ones also know the value of others’ capabilities.
So what’s really to be learned here?
The bottom line is I personally took a role as a Systems Engineer while I was perfectly happy as a Software Engineer for one reason- I need to see the bigger picture. I don’t want to give the wrong impression- there’s no place I’d rather be than in my own code for weeks on end with no one to bother me. As I mentioned above, I kind of loathe following processes and documentation instead of just letting the code flow. But I’ve done that enough times that when I look up, the entire thing I was writing in the first place wasn’t what was needed anymore, or the code I had written in such a manner that -even when I had it working- I couldn’t read it anymore.
I hope learn ways that I can improve my own capabilities in writing software by understanding things from a Systems Engineer’s perspective, writing requirements, understanding needs, and implementing processes in order to make more effective use of my time that doesn’t require as much overhead. Sounds easy enough, right?