I still call myself a "Systems Engineer" despite my role being usurped by HR and middle management into the 'new' hotness: "Site Reliability Engineer".
Thanks to people doing DevOps burning out, it's like an ongoing joke/question as to what 'DevOps' is vs. 'SRE' when in fact it was all work that a 'Systems Engineer' performed prior to someone in middle management working with HR to justify their roles changed my title despite the work not changing a bit during their bi-annual "reorganization".
As someone who is on the hunt for a new place to land, it drives me crazy how the title doesn't match the role description and often when you interview there are times when it doesn't even match the expectations. And the depressing part is that it's difficult to even find "Systems Engineering" jobs unless it's with another industry with different skill sets all together.
But as managers are likely finding out now, most developers don't want to do Systems Engineering as it's a cross-team discipline to pull all the resources together and operate complex systems with greater proficiency (in many different metrics) and maintain service delivery (in multiple other metrics).
What has been interesting is this resurgence in people trying to figure out what "Ops" and "SE" did for developers that they have been thrown into doing and learning how little they actually knew. Partly our own fault, of course, as nobody really wants to know how the sausage is made. But they also didn't envision where our sights were set in the future once we got people doing more self-service resource and code deployment. That just getting the apps launch were just the beginning, that to deliver robust code requires metric gathering, SLA, Chaos Engineering, how to get the right metrics tracked and to look at all the signals as a organism to teach machines how to heal themselves.
But it always comes back to respecting the process while pushing forward education of the people taking part in it. Tearing down the silos while also demonstrating often the value of engineers who know everything but their app/service/code - yet is able to learn it and architect solutions.
Thanks to people doing DevOps burning out, it's like an ongoing joke/question as to what 'DevOps' is vs. 'SRE' when in fact it was all work that a 'Systems Engineer' performed prior to someone in middle management working with HR to justify their roles changed my title despite the work not changing a bit during their bi-annual "reorganization".
As someone who is on the hunt for a new place to land, it drives me crazy how the title doesn't match the role description and often when you interview there are times when it doesn't even match the expectations. And the depressing part is that it's difficult to even find "Systems Engineering" jobs unless it's with another industry with different skill sets all together.
But as managers are likely finding out now, most developers don't want to do Systems Engineering as it's a cross-team discipline to pull all the resources together and operate complex systems with greater proficiency (in many different metrics) and maintain service delivery (in multiple other metrics).
What has been interesting is this resurgence in people trying to figure out what "Ops" and "SE" did for developers that they have been thrown into doing and learning how little they actually knew. Partly our own fault, of course, as nobody really wants to know how the sausage is made. But they also didn't envision where our sights were set in the future once we got people doing more self-service resource and code deployment. That just getting the apps launch were just the beginning, that to deliver robust code requires metric gathering, SLA, Chaos Engineering, how to get the right metrics tracked and to look at all the signals as a organism to teach machines how to heal themselves.
But it always comes back to respecting the process while pushing forward education of the people taking part in it. Tearing down the silos while also demonstrating often the value of engineers who know everything but their app/service/code - yet is able to learn it and architect solutions.