Martyn Coupland

In this post, we take a broader look at building a business case for DevOps focusing on the principal that DevOps is not a job role but a cultural move.

This is day 8/100 in the 100 Days of DevOps series.

How does DevOps become successful? If only that was a simple question to answer! The truth is that fundamentally, to be successful, the whole company needs to be doing DevOps to be successful.

Senior leadership must support the initiative, but everyone with a stake in the final product, not just the development and operations departments, must participate.

I’ve read a Puppet white paper on how to build a high-performing IT team. And Section A contained a number of intriguing theories and practises that I’d like to share with you.

DevOps is pervasive across industries, company sizes, and technology environments. Nonetheless, IT-managers who are leading successful DevOps transformations within their organisations have a common refrain. DevOps is a process of continuous learning and improvement rather than a destination.

Build the business case

You, like many other IT leaders, are being asked to not only deliver more products and services than ever before, but to do so with greater speed and quality — all while maintaining reliability and security. DevOps appears to be extremely beneficial! But…you’re already encountering scepticism from your team before you’ve even begun.

How do you make a clear, convincing case for DevOps that reduces fear and converts skeptics into champions?

Starting with the question above is actually a great start. Building the business case is a crucial part of a successful DevOps transformation (especially in large organizations). In a famous TED Talk, Simon Sinek notes a common denominator of great leaders and catalysts for positive change:

“People don’t buy what those leaders are doing but why they’re doing it.” – Simon Sinek

The same is true when it comes to gaining organisational support for a DevOps transformation. Simply declaring, “We’re doing DevOps,” will not get people on board. Instead, you’ll need a compelling answer to the questions “Why?” and “How?” “And why now?” All of our customers want to move faster without jeopardising the reliability and stability of their systems — two goals that are diametrically opposed in traditional organisations. Developers are tasked with releasing new features as soon as possible. Meanwhile, operations personnel are evaluated based on system uptime and performance. As a result, these teams become adversaries rather than allies.

Up next

In day 9 of 100 Days of DevOps, I will be taking a look at Five Cultural Changes Needed in DevOps.