Explaining DevOps to executives
“How can I explain what DevOps is to the C-suite?” This is a headache raised by surprisingly many of the DevOps and SRE (Site Reliability Engineers) specialists we meet at conferences and when we build Centers of Excellence with our clients. In this article, we share our perspective and tips on how to explain it in a way most non-tech executives appreciate and understand.
The short answer is: Explain how DevOps delivers Value, Flow, and Quality (read on to learn more) rather than as competence or skillset; a DevOps team is not considerably more important than other business functions such as Talent Acquisition, Finance, or Sales.
Bigger than IT
The significance of DevOps is joining the two main jobs of a business: Development and Operations. Not exactly in every business, but all the ones that rely heavily on IT for their products and services. Done right, DevOps is the integrator between the development side that shapes the business, taking ideas to market, and the operational side running the business.
The trick is to highlight it not just as two IT functions but as the glue between the ‘Dev’ and ‘Ops’ sides of the business.
If you are familiar with the “Three Ways of DevOps” from Gene Kim’s book The Phoenix Project – systems thinking, amplifying feedback, and cultivating a culture of experimentation and learning – it will give you a good head start.
We will explore in more detail the concepts of “The Ways of DevOps”, but first, let’s go over the language and key messages we use at Emergn for meaningful work and communication.
Language matters
Of the 1.4 billion English speakers in the world, only one in four has English as their first language. Using plain and clear language is important for the message to be understood. The best way to make points memorable is by making them meaningful to the listener.
At Emergn, we have experimented over the years with and refined the key messages of our philosophy for change in the form of short principled statements around Value, Flow, and Quality. After a couple of iterations, we arrived at: Deliver value early and often, optimize the flow of work end to end, and discover quality with fast feedback.
Deliver value early and often
The most important feedback is the one that lets us know if our efforts pay off. And more value is always better, even if early and often is context dependent. The earlier we deliver, the more benefits we will have. The more often we deliver, the quicker we will know.
Bonus point for DORA metrics advocates. This is where we suggest the ‘Deployment Frequency’ metric should only cover releases reaching customers and end users. Value is only generated by business operations.
Optimize the flow of work end to end
This is both the easiest and hardest point to make. Systems thinking is easy to say but difficult to apply. Finding the right balance between throughput and end-to-end speed is key. This is more straightforward when the organization is structured around flows (e.g., value streams, business processes or customer journeys) than in very functional organizations.
DevOps is more important than engineers propagating code from dev-to-test to prod environment; It’s making sure the flow of work is connected and efficient end to end. From ideas to impact with customers and users.
When measuring lead times, measure them from the intake all the way until they are released in production. Removing unnecessary waiting time is equally valuable as working faster, and usually, a lot easier.
Discover quality with fast feedback
In Gene’s book, feedback features in the second and third ways: The second, amplifying feedback, means learning about the outcomes from real customers and turning them into insights for further development. The third, cultivating a culture of experimentation and learning, it’s about feedback from experimentation and process improvements.
In a complex environment, it is more efficient to learn from experience and adjust quickly than working off predictions and detailed plans and specifications. This is true throughout the whole process from ideation through to operations. Developers need fast feedback on code quality and integration, delivery managers need fast feedback on releases, and above all everyone needs feedback from customers and users.
The Three Ways
The “Three Ways of DevOps”, from Gene Kim’s book The Phoenix Project is an easy read built on a narrative that appeals to most technologists. The key points are outlined by Kim in The 3 ways of DevOps article.
With deep roots in the theory of constraints, complexity theory and lean, the ways represent three crucially important means to manage complexity and uncertainty: systems thinking, amplifying feedback and cultivating a culture of experimentation and learning.
Getting the message across to executives
The right message to send is the one that gets picked up by the receiver and subsequently gets understood. Ideally for the sender, it should also be remembered and followed.
To deliver the important messages on the DevOps role in systems thinking, amplifying feedback, and cultivating a culture of experimentation and learning to executive stakeholders, we recommend the following to make the points more meaningful to leaders outside the technology domain:
- Make amplifying feedback about feedback driving business value
- Streamline systems thinking to flow
- Focus experimentation and learning on quality improvements
The DevOps role
Given your audiences understand that DevOps brings the Development and Operations processes together, a natural follow-up question would be “What work do you do as a DevOps specialist?”
The answer should be, “Putting the technology and feedback processes in place so the work flows quickly from ideas through development to operations, so they generate business value.”
This is where the need for metrics and practices for continuous integration and delivery, QA automation, configuration and release management, monitoring and operations support comes in.
Same but different?
The principles of Value, Flow and Quality are built on similar underpinnings as the Three Ways of DevOps. We suggest you can be more successful expressing the thinking of Gene Kim, Don Reinertsen, David Snowden, and others using language that resonates with business leaders, namely that of Value, Flow and Quality.
If you have any feedback on this article, get in touch with our team. To learn more, you can start by reading our thoughts on Why ProductOps is the newest NotNeededOps or The 2 key metrics delivery managers should care about first.
Additional Insights
The DevOps shortcut to AI
6 ways to control and optimize your cloud costs
