DevOps: Lost in Translation

What is this “DevOps” thing that everyone from computer engineers to business leaders and recruiters are so enamored with? Is it a job title? A set of technical skills? A cultural shift? Or something else completely?

Like the childhood game of telephone, the phrase “DevOps” appears to be one thing on the surface, yet many people interpret it very differently.

Please do not empty

Let’s try to de-construct the phrase “DevOps” a bit:

DevOps is a Grassroots Movement

DevOps was started by Developers and System Administrators as a grassroots movement to re-engineer the fundamental ways that these two groups interface. This is important to understand. DevOps was not created in some think-tank outside the beltway. It was born from a very real frustration that many practitioners in the technology industry were feeling.

Between 2007 and 2009 multiple engineers in the industry started to identify and express dissatisfaction with the existing hurdles that existed in their daily workflows. The “agile” software movement was starting to significantly improve software development, but these gains did not extend across the entire business. Many development and operations teams were estranged and dysfunctional with competing objectives.

DevOps is a Business Process

It is a way of thinking about delivering solutions. It is not simply a set of tools, or a technical skill, or a job title.

Most companies are in the business of delivering solutions to their customers’ problems. Technology has managed to insert itself into every facet of business, long before most businesses were properly prepared to successfully leverage it.  As the agile software movement matured, it became apparent that despite some additional agility, there were still significant blockades to achieving a faster deployment cycle. To truly realize the advantages of writing code faster and more reliably, one had to also be able to deliver it to the customer with similar results.

DevOps is about Goal Alignment

By providing consistent messaging and goals across a business, and using standardized metrics to measure team performance, business leaders can align all teams with the company’s core goals.

Developers and operational engineers have historically had significant conflicts and have typically seen each other as “the problem”. This pattern is common because most businesses measure these teams by very different metrics. Many development teams are measured by how many features they can push into each release, while operations is measured by how much uptime the production systems have. This dichotomy in purpose can create great tension and dysfunction.

When a business communicates goals (i.e. we need to on-board 250 new customers this quarter with no customer losses) to the whole business, everyone can focus on doing their part to accomplish the same thing instead of working at cross-purposes. In this example, rather than telling developers to generate new features, and operations to keep the site stable, the business would expect every internal team to contribute to improving customer experiences, while driving hard toward the specific short and mid-term goals of company.

DevOps is about Flow

In many organizations you often hear about the ‘sales funnel,’  a visualization of prospect/customer engagement. The funnel indicates where companies are in the overall process from potential prospect to fully engaged customer. Similarly, DevOps encourages building a feedback loop (or bi-directional pipeline) that actively supports the business goals intended to help the business grow while meeting its customer’s needs.

A significant goal of DevOps is to create and support processes within the business that encourage the flow of deliverables and communication in both directions. When diverse teams iterate over a single process and constantly communicate and refine that process, they can remove many of the artificial barriers that have historically hampered businesses, and instead focus on the truly challenging problems in their space.

DevOps is about more than Dev and Ops

The DevOps movement started because of a very real communication problem throughout the technology design and delivery cycle. However, in reality the DevOps movement is more than a technology movement, it is a fully-fledged business movement and can positively impact many parts of the business with four simple guidelines:

  1. Take the time to understand the teams you interface with – who they are and what they do.
  2. Be able to articulate what you need from them – establish your requirements
  3. Listen to what they need from you – identify and understand their requirements
  4. Discuss cross-team priorities and align them with the business goals.

If your company is able to incorporate an overall business strategy around a DevOps process, it will greatly enhance the company’s ability to grow quickly and react to the market faster, while leaving your competition struggling to keep up. Teams will be able to focus on a single goal, build and iterate faster, become much more resilient and companies goals will no longer get ‘lost in translation.’


To learn more about DevOps visit our DevOps section and stay tuned for more informational posts from our internal thought leaders.

Sean is a Lead Site Reliability Engineer at New Relic. He is a long-time system administrator and operations engineer who has lived in places ranging from Alaska to Pakistan. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!