EDIT: I just wanted to add an edit and say I really appreciate how active this post got. I was kind of expecting to get no responses, but instead I’m getting an incredibly detailed discussion with a wide range of viewpoints and considerations that I wouldn’t have otherwise thought of. You guys rock! Lemmy rocks!
Hey, all
I need help identifying a job title that would best match my current job responsibilities. For reference, I work at a smaller org that just had a compensation study done and my position was marked as needing no change. My supervisor was angry with that outcome and found out that it is because my actual Job Title is not an industry standard, so the company that did the study had trouble matching it up. My supervisor believes I should be making a fair chunk more than I make, as I am the sole person in my position and the work I do keeps the org running in all ways.
So, my supervisor is starting the process to reclassify me into new position and wants to make sure the title and responsibilities match up in a way that are recognizable on a resume to other potential employers. I’ve done some initial research and I believe that “Senior DevOps Engineer” or a flat “Senior Software Engineer” would probably be the best match.
A list of my responsibilities are:
- I investigate, troubleshoot, code, schedule, and deploy new custom programming releases to our ERP software. It’s a delivered ERP software that has the ability to create, package, and deploy custom coding in order to add functionality that the org needs but the delivered solution does not support. Our org is especially heavily customized - we have well over 200 different customization’s that I support
- I code, deploy, and support data integrations with third party vendors via SFTP, HTTP API, or other options (although most of the integrations come down to either pulling data from our system to push to an SFTP server or an API).
- I build and deploy custom applications on an ad hoc basis to fill needs by our org. An example of this would be that earlier this year we found out that the budget entry portion of our ERP software wasn’t available as it used a user interface that had reached end-of-life and we needed a way for departments to enter their budgets for the upcoming FY to buy time until we could get the proper user interface up and running. I was able to build a web application that could fulfill the requirements and coordinated with our systems administration team to get a server set up with certs, a proper domain name, and the like.
- I act as a general administrator for our ERP software, providing support and guidance on specific functions that members of our Org use as well as backing up our actual ERP Technical Administrator in maintenance tasks if he is sick or out.
- I support the deployment of data from our transactional ERP system to a reporting database and our reporting software. This is largely automated and works without interference. If new data is needed, I go in and make the necessary changes to include the new data in the reporting database.
- We don’t currently have any other developers, but my boss and I have started pushing to expand our slate as other members of our team retire. If we ever do get more developers, it will be my responsibility to train them and coordinate their tasks.
In general, I feel like I identify more as a Senior Software Engineer. I like the programming work more and, if I ever left this current org, it’s the job I would go for. However, for the sake of actually matching the position, I feel like the wide range of development, administrative, and automation duties, that I am more doing the job of a DevOps Engineer.
I’ve done a fair amount of reading, but I wanted to get the opinions of some peers and see if you all had any insights or opinions
You must log in or register to comment.
Don’t put yourself into the DevOps category if you can help it. In the context of hiring / hr, DevOps is a marketing term with little to no actual meaning. As it goes with marketing terms, they iterate with the times and often rather quickly. If FAANG publishes a blog post about “stop doing DevOps, do X” today, 90% of DevOps positions will disappear from the market tomorrow.
Software Engineer is a very generic role that will serve you for longer, especially if your company puts a lot of stock into titles, as it seams like they do. Also, from my experience, Software Engineers get paid more.
That was something I was worried about. It’s a title I hear a lot about, but I don’t actually know that much about it. This is very helpful information.
Thank you for your insight!
The problem is that DevOps is not really a title or a role, its a mindset. It can be summarized as “You build it, you run it” and is supposed to solve the age old problem that arises from the disconnect of developers and sysadmins, where developers just hand over code to the admins without ever having given much thought about how to run it reliably (aka. “You go figure that out, not my problem.”) and the admins being super protective of their painstakingly curated servers and databases that of course you as a developer obviously cannot have any access to whatsoever and of course your app has to work with the 10year old java version that ships with RHEL. The consequence was basically a lot of grief on all sides and huge waste of productivity.
The idea of DevOps is that these two responsibilities merge into on. That means that the team responsible for building the software also needs to take care of how to test it, how to build it, how to deploy it, how to monitor it, how to scale it, how to debug it, etc. This is now mainly incorporated into the software developer / “full stack” role.
The confusing part is, when you look at job postings, the DevOps engineer is often described as “working closely with” or “supporting / assisting” the development team. This goes pretty much against the principle of having the development team having responsibility for their own work. Instead, it’s often just a re-branding of the old role with the title du jour. It also often details the pecking order, namely devops being support for developers.
Given that, if a company offers a DevOps position, you should spend some time finding out what that actually means for you, your work and your career. More often than not, it may put you in a box that only comes with restrictions for not obvious benefit.
Oh I see.
So, in theory, dev ops could apply to what I’m doing (just by way of being the only person responsible for building, testing, deploying, monitoring, debugging) - but, in reality, that isn’t often the case and it would be best to avoid putting myself in that box? Am I understanding that right?
Yes, that pretty much my point :)
Thank you!
I will see about sticking with the Software Engineer line of titles (I’m discussing whether or not calling myself a ‘Senior’ would be a good choice with some other commenters). It makes more sense and my supervisor had mentioned that she wants the best title that could represent my skills, responsibilities, and desired future jobs on a resume.
Well, I do have an opinion on that as well.
Senior is a nontransferable honorific, as in: it does not translate between organizations. I have had people who were senior in their old organization demoted to junior (aka. they mostly quit) because they could not write a line of code without internet or IDE to save their life, and I have had people come in as junior even though their started programming when they were 12 and could programm circles around most seniors, buy HR decided they had “no experience” after collage (which, in my opinion, boils down to exploitation of cheap labor). I also met a guy who was an good developer but at his company it was a formal requirement to give a talk to advance to senior. Even though he had 15 years of experience at that company non the less, he could never advance because he was afraid of public speaking.
So seniority is at least as much politics as it is skill or responsibility. In my experience, it boils down to whether or not you feel you deserve it. If the answer is yes, then you should see that you get it and that you are treated (paid) accordingly.
I see! I definitely feel that Senior would be applicable for this given position. All of my hang ups were in thinking there was a more defined requirement to be a “Senior”. Between you and my discussions with others, I’ve learned to not worry about that and instead focus more on my knowledge-level and my direct contribution to the Org - both of which I would say are appropriate in this environment.
It sounds like you’ve got enough familiarity with the whole development lifecycle, as applied to a smaller single-dev-sized project, that you’d be great as an SDE 2 at a larger company, ready within a few years to step up to Senior. There are companies with hundreds of developers who only rarely hire straight out of college, where your level of experience is exactly what they want.
(There are also companies with hundreds of developers who do hire straight out of college, and I’m not trying to disillusion recent grads.)
This is good to know. Our org doesn’t have multiple engineers, so I don’t think that the multiple levels would really fit, but SDE (Software Development Engineer?) may be a good match. Probably not a senior since I only have experience on single-dev projects?
Although your current role wouldn’t seem very senior at a large organizational, “senior“ is a relative term and at this company it seems like you are the engineer with ownership responsibilities over the end-to-end software development of a production system. So it might still be reasonable to use a senior title if there are other benefits
Definitely. My thinking is that it would make it harder for HR to undervalue the position and, if we ever do get to hire additional developers, they will be looking to me / whoever is already in my position, in a senior / junior type fashion - at least for a solid chunk of time.
That’s right. I know I was thrown off by large projects earlier in my career. The more you learn the stronger you get at understanding and packaging/setting-aside larger and larger pieces of a project. Bigger projects stress this ability in new ways. I think I lost a job in 2016 because I couldn’t stretch my brain around something bigger, at a small business with maybe 14 devs.
This might be a bad way to communicate this, and I think I’m taking this in a weird direction, but: I’ll use the Mozilla project as an example of a large project, though I’ve never looked at its source.
Suppose you were in an interview, and due to the specifics you are expected to be fast and fluent with the same technologies used in the Mozilla project, though you’ve never looked at the source before. Given a machine with the source already checked out and open in an IDE, you have one hour to read through the source and familiarize yourself with it, so you can answer questions about how you would approach adding features or test coverage.
What I want to know is: how high does your heart rate go? Does it go up just a little, as expected for a high stakes situation? Or does it go up a lot, because you honestly have no idea how much another dev in your situation would be expected to accomplish, so you have no clue what “good enough” looks like?
This is a crappy example because no interviewer could ever actually use this metric. But I’d say if it goes up a lot, for the reason I gave, you might not be ready for senior. And by this metric, it might not ever be possible to grow to “senior” without working at a company with large multi-team projects. But I think that’s accurate.
(Edit: yes, sorry, Software Development Engineer. I think that’s a protected term in the US, in Texas and California at least, but anywhere else in the US you don’t need to pass an engineering board exam to use that title.)
Don’t let yourself be put of by peoples expectations. Most Senior Engineers have no idea that “engineer” is in their job description and which would not accomplish anything if you’d take away their Stackoverflow and ChatGPT.
Senior is a title that is generally measured either by an individuals ability to sit on a chair for a long enough time or by its ability to make friends with management. Skill or knowledge overall has little to do with it.
I can definitely see what you mean, and I appreciate the detailed post!
As for your scenario, I feel as though my heart rate would go up to a moderate amount, maybe less depending on the exact structure of the project.
The reason I say that is because I’ve done similar things in the past. My wife also has a job as a junior developer (working from home as part of a smaller multi-dev team supporting a massive project), but her team is set up in a way that she can only get a few minutes a week with her senior since he is always busy with his own tasks. She was never given documentation or even a walkthrough to explain how their project is structured or how their database is structured (they said in the interview that they would do this, but in reality the senior has to spend all of his time on other projects or in meetings). There are times that she gets stuck on a task that she has been assigned because she doesn’t know where in the source code she needs to look and she can’t get a hold of her senior. She’ll ask me for advice (without looking at the code, it’s essentially a 20-questions type scenario of hypotheticals) and, even though it is a completely different programming language and I haven’t actually seen the code, I can figure out what it is that she is needing to do and help guide her to where she needs to go in her project. When she finally gets a chance to talk to her senior about it a few days later, he confirms that the steps she ended up taking were correct for their set up.
For example, she once had to update the items in a drop down that she couldn’t find in the code in their project. She knew that the dropdown was being loaded on a specific page, but the items weren’t being populated in that same place. I assumed that this was likely using a stored procedure or a view on their database to pull the dropdown items. With that assumption, I was able to help her trace to where the data was being loaded in their data repository. That gave her the name of a stored procedure. She went and updated the stored procedure’s definition in their dev server and it corrected the dropdown. She later met with her senior and he confirmed that the dropdown (and many other features in the app like the dropdown) are pulling out of stored procedures so they don’t have to redeploy code to update things like that.
Similarly, one of the projects I had to work on at my org is actually taking an MVC web application and an API web application that are written by one of their multi-dev teams that are provided by our ERP software provider that we can customize to meet our specific needs. I did have some documentation to go off of, but I was able to get that loaded in and making customizations that fit within their architectural style within a couple of hours when I first started it.
I used to be in a relatively similar position years ago so I totally relate to what you’ve got to do on a daily basis.
These are the the titles that come to my mind (leaving ths seniority level up to you):
- Software engineer
- Software engineer in Integrations
- Software engineer in Enterprise Applications
- ERP Implementation consultant
These are some good considerations.
The “Senior” piece felt weird since, while I am responsible for 100% of the programming and coordination of tasks, I don’t really oversee or help train or guide any other developers. I think the main reason that Senior was considered to be put on the title was to ensure that HR doesn’t try and under-value the position again - as our org would run into some major crises if this position is ever left empty for longer than a week or two.
Senior and Principal don’t necessarily have to be managerial. They are often used for individual contributors as well and are just a way to denote you have more experience and expertise in your field.
I second this. I lead a team of engineers, and to us the main dividing line between senior and not senior is if you’re able to take on a project and lead it autonomously. I.e., you’ve gone past the stage where all you do is take on the next ticket in your task tracker; you have an awareness and understanding of the bigger picture, which allows you to create tickets on your own and select the most appropriate thing to work on next. The lead (me) is still there to help prioritize, fetch requirements, unblock things, etc, but it’s fairly light touch management.
(Edit: my job title is Principal Software Engineer)
I did not know that! I was really getting hung up on the “not having any non-seniors” point.
Senior engineer sounds about right.
How many years of experience do you have (both in total and in this org/position)? Also, can you estimate how much value you’ve brought to the org? Example: if the web app you wrote was not made, what would the loss be?
Total: ~7 years, ~3.5/4 of those were at the current org and the last 1.5 years of that I have been the sole programmer as the other programmers that we used to have retired and were never replaced.
Also, can you estimate how much value you’ve brought to the org? Example: if the web app you wrote was not made, what would the loss be?
This is hard for me to quantify. The web app, for example, was built out of necessity because we are required to provide our full budget to the state that we’re in on a rigid timeline. If the web app wasn’t there, somebody would have had to manually poll the different departments for their full list of budget categories and their costs and then they would have had to manually go in and enter in that data line-by-line which would have taken a significant amount of time. The only way to enter data through the existing user interface (the one we do still have) is through a text editor screen that lets you manually modify data line by line, but can go awry if lines accidentally get moved up or down or the data entered doesn’t match the internal format that the application expects.
That’s kind of why my supervisor is pushing this so hard. She believes that, ultimately, every major procedure that would cost our Org significant time and money to have held up due to a technical issue, such as payroll, budgeting, and state/federal reporting to name a few, rely on whoever is in my position to be available at a moment’s notice. Ideally, we’d have multiple people performing these duties, but she hasn’t been able to get that idea sold to higher ups.
Yeah, Senior Software Engineer is a good match then.
Works about right for the workload, responsibilities and the YOE.
The reason I asked about the impact/value is that it’s a good way to argue your case. If you can quantify ‘x’ hours of manual effort (and the estimate should be an average person doing the work, not the best case), then you can start arguing using these numbers to show that you bring value to the org.
While it sounds like your supervisor seems to be pretty solid, it’s possible you’ll eventually sit down with someone esle who’ll be deciding the final ‘value’ of your effort and would have a vested interest in paying as little as possible. For that conversation, whenever it may happen, you need to be fully prepared. That’s going to involve hard number. Effort saved, value created, costs saved etc. It’s difficult, but it’s a useful dataset to have.
I’ve worked in smaller orgs like this in the past, and it’s occasionally an uphill battle to get paid commiserate to the value you bring to the table. It’s a good reminder for management that you’re not easily replaceable and that they need to kep you interested enough that you don’t wander off.
I appreciate your advice! I’ll definitely work on getting the hard numbers to help my supervisor out. She’s been pushing for this for a while, so hopefully I can provide some materials to aid her.
I’ve had to do this before for a former job where I went from a Team Lead on a Helpdesk that started coding tools to help improve our agents metrics and the availability and accuracy of reporting to management and agents. Our helpdesk had no developers, but I was able to show how our team went from spending ~10,000 man hours a year on manually running reports to send to agents and management and only having the reports available weekly to having all of it automated and updated daily for everybody that needed them. So, I can adapt the methodology I used for that to the current org as well.
CTO
Ah, Chief Throwaway Oppenheimer. A worthy title
