Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
“DevOps is a culture, not a role”
2 points by JSDevOps on Nov 28, 2022 | hide | past | favorite | 3 comments
“DevOps is a culture, not a role”.

DevOps is the cultural and organisational merging of traditionally separate department responsibilities; Development and IT operations, to reduce the software lifecycle time and improve code quality. But does “DevOps” have a place in job roles or team names?

The “DevOps Engineer” nomenclature exists and is widely used, it serves as a good reminder to teams and individuals of our ultimate goal.

There can be negative implications when being this ambiguous with team naming. If we consider the top 3 common roles that are often covered within a “DevOps” team; Cloud Infrastructure, Site Reliability, and Development Experience.

Issues we may face:

Headcount Even a growing organization with a relatively simple stack will likely require multiple engineers assigned to each of the aforementioned areas if it wants to be able to progress quickly in each area simultaneously. A squad of three engineers may seem like a well-stocked team when in reality it is three severely under-resourced teams.

Responsibility Having a single team named “DevOps” can easily obscure the scope of responsibility across (at least) these top 3 areas. This complicates the wider organisation's ability to include the relevant engineers in project planning and often results in DevOps simply being a catch-all reactive team.

Context Switching Unlike software engineering, context switching is part and parcel of each of the top 3 areas. That being said, context switching between all areas at once will increase that overhead significantly.

Organizational perception Depending on how many of the above issues we are facing and how well we are mitigating them, the perception from the outside organization will not be great, even from inside the development department. It will especially compound the age-old issue of quiet competence in the Cloud Infrastructure and Site Reliability work.

So, how do we alleviate these issues?

Be organisationally clear If we have a “DevOps” team, have sub-teams named appropriately e.g. Cloud Infrastructure Team. Each of which would be populated with “DevOps Engineers”. Much like the Identity, Backend and Frontend development teams would all have “Software Engineers”.

Experienced Management Whether you have a manager for each area or one for “DevOps” as a whole, it is key that the outward-facing manager has a wealth of experience in SRE/Infrastructure and the ability to clearly articulate the value of all aspects of the team's work.

In conclusion, if a company insists upon the word DevOps being visible as part of R&D org, yes, “DevOps” can be used to define a section of the organization however, we must qualify each of the sub-teams with clear names that can be used to correctly scope responsibilities.

More preferable would be to leave the word DevOps as the description of the way of working and be precise with team names and job descriptions as it minimises the need for any confusion at all.



I remember the internal presentation that introduced the notion of DevOps to all the teams and the warm fuzzy feelings it gave us. The Venn diagrams and all. That was in 2016.

I also remember seeing "DevOps" quickly becoming just another role and silo and the everlasting disappointment of seeing yet another promising idea becoming the exact opposite of what it was supposed to be.

Happens way too often in "tech".


Typically, a "DevOps engineer" job position means that the infrastructure and architecture have become so terrible that a specialist is needed and/or existing engineers don't want anything to do with such mundane concerns. Which is, of course, the opposite of "DevOps" as the result of process improvement and collaboration.


Set of general principles and practices in an organisation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: