What’s in a Name?
Everybody has some job title. Your job title gives people an idea of what you do. It also helps them decide who to reach out to in a time of need. You know, if your house is on fire you’re not calling a plumber, you’re calling a firefighter. That seems fairly straight forward. But what about in the world of IT? In IT there are a million and 1 names for each role. Even worse, there are more variations of each. I’ve worked in a place where it the titles changed with each re org. So you could have worked a path that looked something like;
Jr. Developer.
Developer II
Sr. Developer
Developer III
Developer I(because somebody decided the 3–1 made more sense than 1–3)
But even with those titles you can see that this person is a developer. You know to go to them with coding related questions. But what about the operations side of the world? How are titles hurting or helping their life?
Well to start you’ve got systems engineers, site reliability engineers, systems administrators, systems architects. I could go on for days with the titles, and probably write another post on what makes somebody an engineer vs. an administrator…probably should. But today we’re going to focus on the one job title that gets tossed around a lot now. A job title that shouldn’t exist, but businesses still use it. And why this title hurts companies more than helps. That title is of course “DevOps Engineer”
You’ve all heard of DevOps by now, well most of you. If you’ve not, please tell me how you haven’t. But if you’ve not heard of it, here is a quick definition.
DevOps is a methodology of doing work that relies on constant communication between developers and operations to make work smoother and more efficient.
This idea basically stemmed from the old way of doing product development. Which was Developer wrote code. Developer gave code to Operations. Operations forced code to work in a production environment. This process of course lead to lots of rework, buggy releases, and the feeling that Devs and Ops would never get along. Much like cats and dogs. Then somebody got the idea, that maybe these two teams should be working together. Not just steps in a process, but working together to make the process work.
Well somewhere along the line, somebody who skimmed over an article about DevOps thought they had the best idea ever. Hire a DevOps Engineer. This was some magical unicorn of an employee who was going to solve all their problems. Because “We’ve got a DevOps guy on the team”. The problem is that this won’t work at all. There is no such thing as a DevOps guy. DevOps is an idea that an entire team must work together and achieve. This would be like saying we have an agile guy, or a Waterfall guy. If I told you I hired an Waterfall engineer you’d laugh at me. Saying you hired a DevOps engineer should be no different. I made this joke once at a conference and somebody stood up to tell me they were a waterfall engineer. I felt bad for that guy. I wonder what came of him sometimes.
But why is this a bad thing? It’s just a title right? What harm can a title cause? Well let’s look at the name: DevOps. What does DevOps mean to you? OK, you’ve got an idea in your head? Good. Now ask a colleague…I’ll wait. Weird? Their answer was different. I bet if you keep asking around, you’ll find that everybody has a different idea of what DevOps is supposed to be and not be. That is because nobody defined what DevOps was supposed to mean as a role. Because that was never its intent.
Sadly because everybody has a different idea for what DevOps means, if you have a DevOps guy or a DevOps team, then they end up being the dumping ground for all work that doesn’t have a great fit. You end up seeing people in this role having to debug code because they have Dev in their name. Or they are configuring network rules because they have ops in their name. Or they are dumped a half baked project with no server requirements, and two weeks to get an app on the internet, because that is what DevOps does!
This is a terrible thing that can happen to your company. Because it will lead to morale dropping for your DevOps team. And then your timelines are missed. Then you get in trouble because that app isn’t making its deadline. All because somebody, who doesn’t know better, decided to name a team a buzzword without understanding what that even meant. So if you’re looking for a job, and they are offering you the title of DevOps engineer, ask a lot of questions about what that role entails.
- Is there an on call rotation?
- Are there already people in this role?
- Will this team handle deployments?
- What level of proficiency will I need in writing code?
- What is your ticketing system?
- Name one person from your Information Security?
That last one is just to see if they are properly communicating with all teams that should be involved. But really, the most important question to ask during this hypothetical interview; What does DevOps mean to you? If you don’t like that answer, then that should be your answer on whether or not to go forward with a DevOps Engineer Position.
So how do we get rid of this title? Well I think that horse has already left the barn for that issue. All we can do is start educating those who will listen that we’re not magical, we’re just engineers who work within a more efficient process and would be happy to teach you more.
