What you need to know about DevOps

If you’ve used the term “DevOps” as a job title, you may have been making a big mistake. It sounds innocuous: After all, isn’t DevOps something that you do? If you’re a marketer, hiring manager or non-engineer at your company, it might seem like it.

But nothing could be further from the truth. It’s actually a philosophy and set of practices that guides how your engineering and IT teams work. And using the term improperly doesn’t always sit well with tech teams, even if they have “DevOps Engineer” on their LinkedIn profile.

Using the term improperly can cause many problems. It may create additional silos in your organization, or may negatively impact how teams collaborate and get things done—limiting the effectiveness and accountability of DevOps work.

To counteract misinterpretations of what DevOps is and what it means, it helps to know why it matters and where the idea came from.

Why DevOps Isn’t a Job Title

DevOps is a way of working that emphasizes collaboration, open communication, and the seamless sharing of ideas and code. For many organizations that are moving to a DevOps model, it represents a culture shift, and the messaging around it is important.

Good DevOps work requires testing, iterating and even breaking things. That needs to happen quickly, without friction and, importantly, without blame. Defining someone as a DevOps head or team could imply that only those individuals are responsible for DevOps, and should it fail, those failures are individual failures rather than systemic.

As Chip Locke writes, software developers and operations engineers may be different types of people, and trying to combine them into a single role may not be effective. When dev and ops are forced into a single role or team instead of encouraged to collaborate across their individual teams, competing values and (sometimes) suboptimal results are the outcome. Additionally, implementing DevOps as a third team that sits between the development and operations teams is a whole recipe for disaster. Trying to fix it by combining those silos only makes things worse.

So, What Is DevOps Then?

There’s no standard definition of DevOps. According to The Agile Admin, DevOps is a “methodology of collaboration.” Put another way by the site, it’s “agile systems administration.” That means DevOps is about software developers and ops engineers working together with shared values, principles, methods, practices and tools to build, maintain and improve systems—across the whole services lifecycle.

That definition doesn’t fit on a business card. But defining it properly is important to your organization. Because DevOps is not about software developers taking over the job of ops, or ops taking over the job of devs. And it’s not just about shared tools (though that is part of it). It’s about implementing change across entire systems and cultures to improve how customers receive products and services, breaking down barriers, and fostering collaboration and communication between two teams that are sometimes at odds with each other.

Where Did DevOps Come From?

How did DevOps become the preferred option for many software companies? Data shows that DevOps helps businesses deliver better software products and adapt more quickly to fast-moving market realities by supporting more rapid code deployments.

The Agile Admin roots DevOps’ rise in the Agile Systems Admin and Enterprise Systems Management movements. Both arose from a need to improve business processes by taking advantage of faster, smaller and open-source “large vendor” enterprise frameworks. At the same time, Agile Systems Admin was becoming common in Europe as companies translated lean and agile manufacturing lessons to IT departments across the continent.

But even with these advances, companies still had serious silos and were dangerously inflexible.

Better tools—combined with the failure of big or heavy implementations—created what The Agile Admin calls “the perfect storm.” We had the means to do things better. DevOps was born.

The term was first coined by Patrick Debois and Andrew “Clay” Shafer in 2009. The philosophy took off when Debois hosted the first DevOps Days event in Ghent, Belgium. The rest, as they say, is history.

And when you understand that history, it’s easier to understand why engineers bristle at the idea of DevOps as a job title or company role. By referring to and thinking about DevOps properly, you won’t just make tech talent at your company happier. You’ll also help internalize DevOps principles within your organization.