Redgate has a DevOps team. They do a good job. For the record, Redgate is not the company that inspired this blog post. The company that did shall remain nameless.

I don’t have a problem with “DevOps teams” or “DevOps engineers”… as long as they are evangelists – and not button pushers, build masters or release engineers with added buzzwords.

Actually – I don’t even mind that much, when Mr or Mrs DevOps does become synonymous with the role of TeamCity, Jenkins or Octopus Administrator – as long as they do a good job at talking to the users of their system and making it easier for them to get their code into production. There are worse problems – and at least these people are cooperating with the rest of the business.

But what really annoys me is when I go into an organisation and I see horrible bureaucratic processes and impossible deployment systems with pointless hoops that developers and DBAs alike are forced to dance through because some “DevOps” team owns the delivery process and enforces that the rest of the IT team works in a particular way to release code.

There is certainly a place for standardisation of practices. And there is certainly a place for requiring some level of adherence to code quality, testing or formatting standards. But when these processes are crippling the productivity of the IT organisation it is time to evaluate how you got into this mess. When teams go out of their way to work around the process in order to get stuff done it is a clue that the process is broken and that Dev and Ops are unable to work together effectively.

If you ever have a team that lives in one silo and is enforcing the way another team works from some ivory tower without there being a two-way dialogue, there is always going to be a problem. And that team should know that what they are doing is entirely opposite to what we mean when we use the word “DevOps”.

DevOps teams should not be there to enforce one way of working. They should be there to facilitate the other teams in the business to deliver good code in order to meet the business goals.

DevOps teams should not live on an island. They should be there to break down the walls between different silos and encourage teamwork and cooperation.

DevOps teams should do more than implement automation solutions. They should promote the ideas of Collaboration between different functions, Automation of all the things, Lean principles to guide processes, Monitoring pipelines/data to inform decisions and Sharing good practices across the business instead of dictating their opinions on others. (If those ideas are new to you look up ‘CALMS’).

If your role includes the term “DevOps”, you should be an evangelist, not a dictator.

Header image is shamelessly stolen from Matt Skelton’s great blog post: “What Team structure is Right for DevOps to Flourish?“. It is a far more measured, and generally a far better piece of writing than this rant.