I wholeheartedly agree that DevOps should not be a role. However, the current reality is that IT IS a role.
During a DORA community meeting (dora.community), the recurring question, “Is DevOps a role?” surfaced once again. My daughters are peacefully asleep so I’ve decided to delve into this topic.
Over the past seven years, I’ve dedicated five years to leading a “DevOps” team, and for the last year, I’ve served as the Head of DevOps and Platform Engineering.
Before embarking on my DevOps journey, I thought of myself as a Software Engineer, passionate about problem-solving, irrespective of the technology or stack involved.
I found joy in transitioning from frontend (backbone.js/Angular/ReactJS) to backend (Ruby on Rails, Django, NodeJs), tooling (Jenkins/Sentry.io/Rabbitmq), and infrastructure (from Xen machines on Dell servers in remote data centers to AWS infrastructure using Chef/Puppet/Ansible, etc.).
Yet, even if I called myself a Software Engineer, I was a Backend Software Engineer when working in the backend, Fronted Software Engineer when working in the frontend, and a mythological full-stack when working on both.
Somehow though my role’s definition became ambiguous when I started working on tooling and infrastructure. Suddenly, I was no longer a Software Engineer but a DevOps.
In 2016, when I began leading a team of DevOps Engineers, it became increasingly apparent that the traditional Frontend and Backend Engineer roles didn’t exist in this realm. Instead, the term ‘DevOps Engineer’ became a catch-all phrase.
At this juncture, you might be thinking, “BUT WAIT, WE SAID DEVOPS IS NOT A ROLE!!!”
Allow me to share my perspective on this. I wholeheartedly agree that DevOps should not be a role. However, the current reality is that IT IS a role.
LinkedIn currently lists more than 15K positions for DevOps Engineer
I don’t oppose the idea of DevOps being a role because DevOps IS A CULTURE, but primarily because we are doing ourselves a disservice by categorising it as a role.
If we consider Google’s definition of DevOps capabilities from a few months ago (though it seems they’ve removed some), we find:
-
Technical capabilities
-
Process capabilities
-
Measurement capabilities
-
Cultural capabilities
These further expand into:
Version control, Continuous integration, Deployment automation, Continuous testing, Continuous delivery, Architecture …,Code maintainability, Working in small batches, Visual management capabilities, Westrum organizational culture.
From the list above, it’s clear that the world of DevOps encompasses a wide range of specialisations.
The Roles
What if we took a leaf out of the Software Engineers’ book and define roles in DevOps?
Consider this: what if we took a leaf out of the Software Engineers’ book and defined roles for ourselves, such as:
Infrastructure Engineers: Specialists in setting up and maintaining infrastructure, whether on-premise or in the cloud.
Site Reliability Engineers (SRE): Professionals focused on ensuring system uptime, resilience, scalability, and performance.
Platform Engineers: Experts in abstracting infrastructure and providing a clear, easy path to production for application teams.
Security Engineers, Cloud Engineers, DevOps Practitioners, and so on…
Defining specific roles will aid in skill development and career progression. It allows us to concentrate on deepening our expertise, attending relevant training, and advancing in our chosen specialty. It’s much easier to tick off 5 boxes than 20+.
The hiring process will also benefit from this
Enabling companies to advertise for specific positions and conduct more focused interviews. Professionals can filter out the noise and find roles that better align with their skills.
In Conclusion
As with many aspects in tech, the “right” approach often depends on context. A generalist might suffice for smaller organisations or projects (aka “full-stack”). However, as systems grow in complexity and scale, specialisation becomes not just beneficial but necessary.
We should view DevOps not as a role, but as a philosophy – a way of working that emphasises collaboration and communication. Within this philosophy, there’s ample room for specialised roles that bring deep expertise to their specific domains.
So if you want other to stop using DevOps as a role our task is to work together to define these roles within DevOps. Sounds easy right?
Whom should I talk to to get started with this?