You are not a DevOps Engineer

This is post is a little rant, about the IT industry and how we grab onto the coat tails of terms and play buzzword bingo with job boards. The latest term that has me mildly annoyed is the term DevOps Engineer!

There is no such thing as a DevOps engineer. DevOps is a cultural change in attitude so shared ownership and collaboration are the common working practices in building and managing a service.

The culture change is especially important for established organisations.

DevOps is not a team or a personnel thing. It's not something you can just inject into an organisation and overnight your organisation moves from broken to fixed!

There is no such thing as a DevOps swat team, driving around in a black and red van and if you have a problem, if no one else can help , and if you can find them, maybe you can hire the DevOps team.

Transforming an organisation and implementing DevOps practices takes a lot more than parachuting is some guy who has skills in Puppet, Chef, ansible , docker or any other verb that became a tool.

Your organisation won't be saved by a terminal wonder kid in a hoody churning awesome BASH scripts during his lunch break.

Changing your department names form Software Development and IT operations and moving them to a co-located zone with a pool & Ping Pong tables, open plan kitchens and bean bags then calling them DevOps is not really going to make your customers any happier.

Your customers really don't care about the fact, your staff now look more like Canadian Loggers than they do log consuming coding units!

The truth is DevOps is about a lot more than just changing your build server, source control repositories and configuration management tools.  

These tools may be a feature of DevOps but have nothing to do with the benefits.  They solve particular development issues, but in reality, your organization may not be directly suffering from those issues, and the cause of your issues are manifested elsewhere.

It is the old adage that data counts. After all you can't manage, what you can't measure and your first step on the DevOps trail is about collecting data, and analyzing your current working practices. This is the easiest part, which also happens to be the part a lot of organisations implement first and the result is that most of the DevOps strategy is about implementing Logging, Dashboards, Metric gathering and a number of new databases and SaaS applications are implemented.

The problem here lies in, that nobody really knows what data they need to measure or even how to use the new acquired data to effectively and efficiently guide the business to the Nirvana promised.

Useless Job Titles

I've had issues in the past with the rising popularity of bazaar job titles and descriptions. An example of which is Agile Developer , to me this paints a picture of some guy coding while seated in a lotus pose, snacking on Fava Beans and Wheatgrass smoothies!

I don't think it necessarily described a developer who knows a little about TDD and Stand Up meetings.  

Another term is Rockstar Developer, why would an organisation want to employ somebody who throws TV's out of hotel rooms and die of a drug overdose in his mid 20's! Although, it is entirely possible that these company's are actually searching for developers with skills in Rockstar Programming Language,  a dynamically typed computer programming language, designed for creating programs that are also song lyrics.

In some respects, Devops Engineer, might just be one of this Bullshit Jobs, but even I would agree there is actually a real need for the movement or ideal for Devops within software development teams but definitely not within all software development teams!

This partly down to the fact that there is no formal career track for becoming a DevOps engineer, mostly because like I say it's because it is not really a thing!

Apparently, they are either developers who get interested in deployment and network operations, or sysadmins who have a passion for scripting and coding, and move into the development side where they can improve the planning of test and deployment. Either way, these are people who have pushed beyond their defined areas of competence and who have a more holistic view of their technical environments.

Devops Unicorns

Job descriptions on Job Boards for the mythical DevOps engineer,  primarily detail the skillsets of build and automation engineers, and nothing what so ever about transforming organisations to adopt frictionless working practices.  

In fact the majority of the job posts I read seemed to require nothing more than Linux, Security and Build with some exposure to working in Agile teams.

Job adverts for DevOps engineers are nothing more than a sign that the industry has yet again adopted some cool buzzword and appended it to other keywords and now we have a whole new name for something!  In an attempt to describe something that's cool and hot. Unfortunately, in reality it doesn’t exist.  

It just serves to paint the industry in a bad light with the rest of the business disciplines, because nobody can understand that Devops is a cultural change required by the whole organisation!

What worries me most is that the DevOps engineers are required to work in the DevOps team! ( I don’t even know what a DevOps team is! )

If an organisation has a DevOps team, comprised of DevOps engineers then what has happened to the multi discipline aspect of what DevOps is supposed to encompass?

If an organisation has actually implemented such a concept as a DevOps team, effectively all they would’ve done, is effectively renamed the IT Operations department to some more cooler and down with kids term! However, I fear that the organisation is still pretty much engaged in a game of over-the-fence-tossing, albeit with another cooler named fence!

It is human nature to attempt to compartmentalise things and organisations are built on the notion that we should box people into units or functions of work or disciplines.

Organisations are carved up into functional units of work which are then managed by functional units of management.

It is due to the compartmentalisation of organisations that we believe work can easily be carved up into discrete packages and passed through production line process, whereby discrete units of work are passed between each functional unit.

It may not be a perfect process, but in some respects, tends to work  (pun not intended)

It is commonly believed that by following a process that we don't need to communicate. It is that concept that brings about the problems. The major problem that DevOps ideology attempts to address is the breakdown of communication in organisations.

This all seemingly falls in place, until the organisation seeks to engage in project work.   Project work in organisations is tough and one of the biggest challenges is that of finding and assigning adequate resources.

Often projects maybe innovative in nature, and may revolve around the implementation of new services or products. Often requiring out of the box thinking usually by people that are required to think within boxes!

Organisations will often, try to use existing resources from various departments, and mix them into a project team.  Project team members will be told that they are to rid themselves of their normal day to day business activities and their core focus over a period of time will be nothing but the project work!

The downside to this is that usually these team members maybe subject matter experts in particular business areas and  maybe the defacto points of contact, for all problems related in the particular business area.   This will of course be unofficially documented in the canteen or watercooler doctrine.

Developers tend to fall into this category, usually because they may have been ones that developed the initial application or supported it in some guise.

Database Administrators too, due to their role, as the name suggests is to Administrate the various production databases in use in the organisation.

IT operations guys maybe the defacto points of contact for networking related issues, due in part that they on a daily basis troubleshoot issues.

In fact instead of me droning on it's probably a better choice to read The Phoenix Project : A Novel about IT, Devops and helping your business win

Although, a fictional tale, it describes situations I have all too often witnessed in organisations during my career as a freelance software developer.

So the long and the short of it is, sorting out the continuous delivery aspect of your project, is a very small component of what DevOps addresses.  There is no one specific role required. DevOps is a collective sense of purpose of your project team.

Culture Change

DevOps is a belief, shared ideology and a cultural change which is at the core of an organisation. Just because some individual knows something about Puppet and Chef and can write Bash scripts to make coffee, does not necessarily make the DevOps Experts. They are IT automation professionals who may form part of the collective sense of purpose that the organisation aspires too.

The ideal DevOps implementation will include the integrations and collaboration of a number different resources. There is no magic tool, formula or wand waving wizard can fix it.

DevOps is about ensuring all friction points are eliminated, communication is clear, concise and open. This can only be done by ensuring you have a smooth flow data and clear interaction points.

The 4 Key Components of DevOps

• Cross-functional team
• widely shared metrics
• Automation
• Regular releases

The layman and technology wizard would look at these components then in all likelihood deduce that this is a technology problem that can be solved, because they Include the words Metrics, Automation and Releases. This is where the confusion really starts

The reality is that if you changed the wording slightly it clears the pictures.

• Cross-Functionial == Diverse
• Metrics == Accountability
• Automation == Efficient Communication
• Releases == Dissemination

Accountability is not just for individuals Accountability is for the organisation as a whole. Every member of the organisation, regardless of position or title plays a role in the success of a project.

Conclusion

Stop calling yourself or even refer to individuals as DevOps engineers. There is no such thing.  If you need some sort of title or need some kind of title to identify your role call yourself Millenial Falcon Engineer , it sounds cooler and most people will be really impressed, while at the same time have no real idea of what you actually do!