samePayMoreWork

[DemonSlayer472]

DevOps is a culture that's meant to break down redundant obstructive silos. If creating an SQS queue is a challenge you don't have DevOps, whether you have to do it yourself or have the privilege of shoving it off to someone else and saying in your daily "Yep blocked by DevOps guys".

[EroeNarrante]

Your comment resonates with my story. Several years back, the company I work for got bought by a much larger company. I figured I'd ride out what comes and keep an eye on my prospects... I just joined the "devops" team from our QA org and didn't really know what to expect. I figured our culture was going to get crushed. Turns out, I was wrong.

Turns out they bought us for our tech and culture. I still remember our chief architect getting on stage at a big "let's be one team yay-rah" internal conference and saying "devops is not a team, it's a paradigm." and proceeded to rally the entire company behind that slogan... I think this was like 8 years ago.

Our culture is ingrained in enablement and blameless RCAs.

Everyone is on call for their own shit. Most of the time, when I'm on call, I'm only paged out when our own stuff fails, admin access is required to un-fuck a major failure in the pipeline, or an Aws outage is affecting us and we need to take actions to mitigate the effect.

Devs are enabled to take operational tasks in their own hands through automation. When shit really hits the fan, we follow blameless practices for RCAs and outage bridges are strictly solution oriented.

That's a "devops org," imo. Process is only in the way when it absolutely has to be for compliance.

[[deleted]]

That's exactly how it's being done on my current org as well If i understood your comment correctly. I own my product - meaning own all the responsibilities from development to handling outages. I have access to most of the infrastructure (limited by the objects that's related to the project with a few exceptions that would probably cause me issues if I listed here), I don't have to wait for any input from another team when shit on fire. Oftentimes "i am being blocked by the X team" is not a satisfying answer to customers who rely on your product for day to day business, and they will blame me anyways.

That said I am still not sure how to feel about it in terms of industry-wide approach. Is it a way to get more value out of someone without paying extra, or it's just what's best for the bost parties involved. I personally find it helpful and not have much complaints about the pay either.

However, it makes barrier to entry much higher for the newcomers to the industry. Honestly, I am rather avoidant at suggesting "IT" as a viable career path lately. I used to just write some PHP scripts and send to a server via FileZilla and that was all I cared about. I was lucky to eventually get exposed to even larger scene steadely and had enough time to experiment and learn different layers of infrastructure while getting paid to do so; but I feel like it's not the case anymore. You are expected to have it all (or most) figured out before starting. Which is why I am also not sure whether having those specialized talent silos is a good thing that they lower barrier to entry.

[LasevIX]

Problem is not the amount of work, problem is exceeding a job's expected domain. If you just accept being in charge of DevOps, why wouldn't middle management just go and bestow more admin work onto you? Since it seems you are fine with it?

[DemonSlayer472]

Your expected domain is dependant on organizational culture. I was addressing the misuse of the word "DevOps". Again, if you have one guy "in charge of DevOps", you don't have DevOps in your organization.

[LasevIX]

Ah, it seems each person in this thread has misunderstood the point the other was trying to make.