I’m an 8 year data center network engineer who recently broke 100k for the first time. When I got asked my salary requirements I actually only asked for 90k as my highest previous salary was 80k with lots of travel, then I found out they gave me 100k because it was the minimum they could pay someone in my position. I’ve read before about people making crazy salary increases (150%-300%) and am wondering if I played it incorrectly and how I could play it in the future. I plan to stay with my company for the next few years and upskilling heavily and am eyeing a promotion in my first year as I’ve already delivered big projects by contributing very early. I’ve progressed from call center/help desk/engineer etc (no degree, just certs) so my progression has been pretty linear, are people who are seeing massive jumps in pay just overselling their competency and failing forward? Or are there other fields in IT like programming/etc that are more likely to have higher progression scales?
That’s great, can you elaborate what you mean by ops>devops? Do you support infrastructure or applications? I know devops is kind of a catch-all term now for automation, did you work on understanding cloud deployments from the POV of the servers/application or from infra?
I only ask because some of what I do is considered “devops” in the sense that I’m working on network automation, but a lot of times when I hear people discuss devops they’re talking about supporting applications
Yeah, happy to elaborate!
When I first started (hourly) I was doing basically field tech work at an msp. That means I was just a monkey following a document and would call for backup if I experienced any issues. I started getting some basic tasks to come up with newer processes, script some existing ones, and generally manage existing clients. I mostly got familiar with OS stuff, took a few Microsoft certs, that sort of stuff.
Second and third job I was doing more engineering of my own. I’d get higher level tasks like design an implementation of a next Gen firewall here, design next developer image, implement monitoring system, revamp backups, etc. Third job involved some public site management but I wasn’t yet too responsible for app deployments themselves though was often involved as escalation in app support.
Fourth job was more of the same but focused on automation this time. Our group was called ‘automation team’ and we revamped processes at a larger regional bank while adding automation. Before I left there we transitioned to DevOps team, but was more of a DevOps processes and platforms team. We wrote a lot of ci and automation but the goal was to have existing app support teams to own it. That model largely worked and we helped train the ops folks to be DevOps folks.
I moved to a cloud consulting company bc I wanted cloud experience and to get closer to app deployments. If you work on line of business applications then you’re more likely to demand higher pay while doing more interesting and important work. Managers usually need to improve the product so they’re less likely to be wanting to stick to the status quo.
The last two are similar, both justify architecture in the name. The previous though had a lot of bad practices, status quo managers, and was generally miserable. I’m currently quite a generalist because we’re at a small business. That said, main responsibilities include writing and supporting cicd pipeline, all infrastructure changes and automation, 3rd party mail system config, etc.
If you have any more questions lmk.
That’s great. That’s basically the route I’m looking to take, though my background is mostly with networking, so I have some catching up to do in sysadmin skills. Thanks for your insight! I’ll give you a follow (idk if that exists in the fediverse lol) and maybe follow up with you later. It’s great you’re willing to be a resource for the aspiring engineers. That’s the kind of spirit I try to embody.
No problem - I’ve had a couple unofficial mentors myself. In the tech world it’s also impossible to not be riding the shoulders of the giants before us.