When you have a separate DevOps team, you are not doing devops
I wrote this initially in December 2017 for a paid freelance blogging contract, and both my message has softened since then, and the blog editors revoked the link to the original post so I cannot link to it now. I post it here *as written*, and hope you take it as a viewpoint in a moment of time, with some strands of helpfulness woven therein.
On 14 November 2017, I tweeted the following:
https://twitter.com/TheresaNeate/status/930262953172942849
I was interested to see that it received several Retweets and Likes. So it seems many agree. This prompted me to write this article.
The theme of my message is similar to an earlier article I wrote for DevOps Agenda: Lean testers bring DevOps and QA together. The point of that message is that we are not achieving DevOps if we are still siloing teams or disciplines (like QA or Security).
In this particular tweet I am referring to the — what I consider most unfortunate — behaviour by mostly large enterprises, to rebrand their separate Operations team into a “DevOps team”. By giving them DevOps automation tools and rebranding their titles from sysadmin or ops to “DevOps engineer”, one is disregarding the very point of DevOps.
The very point of DevOps is the collaboration between developers and operations personnel, ideally by co-location, but always by breaking down silos. In this world, dev and ops are now on the same team. Let me repeat that: it’s the same team.
On this team, developers learn enough operations skills to take responsible ownership for the deployability and maintainability of their software, and should ideally be on the subsequent support roster; and operations personnel learn enough coding to code & automate deployments and environmental infrastructure, and may at times even be able to correct some of the post-deployment application bugs.
I am certain most managers want to do the very best for their teams and most certainly for their companies. But let me warn you: your teams are likely to be foremost keen on new shiny tools; firstly because we are all engineers and engineers love tools and find them mostly easy(ier); and secondly because we are not great at solving culture problems, how we work together, how we deal with work. As engineers we (and the tools vendors!) are quite likely you convince you that all you need is to buy us shiny tools so that we can “achieve DevOps”.
What some of us did not know, is that culture is paramount and primary, to tools. This culture includes breaking down the silos and working barriers so any chosen tools can then be optimised to achieve our desired results.
What we have done wrong too often, is ask “How do we do DevOps?” as opposed to asking “WHY are we doing DevOps?”.
If one knows the WHY, one will understand that just like the term “DevOps Engineer” is an oxymoron, so too is the term “DevOps Team”.
DevOps is an idea, not a brand and not a state. It is an optimised, lean way of working.
Let’s drop the branding and get on more with the understanding.
Additional reading:
If you are keen to know more about the understanding, the DevOps Cafe podcast and the Phoenix Project help a lot, with the DevOps Handbook balancing the why with the how.
My follow-up post is here: https://medium.com/@theresaneate/cargo-cult-devops-44bae3e56880
