The term DevOps is commonly thought of as a portmanteau of two nouns, developers and operators. It should be thought of as two verbs, developing and operating.
Developers and Operators (bad)
If Dev and Ops are people, that leaves a lot of people out
You’ve probably seen this image showing how different roles in an IT organization view each other. The image is often used to demonstrate why developers and operators don’t get along. It’s entertaining, and also fairly accurate. It also shows one reason why thinking of Dev and Ops as nouns is a problem.
There are a whole lot of roles missing, not to mention the fact that very few people have a job title of “operator” anyway.
It leads people to think we need even more words
I think this is a big reason why we see things like DevSecOps and DevQAOps and so forth come up. If someone is recommending a change that only involves developers and operators, it’s natural to want to know how all of the other vital functions are going to get done.
Including those roles is important, and it’s also what was intended from the start.
Developing and Operating (good)
Developing software is a team activity. That team should have a wide variety of skills.
Verbs are more inclusive
All too often people with job titles such as QA are left out of key conversation and decisions. Telling them you’re transitioning to a culture which focuses on developers and operators understandably results in them feeling excluded.
Tell them you’re transitioning to a culture where cross functional teams will be developing and operating the software from here on out.
I’ll take security as an example, even though I’m far from a security expert…
Security isn’t something you do after the application is done, it’s something that needs to be baked into what you’re doing from the start. It affects every part of your application. Decisions you make about which libraries or components you’ll use, integrations with other systems, the deployment platform, who has access to what in the data, how you’re going to manage the data, and on and on and on.
Metrics that aren’t evil
People focused on specific roles are given metrics which are locally optimized. How many bugs you found, lines of code, story points completed etc. These metrics aren’t aligned to business goals, they are just things we can count. Local optimization is almost always bad.
When you have a team developing and operating a system you can use business goals as your metrics. Did that change we made to the e-commerce site result in more sales? Yes, awesome, let’s build on that. No? Also awesome, the whole team knows we should focus on something else.
This helps avoid creating yet another role
When we think of DevOps as combination of roles, it’s possibly a natural next step to create a new role which represents that bridge. Also, the “DevOps engineer” job title is born.
I’m not going to turn this into a “DevOps isn’t a role” rant, but it’s not.
Work together and make great software
Let’s focus on developing and operating great software. Let’s include the right people at the right points and stop worrying about their job title.
