Scrum and Agile seem to be dying. I had a Product Owner and Scrum Master cert for years on my resume but i've dropped it from my current. Feels now like the ancient webmaster title of the mid 90s. Made for another timeline which is not more relevant.
DevOps is another sad story as it was a saner approach to get people skilled for both dev and ops but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
Exactly. The field is already too complicated, you can learn a lot without learning literally everything.
Actually, no one learns literally everything. "DevOps" mean that developers should prioritize learning ops over learning deeper something else (because ultimately there are only 24 hours in a day). Which sounds crazy to me; it would be better if the team had experts on different things cooperating together, rather than everyone being mediocre at everything.
That said, companies love replaceable people, or at least they love to imagine that everyone is replaceable. So when everyone becomes DevSecOpsCloudAccountantJanitor, it feels like as long at they keep one such person in the company, they got everything covered.
As someone who has been in the "robot devops" space for like a decade now, I think with robot companies it becomes particularly acute because:
- Ops for cloud services and ops for deployed robots are very different beasts, so it's really two different teams that could both reasonably be "devops".
- Ops/tools for robot developers is different since you're often dealing with simulation environments (local, cloud) and also managing access to a more constrained pool of test hardware, all of which needs to be able to quickly recover and restore itself to factory state after developers or their code have done unspeakable things.
- Deployed units are often the worst of both worlds between multiple domains. You've got the big deployment assets of a data center but without the big data pipe; nothing is virtualized so you can't just throw away a node that goes bad; you're stuck supporting hardware snowflakes (here's a text file somewhere with the list of units that have bad CPU fans and need different frequency caps); it's like IOT but with the power and disk and observability requirements of a real server.
> but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
Titles like these always mean something different from company to company.
Even “product manager” has had different meanings at my different employers, some times with major consequences for people who got hired into those roles expecting to do one type of work and then being evaluated on different expectations.
For DevOps, there were a lot of unrealistic expectations from everyone who saw the word and assumed they knew what it meant. I saw a lot of engineering leaders come up with completely different expectations for DevOps roles, but when the chaos arrived most of them reduced the DevOps people into the responsible-for-everything people, which just burned people out.
I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
> I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
This depends on the org, but product managers I've worked with spend a lot of time speaking directly with users, particularly in B2B shops. Between speaking with customers and communicating product plans both upwards (to GMs/VPs/exec etc) and outwards (to your own team + external teams) you really shouldn't have a lot of time to build anything as a PM, even with AI.
DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles.
Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
Very few people want that in their life, money be damned. Same way in an ideal world devs should also participate in customer support, but very few could really do it or handle that for years.
Last team I was on was repsonsible for supporting and maintaining their product, with help from the SRE team. It means after-hours support for issues and (maybe) releases but I think this was the right way. You became the backstop and support resource for things like data center outages and DDOS attacks that were largely the responsiblity of the (much smaller than many places) SRE team. We also put devs very closely behind front-line customer facing staff where it made sense (ex: reporting & analytics - yes, platform - probably not). It made the devs better and they might try and deny it but I think most of them actually appreciated it. #YMMV
> being in the war room when a data center goes under
When doesn't this involve devs? If you have ops separate and isolated from the development effort, a devs representation will have to get involved at some point.
> DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles. Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
That's exactly the issue that DevOps aims to solve, though. When you have developers who have no ownership or responsibility once the software is running on production, it becomes a "throw it over the fence" situation, and devs don't care about the operational side.
Logging? Who needs that, if there's a bug report I'll reproduce it on my local machine (and if I can't, CLOSE-WONTFIX!) Performance monitoring? That's an ops problem, tell 'em to buy better hardware. Application crashes? Works on my machine, probably a bug in the server config; ops problem. Tell them to set up a scheduled restart every hour.
You still need dedicated operations staff who deal with the overall system health and design, but yes, a developer needs to be involved when a DDOS brings down the service, because how should the system behave under heavy traffic? Can it serve up cached read-only pages? Did someone find a very CPU-intensive public endpoint that is being exploited and needs to be fixed? Only your developers can answer this question, not the ops team.
>DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions
That's why they have to be the same team. Your dev team needs to: 1. understand how to write code that can be debugged and recovered in a crisis, 2. learn to write code that doesn't cause the crisis in the first place, 3. have the motivation to do so because they will be the ones paged.
Anything else produces are far worse experience for everyone involved, especially customers.
The problem I've seen with DevOps is that some fief-builder sets up a "DevOps Organization", which is literally the opposite of what DevOps means.
DevOps should be a guiding principle for the organization, not a dedicated role. Every developer (or at least: every team) should be able to
- speak to production users
- ship to production
- monitor and learn from production usage
You don't need "devopsy" skills to do that, rather organizational structures that allow for incremental change. FWIW, deployments could still be a 2005-like upload via FTP, and the benefits of DevOps could still be reaped.
All have been meaningless except for Cloud Infrastructure Engineer. The rest described a generalist who knows how to deal with ambiguity and (usually) has the trust with things like AWS root account credentials. Most organisations have no idea what real DevOps is. If they did, they wouldn’t hire for a “DevOps Engineer”
I enjoyed looking back at my 20 year career through roles. I've done a few of them crossing domains twice. The tree should be seen as a constant evolving graph. There will be a plethora of new roles in the coming years.
For those who think Software Engineering roles are extinguishing, they just need to realize roles will evolve into something new. My current role (SRE) was a nascent niche at the start of my career and I didn't even know about it for many years.
I’ve always been “software engineer” or some variant thereof, but always with the implication that you pick up any tech stack and learn it well enough to be productive. Often it was not the new programming language(s) that were challenging, but some really difficult black box tool (API, platform, database, framework, etc.), and even MORE challenging, the unnecessarily complex development environment.
I've had the title on and off since 2018, I assume we are pretending with DevOps that pure operations / ops management doesn't exist 0:-)
More charitably though, I think they are not focusing on operations despite it being one of the categories - I don't see incident coordinator / manager, problem manager, etc either.
It's fascinating seeing all these in one place with the relationships and over time. I'd love to see one with the less formal titles (I like to go by "developer" personally though it's not my job title), but it would be gigantic.
IME, you see changes in numbers over time but the titles data analyst, data engineer, analytics engineer, data scientist are all still around. data platform engineer or SWE data seems to be stable as a systems role but anecdotally there is less demand for data roles now due to AI (either believed capability or deferred hiring to understand near term needs).
Software is mostly human-defined. The complexity mostly comes from understanding the meaning of a large corpus of existing text, and then building your thing on top of existing human-created conventions. Therefore, I suggest we start calling ourselves Software Lawyers, Software Judges, and Software Legislators. This is a much more sensible set of titles than “software engineer” and “architect,” and it will probably cause less confusion and pointless bickering.
This was interesting to look at. I know it's not supposed to be perfect but it certainly does make one think about the career routes available. What surprised me was how short the path was for security to getting into the C-Suite. Although I do feel like most people become security analysts, then ISOs. Also I didn't realize that tape librarians were still a thing.
> When I’m asked what the difference is between a DevOps engineer, an SRE and a platform engineer, the honest answer is always a little history lesson. This is the shortest version of that lesson I’ve managed so far.
Unless you talk to a recruiter and they say something like your more of a SRE then a DevOps engineer and we really need a devops engineer. Insansity
I think there should be more domains included other than mobile/backend/frontend, there’s software engineers working on robotics/graphics/aviation but not necessarily embedded engineer
Scrum and Agile seem to be dying. I had a Product Owner and Scrum Master cert for years on my resume but i've dropped it from my current. Feels now like the ancient webmaster title of the mid 90s. Made for another timeline which is not more relevant.
DevOps is another sad story as it was a saner approach to get people skilled for both dev and ops but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
A dev can very much enjoy learning new skills without feeling any desire for the pressure and burden of having to deal with ops.
Ops is when what you made collides with reality. Replacing "ops" in your post with "reality" gave me a good chuckle.
Now I'm reading every comment here, substituting "Ops" with "Reality" and it's hilarious.
Exactly. The field is already too complicated, you can learn a lot without learning literally everything.
Actually, no one learns literally everything. "DevOps" mean that developers should prioritize learning ops over learning deeper something else (because ultimately there are only 24 hours in a day). Which sounds crazy to me; it would be better if the team had experts on different things cooperating together, rather than everyone being mediocre at everything.
That said, companies love replaceable people, or at least they love to imagine that everyone is replaceable. So when everyone becomes DevSecOpsCloudAccountantJanitor, it feels like as long at they keep one such person in the company, they got everything covered.
As someone who has been in the "robot devops" space for like a decade now, I think with robot companies it becomes particularly acute because:
- Ops for cloud services and ops for deployed robots are very different beasts, so it's really two different teams that could both reasonably be "devops".
- Ops/tools for robot developers is different since you're often dealing with simulation environments (local, cloud) and also managing access to a more constrained pool of test hardware, all of which needs to be able to quickly recover and restore itself to factory state after developers or their code have done unspeakable things.
- Deployed units are often the worst of both worlds between multiple domains. You've got the big deployment assets of a data center but without the big data pipe; nothing is virtualized so you can't just throw away a node that goes bad; you're stuck supporting hardware snowflakes (here's a text file somewhere with the list of units that have bad CPU fans and need different frequency caps); it's like IOT but with the power and disk and observability requirements of a real server.
> but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
Titles like these always mean something different from company to company.
Even “product manager” has had different meanings at my different employers, some times with major consequences for people who got hired into those roles expecting to do one type of work and then being evaluated on different expectations.
For DevOps, there were a lot of unrealistic expectations from everyone who saw the word and assumed they knew what it meant. I saw a lot of engineering leaders come up with completely different expectations for DevOps roles, but when the chaos arrived most of them reduced the DevOps people into the responsible-for-everything people, which just burned people out.
I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
> I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
This depends on the org, but product managers I've worked with spend a lot of time speaking directly with users, particularly in B2B shops. Between speaking with customers and communicating product plans both upwards (to GMs/VPs/exec etc) and outwards (to your own team + external teams) you really shouldn't have a lot of time to build anything as a PM, even with AI.
DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles.
Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
Very few people want that in their life, money be damned. Same way in an ideal world devs should also participate in customer support, but very few could really do it or handle that for years.
Last team I was on was repsonsible for supporting and maintaining their product, with help from the SRE team. It means after-hours support for issues and (maybe) releases but I think this was the right way. You became the backstop and support resource for things like data center outages and DDOS attacks that were largely the responsiblity of the (much smaller than many places) SRE team. We also put devs very closely behind front-line customer facing staff where it made sense (ex: reporting & analytics - yes, platform - probably not). It made the devs better and they might try and deny it but I think most of them actually appreciated it. #YMMV
> being in the war room when a data center goes under
When doesn't this involve devs? If you have ops separate and isolated from the development effort, a devs representation will have to get involved at some point.
> DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles. Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
That's exactly the issue that DevOps aims to solve, though. When you have developers who have no ownership or responsibility once the software is running on production, it becomes a "throw it over the fence" situation, and devs don't care about the operational side.
Logging? Who needs that, if there's a bug report I'll reproduce it on my local machine (and if I can't, CLOSE-WONTFIX!) Performance monitoring? That's an ops problem, tell 'em to buy better hardware. Application crashes? Works on my machine, probably a bug in the server config; ops problem. Tell them to set up a scheduled restart every hour.
You still need dedicated operations staff who deal with the overall system health and design, but yes, a developer needs to be involved when a DDOS brings down the service, because how should the system behave under heavy traffic? Can it serve up cached read-only pages? Did someone find a very CPU-intensive public endpoint that is being exploited and needs to be fixed? Only your developers can answer this question, not the ops team.
>DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions
That's why they have to be the same team. Your dev team needs to: 1. understand how to write code that can be debugged and recovered in a crisis, 2. learn to write code that doesn't cause the crisis in the first place, 3. have the motivation to do so because they will be the ones paged.
Anything else produces are far worse experience for everyone involved, especially customers.
The problem I've seen with DevOps is that some fief-builder sets up a "DevOps Organization", which is literally the opposite of what DevOps means.
DevOps should be a guiding principle for the organization, not a dedicated role. Every developer (or at least: every team) should be able to
- speak to production users
- ship to production
- monitor and learn from production usage
You don't need "devopsy" skills to do that, rather organizational structures that allow for incremental change. FWIW, deployments could still be a 2005-like upload via FTP, and the benefits of DevOps could still be reaped.
So far in my career:
- DevOps Engineer (Junior, Senior, Staff)
- Systems Development Engineer
- DevOps Team Manager
- Cloud Infrastructure Engineer
- Site Reliability Engineer (+Lead)
All have been meaningless except for Cloud Infrastructure Engineer. The rest described a generalist who knows how to deal with ambiguity and (usually) has the trust with things like AWS root account credentials. Most organisations have no idea what real DevOps is. If they did, they wouldn’t hire for a “DevOps Engineer”
DevOps requires tooling and infrastructure, and at a certain size, a dedicated DevOps Engineer optimizes that tooling. What's wrong with that?
Where does “Member of Technical Staff” fit on this tree? At the bottom should all arrows just feed into “Member of Technical Staff”?
I enjoyed looking back at my 20 year career through roles. I've done a few of them crossing domains twice. The tree should be seen as a constant evolving graph. There will be a plethora of new roles in the coming years.
For those who think Software Engineering roles are extinguishing, they just need to realize roles will evolve into something new. My current role (SRE) was a nascent niche at the start of my career and I didn't even know about it for many years.
Very few think that SWE roles will completely disappear. The main concern is that whatever it evolves into, the world will need far fewer.
Before data scientist, there was data miner or data mining engineer.
I’ve always been “software engineer” or some variant thereof, but always with the implication that you pick up any tech stack and learn it well enough to be productive. Often it was not the new programming language(s) that were challenging, but some really difficult black box tool (API, platform, database, framework, etc.), and even MORE challenging, the unnecessarily complex development environment.
Surprised “Web Designer” didn’t make the cut. That is what we were often called between being a Webmaster and Web Developer.
I can't see Operations Manager listed, yet I've had that title for the last 15(?) years.
I've had the title on and off since 2018, I assume we are pretending with DevOps that pure operations / ops management doesn't exist 0:-)
More charitably though, I think they are not focusing on operations despite it being one of the categories - I don't see incident coordinator / manager, problem manager, etc either.
It's fascinating seeing all these in one place with the relationships and over time. I'd love to see one with the less formal titles (I like to go by "developer" personally though it's not my job title), but it would be gigantic.
As a kid I always wanted to be a SysOp. Not that I knew what it was, all I knew was it had to do with computers and sounded cool. That was enough.
Would be nice if I could actually see it. I cannot zoom in, zoom out or do anything with it.
It’s here: https://ianmiell.github.io/sw-job-title-family-tree/
agree, the ui to navigate this data is very uncomfortable, I guess we're gonna need a front-end developer here to fix it. :)
There's a link to the SVG version of it that you can navigate using your browser's normal interface controls.
CTRL+scroll wheel to zoom
On mobile you can pinch zoom on the png file: https://ianmiell.github.io/sw-job-title-family-tree/job_titl...
IME, you see changes in numbers over time but the titles data analyst, data engineer, analytics engineer, data scientist are all still around. data platform engineer or SWE data seems to be stable as a systems role but anecdotally there is less demand for data roles now due to AI (either believed capability or deferred hiring to understand near term needs).
My first paid job, at 21, in 1999, was "Senior Network Operations Engineer".
I've never been able to take "senior" seriously since.
Member of Technical Staff is missing
> In 1947 coding was the clerical bit, and the real work was in the planning.
A tale which of course, flatters the planners…
Heh heh. Meanwhile in 2026, the developers are doing the real work, including those heavily employing AI. Which flatters me :-)
Where’s member of technical staff?
These days I half-jokingly (it’s on my slack profile “position” field) refer to my self as a Serious Product Vibe’ineer.
Where does this fit in on the chart?
Software is mostly human-defined. The complexity mostly comes from understanding the meaning of a large corpus of existing text, and then building your thing on top of existing human-created conventions. Therefore, I suggest we start calling ourselves Software Lawyers, Software Judges, and Software Legislators. This is a much more sensible set of titles than “software engineer” and “architect,” and it will probably cause less confusion and pointless bickering.
This was interesting to look at. I know it's not supposed to be perfect but it certainly does make one think about the career routes available. What surprised me was how short the path was for security to getting into the C-Suite. Although I do feel like most people become security analysts, then ISOs. Also I didn't realize that tape librarians were still a thing.
Where is Prompt Engineer?
What's the source of this data?
Jokes on you, I'm a Senior Systems Engineer.
> When I’m asked what the difference is between a DevOps engineer, an SRE and a platform engineer, the honest answer is always a little history lesson. This is the shortest version of that lesson I’ve managed so far.
Unless you talk to a recruiter and they say something like your more of a SRE then a DevOps engineer and we really need a devops engineer. Insansity
I think there should be more domains included other than mobile/backend/frontend, there’s software engineers working on robotics/graphics/aviation but not necessarily embedded engineer