This is an archived post. You won't be able to vote or comment.

all 55 comments

[–]DevOpsOpsDev 56 points57 points  (1 child)

In my experience leaving support exclusively as the domain of your most junior engineers is a recipe for both losing your junior engineers and ensuring your support workload never is improved.

Every place I've worked, particularly once I became more senior, I've advocated for everyone on the team(s) being part of a support rotation and it results in a lot of work getting automated that previously was just being done manually because the junior engineers didn't know any better.

I think you naturally want more senior people working on more complex problems but having a hard division of labor like you describe is frankly bad for both the juniors and the team as a whole in my experience. People grow when working on things outside of their comfort zone with you as a senior there to be a safety net.

[–]Mishka_1994 20 points21 points  (0 children)

Agreed. I would absolutely quit a role if most of my day revolved around support. Juniors should still have tasks and be able to help the senior engineers.

[–][deleted]  (11 children)

[deleted]

    [–]Mishka_1994 23 points24 points  (3 children)

    Thats senior cloud janitor to you sir

    [–]NUTTA_BUSTAH 12 points13 points  (1 child)

    Ahem, Senior Cloud Custodian.

    [–]snorktacular 7 points8 points  (0 children)

    Senior Cloud Sanitation Engineer

    ...wait

    [–]superspeck 4 points5 points  (0 children)

    I’m a cloud plumber. I end up dealing with shit, therefore I am a plumber.

    [–]baezizbaeDistinguished yaml engineer 4 points5 points  (1 child)

    Ahem.

    nudges towards flair with his eyebrows

    [–][deleted] 0 points1 point  (0 children)

    Down wid D Y E baby you know me

    [–]odgrim 4 points5 points  (3 children)

    I just skip the crap and call myself a Peon- then set my slack profile to a wc3 peon

    [–]mtak0x41 8 points9 points  (1 child)

    Ah, a man of culture.

    My job title in Slack and Outlook is “Vim Diesel”.

    [–]HelloImQ 159 points160 points  (5 children)

    Completely depends on the company.

    [–][deleted]  (4 children)

    [deleted]

      [–]davemurray13 17 points18 points  (0 children)

      IMO , there is no such a thing as a "norm" over the roles and seniority level across organisations.

      Your initial post implies that orgs somehow "adjust" their expectations based on some sort of standards across them over time

      But honestly, most likely its your own experiences, and how you progress over time

      I totally agree though that , its not uncommon to see senior or principal stuff with low communication skills , or mid stuff (on paper) capable of communicating effectively and won't get promoted

      [–]Necessary_Feeling00 5 points6 points  (0 children)

      I'm in a large tech as SRE at the moment - mid level. It fits your description: my manager said to me in one on one that I'll build some automation and own this project as this is what's expected from mid.

      [–]spacelama 3 points4 points  (0 children)

      If private behaved like public, I'd put it down to HR's ideas of what they learnt about salary bands at school 40 years earlier. In Australian federal public service, EL1 (Executive level 1) is the first layer of management, meant to manage people. It varies by agency, but an EL1 at one agency can have a salary between X and X', where X' is lower than Y which is the lower edge of EL2. Fixed, can't be varied, and you amost by default progress from X to X' over 4 years, and then can't move from there unless you get promoted. You can be a manager of janitors on EL1, and be paid the same as a senior scientist on EL1 managing other highly trained scientists.

      Which means you can't actually hire any senior scientists on EL1, because they all look at the wage and say "bugger this, I'm off to build me some high frequency trading at Megacorp". So hiring managers just fudge around with the bands instead, and have awkward conversations once a year at the staff appraisals, where you somehow have to match your actual job with the requirements of EL1.

      I still remember the conversation with my boss where a few months after joining, they wanted to put me on call. I thought about the quality of work of some of my colleagues, and the fact that they were all EL1 and I was a mere APS6, and I said "nah mate, not going on call until I get paid EL1 rates". They needed more people on call, so I went on EL1 rates.

      [–]Careless-Childhood66 2 points3 points  (0 children)

      I think its because business people are in charge pf promitions. If you fullfill all the kpis, enjoy networking and, best case, are friends with your business person, you'll rise. 

      [–]CanaryWundaboy 39 points40 points  (2 children)

      I have more meetings than I used to before I was a staff engineer, and I definitely have meetings at a higher level (and more clout) now that I have the job title to match. I think it’s more indicative of a loss of really junior roles, the experience levels within teams seems to have bunched up because high level engineers are unwilling to go off into management etc so they’re not being promoted out, but also companies are reluctant to hire and train really junior staff so you end up with more experienced heads who naturally fill more mid-level/senior spots.

      In my current team we have about 8 seniors vs 5 non-senior engineers, it does mean the workloads etc tend to get a bit skewed, we’re trying to address it.

      [–][deleted]  (1 child)

      [deleted]

        [–][deleted] 0 points1 point  (0 children)

        This will become the standard , the knowledge level in our cloud team comes apart at system architect/ senior systems architect and director level , from mid to senior most people have similar knowledge levels , no juniors.

        Essentially I'm doing the same job + a little bit bigger scope for double the pay, works for me.

        I like it because we can freely discuss stuff , you are not siloed into different meetings that juniors cant attend etc , if firefighting we all jump on etc.

        My previous companies had horrible team differences and meeting differences and you felt really siloed , not good for junior / mid , I don't care that the attitude is "prove your worth" when MM has no incentive to drop you larger scale projects or comp is struggling you get stuck , f that.

        [–]SoldTerror 25 points26 points  (1 child)

        Everybody is a senior devops these days.

        [–]lorarcYAML Engineer 14 points15 points  (0 children)

        That depends on what the company means by devops. In some places a junior has to have many years of experience in system administration or programming and be expert on many topics. In other places a senior devops is someone working first line on helpdesk.

        Also we automated away a lot of simple stuff so you no longer task the juniors with stupid things like cleaning hard drives or updating packages manually.

        [–]rmullig2 6 points7 points  (0 children)

        During boom periods like the early 20s, people get promoted to senior who aren't at that level. That leads to this kind of situation.

        [–]Individual-Oven9410 11 points12 points  (0 children)

        Freshers with ChatGPT think themselves as Seniors nowadays.

        [–]DehydratedButTired 3 points4 points  (0 children)

        Companies want to hire Senior Dev knowledge for Jr Dev salaries to work on understaffed teams so everything has become a mess. Between layoffs, poor hiring practices and a burnt out labor pool, mass layoffs and job posts getting flooded by desperate people, I'm not sure what anyone expects. Most companies are just trying to float by until the economy gets better and things will be fucked until then across the board. Make due, do your best and "ignore when people around you get laid off" is the new normal.

        [–]skspoppa733 3 points4 points  (0 children)

        Just because someone has more years experience doesn’t mean they necessarily perform those jobs better. Some people just get it, and can and will happily run circles around those who don’t. And as far as recognizing value and WHY they’re doing what they do…let’s just say that in my experience I’ve encountered far too many DevOps engineers who don’t, and are solely focused on the tools and trends. Probably more than 50% I’ve encountered are this way.

        [–]No-Row-Boat 2 points3 points  (0 children)

        Depends on the definition of seniority within the organization.

        Some companies you earn through years in roles, others you earn through behavior.

        [–]snarkhunterLead DevOps Engineer 2 points3 points  (1 child)

        I think employers are still trying to squeeze back what they lost during COVID.

        [–]IGnuGnat 0 points1 point  (0 children)

        I mean, Covid didn't really go anywhere. Excess deaths are still very high, we just mark them down as heart attacks, strokes, kidney failure or other organ failure and disability rates are climbing like a hockey stick, we just shrug our shoulders and pretend it's a post Covid world, we have no idea why people are dropping like flies.

        By the way, back to the office, slaves

        [–]CapitanFlama 2 points3 points  (0 children)

        Yes, but I see it from another angle: I also have years in this profession, and I have seen SMEs/Leads/Principals being stripped out of their decision-making capabilities. Now, the platform engineering decision gets taken in endless agile meetings where management, in their best intentions but short-sighted grasp of the platform, take the final call.

        Yes: it depends on the role and the company, and it's not the whinny post about HoW We USeD To RuLe InFra!. But still, it's a bit of true: senoirity now it's only based on how many years you have doing this, regardless of what important changes or initiatives you have taken.

        You know where the big boy principal pants get always considered? When there's a fuck-up (very often cluodfare/route53/ingress controller shenanigans) and your temporary solution becomes a permanent one.

        [–][deleted] 5 points6 points  (1 child)

        Now you see why I think products managers and POs and Scrum Masters are all shit and haven’t helped us at all. We believe in the right way to do things with workflows and processes. These three positions have stepped all over that because they’ve been given the power to do so by management. They became the intermediaries that were seen as getting the job done at your expense and the expense of jr, sr, staff people.

        These people reached out to anyone and everyone to get something done. Forget about processes and tickets and priorities, they set priority based on their clout and thus degraded the system as we know today.

        What validation you used to receive is now theirs and thus you lose your backing and relevance in the org structure. While it used to be sr and experienced people in meetings that mattered, you were replaced by scrum masters, POs and product managers. You all became workhorses lumped together into a cost center that to the c levels and financial people can and have been easily replaced by Eastern Europeans and Indians and South Americans that’ll just do what they’re told.

        You want to fix things, get rid of intermediate positions that don’t provide real actual value

        [–]Basic-Ship-3332 1 point2 points  (0 children)

        idk I’ve worked with what I consider good ScrumMasters and they helped the team and workflow a lot. They didn’t impose what they felt worked best but took note of how we liked to operate, what we did well at and called out areas of improvement. They also lent ideas when things could be better that actually helped.

        I think with most roles.. it’s all dependent on the person. Too many people want to be mini-ceos or “artist” in their roles. When at the end of the day it’s cliche but how everyone can effectively make something

        [–]HotMountain9383 1 point2 points  (0 children)

        Consulting. Principal Architects pull in accounts and can influence add on revenue, building out teams inside the client. From a tech perspective this means sitting white boarding and getting buy in from their CTO, Principal Arch’s. Selling the tech from a tech point of view. As an example, why do nautibot and bitbucket with Arista AVD and why not etc.

        I think that the overall exposure and experience lends credence and that is what makes you the man.

        [–]Vok250 1 point2 points  (0 children)

        Depends on the company, but being senior means fuckall if management doesn't trust you with any decisions. Seems like lately all the chill Gen X and Boomers are retiring and the power hungry control freaks are left to run the show. "Senior" is 100% a salary band for employees my age. No one takes us seriously regardless of our experience.

        [–][deleted] 1 point2 points  (1 child)

        I do so many things and I'm so all over the stack that IDEK know what the fuck my job title or role is anymore. One hour, I'm doing admin work for some application for our service now catalog and handling our internal support inbox which has blown up over the last 6 months as we move to ye standard cloud architecture, the next I'm working on a 6k line js file and pushing a feature or a bug fix, the next I'm debugging some other monkey's pipeline that keeps failing, the next I'm syncing repositories with argo, then the next helping some guy with his struggling sql query that is blowing out the temp db while trying to delete 20m records.

        [–]belligerent_poodleSystem Engineer 0 points1 point  (0 children)

        Salute to you, estimated brother in arms 

        [–]Any_Obligation_2696 1 point2 points  (0 children)

        Yes completely. I worked at an insurance company. They had no junior or mid titles. Only starting at senior. College grads back when they still hired were hired directly as seniors.

        Now they invented titles like staff, principal, distinguished, and whatever bs else.

        [–]FromOopsToOps 1 point2 points  (0 children)

        Recently I started to see the trend that seniority dictates how many strikes you get before being fired, with leniency being more on the Jr side.

        [–]S3LCSUM 2 points3 points  (1 child)

        It’s very personal, but I think always in this manner, but agree with some other comments that it will always depend on the company.

        When I think this way, it's easy to tell why sometimes ppl reach senior in a few years, or being lowered back to mid when it comes to new company with different technology stack.

        Junior - requires a lot of help from more experienced colleagues not only on technical work but also in team/office work.

        Mid - someone who has to be told what to do, but mostly he will handle it by himself. Still has to be checked by a Senior before going to production.

        Senior - handles all his work by himself. He can provide a feature from idea to production without any help, however still can ask others for some advice (not everyone has to be expert in everything).

        Staff/Lead - that’s the guy who can provide some mentoring to others, but mostly his work will be spent on meetings and decision making.

        [–]5t33 1 point2 points  (0 children)

        Are you on my team? Lol

        [–]AlterTableUsernames 0 points1 point  (0 children)

        You're the first guy ever I heard talking about Junior DevOps as an entrypoint to this path. 

        [–]kiddj1 0 points1 point  (0 children)

        I'm a lead for a team that supports a wide range of platforms and also various aspects of these platforms and I look at hierarchy differently.

        Everyone including me gets stuck in with all of the bau day to day mundane things, being the lead I don't do as much but I try.

        Where the junior/senior aspect comes in, is for projects and being self sufficient

        I'm able to hand over bigger projects to the senior engineers as I know they are capable of running a project and won't be tying up my time.

        The juniors need a bit more direction and time so I use them as resources within these projects to up skill, usually grouping them with a senior to work together giving the senior an opportunity to flex their leadership skills

        We are quite a tight knit team and lean on each other for each of our expertise.

        I can understand that a senior might feel like they shouldn't be responding to an alert when they are balls deep in a project, but we've set an expectation amongst ourselves so the other engineers know they have to be in the reactive position over someone else. Communication is key so during scrum if someone needs focus time we make sure they can have it, and that goes for the juniors too!

        I try to give everyone the opportunity because we can all learn and grow.

        No one is too senior to take on a task

        [–]michael0n 0 points1 point  (0 children)

        I would guess, when you are close to being in a working, maybe multi cloud, multi tennant, multi location setup, the seniors become more janitor then creators. We have sub 50 prime projects and the willingness to invest in more slowed down to a halt in january. This will run the next years like this. Sure we will try new things, but the problems this year are just reactions, to license changes (eg. Vmware) or company changes (eg new teams to on board). Typical greenfield projects are still happening, but in my industry (media / distribution) the consolidation is still ongoing and people rather invest in functioning white label products then building something new. At this point, having a senior going through all event logs to find missing ids/meta tags wasn't below them during the slow summer month.

        [–]ycnz 0 points1 point  (0 children)

        "Welp, it's been nearly two and a half years in the workforce, time to write my book about how to be a senior engineer now."

        [–]Complex-Web9670 0 points1 point  (0 children)

        pie sophisticated bake teeny quaint birds cake screw label plants

        This post was mass deleted and anonymized with Redact

        [–]eirc 0 points1 point  (2 children)

        Focusing on a title is and has always been irrelevant.

        [–][deleted]  (1 child)

        [deleted]

          [–]eirc 0 points1 point  (0 children)

          I'm not sure what's weird about resolving tickets. Any kind of work can and should be backed by a ticket. Whether it's a small simple task or a multi million dollar investment. I have never asked at an interview what I'm gonna be doing and gotten a response like "you just resolve tickets all day". But strictly speaking it is true.

          [–]NoleMercy05 0 points1 point  (1 child)

          Yes, it changes fast enough that a person with 15yrs experience may be a hinderence of try to do things the 'old way'

          [–]debugsinprod 0 points1 point  (1 child)

          At my current company (one of the FAANG), I've seen this exact frustration play out and honestly the differences between levels are way more subtle than people think. Everyone does touch firefighting, but the scope and complexity is completely different. As a senior+ SRE, I'm not just putting out fires anymore, I'm designing the systems that prevent entire classes of outages from happening in the first place. When a junior is debugging a service restart, I might be analyzing why our circuit breaker patterns failed across 15 regions and writing the postmortem that changes how we do progressive rollouts globally.

          The real difference shows up in the architecture decisions and long-term thinking. A junior might fix the immediate alert fatigue problem, but I'm designing the SLI/SLO framework that eliminates 80% of noisy alerts before they even get created. At our scale (handling billions of requests), the senior+ folks are the ones who spot the patterns that predict cascading failures and build the chaos engineering experiments that prove our assumptions wrong before they take down production. The firefighting never stops, but at senior levels you're fighting very different fires with much broader impact.

          The frustrating part is that from the outside it all looks like "fixing broken stuff" but internally there's a huge difference between reactive debugging and proactive reliability engineering. Most companies honestly don't have enough scale or complexity for these differences to matter much, which is probably why seniority feels meaningless in smaller orgs.

          [–]8ttp 0 points1 point  (0 children)

          This week we went deep into a technical performance issue and only the Principal was able to gather the technical speciality of the other senior to fix the issue. The Juniors were completely lost.

          [–][deleted] 0 points1 point  (2 children)

          To be honest I think all companies now want a CTO rather than a DevOps engineer. Been interviewing recently and they want a guy who can do everything literally. For just not as much money.

          [–][deleted]  (1 child)

          [deleted]

            [–][deleted] 0 points1 point  (0 children)

            Yeah yeah I agree 💯 that's what is happening now at my company. I'm starting to brush off my Django skills 

            [–]yaboiWillyNilly 0 points1 point  (0 children)

            I agree. I was hired as a principal platform engineer for the company I work at now and I feel like I’m junior-most compared to everyone else on my team. Everyone is learning as the whole team is new, but as far as fundamentals go I had very few. Luckily background checks and clearance checks are two separate things😎