The DevOps Role Nobody Really Agrees On (And Why That's Actually The Point)

I spent three years thinking I understood what a DevOps engineer was. Then I hired one, and realized I had no idea what to actually ask them to do.

We were at that painful startup inflection point—our deployment process was a manual checklist that lived in a Slack thread, our production monitoring was basically "refresh the server until something breaks," and we had exactly one person (me) who knew how to push code live without giving everyone a heart attack. We needed help. So we posted a job for a "DevOps Engineer," and got applications ranging from people who'd never touched a server to seasoned infrastructure architects who wanted $180k base. Everyone was technically qualified. Nobody could agree on what the role actually meant.

That's when I realized: DevOps isn't a single job description. It's a culture that looks completely different depending on your company's maturity, and the person doing it needs to be genuinely comfortable in that ambiguity.

The Real Problem DevOps Solved

Let me be blunt about what companies were doing before: developers would finish code, toss it to ops, and completely move on. Ops would test it, find problems, send it back. By then the developer was three sprints deep into new work. This wasn't malice—it was just how the organizational structure forced people to work.

What bothers me about this isn't the inefficiency, though that's real. It's that nobody owned the actual problem: getting working software to users consistently. Development owned "did we write it correctly" and operations owned "is the system running" but nobody owned the space between those two things. That gap is where all the friction lived.

DevOps fixed this by saying: stop thinking in phases. Start thinking in flow. One team, shared responsibility, continuous movement.

What a DevOps Engineer Actually Does (And It Changes)

Here's where I diverge from the standard explanation: DevOps engineer isn't a fixed role. It's a set of concerns that your organization needs someone to care about. What that looks like changes wildly.

In a small team like mine, a DevOps hire means someone who understands why we're manually deploying and builds us out of that. They write the pipeline. They set up monitoring. They document the infrastructure as code instead of tribal knowledge. They're maybe 60% infrastructure, 40% education because half their job is teaching developers not to be terrified of production.

In a bigger organization with dedicated infrastructure teams? That same person might be purely focused on scaling Kubernetes clusters, writing Terraform, and managing the network layer. Different work entirely.

The six responsibility clusters the original article mentions—planning, version control strategy, automation, deployments, infrastructure, monitoring—these are real, but I've never seen one person own all of them equally. You own some of them deeply and interface with others.

What I Actually Look For When Hiring DevOps

The honest answer: I'm looking for someone comfortable with incompleteness. The best DevOps people I've worked with don't need a perfect job description because they see the gaps and fill them.

Technically, they need to understand how code moves from a repository to users seeing it. That usually means Git workflows, CI/CD pipeline basics, containerization, and cloud infrastructure. But the tool doesn't matter nearly as much as the mindset—can they debug across the entire stack? Can they read an error in production and trace it backward?

The harder part is cultural. A DevOps hire needs to work well with developers (who often just want to deploy and move on) and with infrastructure teams (who want stability and documentation). They're translating between groups that sometimes want fundamentally opposite things.

Where I Think The Original Takes a Shortcut

The article does a solid job explaining the problem DevOps solved and the general responsibilities, but it treats the role more like a fixed position than it actually is. In reality, you're building the role as you go based on your company's needs.

Also, saying DevOps engineers "sit in the overlap" between development and operations is accurate but undersells how much of the job is communication and culture change. The technical skills are learnable. The ability to move between worlds without losing credibility is rare.

What's Next for Your Team

If you're hiring a DevOps person, don't write a job description that lists everything—you'll terrify candidates and set them up to fail. Instead, describe the actual pain points. "Our deployments are manual and slow," "We have zero production visibility," "Infrastructure knowledge lives in one person's head." Then find someone who gets excited about solving those specific problems.

Because that's what DevOps really is: not a job title, but the willingness to own the journey from code to production, and to make it smoother every single sprint.

Source: This post was inspired by "What Are DevOps Engineers, Really? Roles, Skills, and How to Become One" by Dev.to. Read the original article