“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.