A comprehensive guide on how consequences and team structure impact DevOps success, the role of functional silos in fostering apathy, and the benefits of shared responsibility and distributed control in achieving higher-quality outcomes.
This document explores how consequences and team structure impact DevOps success, explains how functional silos can lead to apathy, and describes how shared responsibility and distributed control foster higher-quality outcomes in organizations.
Consequences play a crucial role in shaping behavior within organizations. When individuals or teams are abstracted from the outcomes of their actions, accountability diminishes, often resulting in lower quality and apathy. Jez Humble, author of “Continuous Delivery,” highlights that bad behavior arises when people are separated from the consequences of their actions, a common issue in organizations with functional silos.
Functional silos can create an environment where teams lose sight of the broader impact of their work. For example, introducing a separate QA team may lead developers to feel less responsible for quality, focusing instead on delivering features quickly. This shift in responsibility can overwhelm QA and ultimately reduce overall software quality. When teams are isolated, they may not experience the effects of their decisions, leading to disengagement and a lack of ownership.
To counteract the negative effects of silos, organizations can create cross-functional teams where members collaborate directly, rather than relying on ticket queues. If cross-functional teams are not possible, rotating developers through operations roles or involving operations engineers in development activities can build empathy and understanding. Assigning developers to on-call rotations or making them responsible for service level agreements ensures they experience the real-world impact of their work, encouraging higher standards and better code.
A successful DevOps organization aims for a shared consciousness with distributed, local control. This means everyone understands the overall goals and direction, but has the autonomy to determine how best to achieve them. Empowering teams in this way leads to greater engagement, innovation, and customer value. As Werner Vogels, CTO of Amazon, states: “You build it, you run it.” In effective DevOps cultures, there is no distinction between development and operations—everyone is responsible for delivering value to the customer.
Organizations need to have small, dedicated, cross-functional, self-organizing teams to successfully implement DevOps.
Conway’s Law implies that a company’s design results are a direct reflection of the company’s communication structure.
Instead of the traditional structure organized around technology, successful DevOps teams should be organized around business domains. Each team should have its own mission that aligns with a business domain.
DevOps is a mindset that the whole organization adopts.
DevOps solves problems caused by siloed teams.
DevOps is the practice of development and operations engineers working together during the entire software lifecycle, following lean and Agile principles that allow them to deliver high-quality results.
Actions without consequences can lead to apathy.
Allowing teams to feel the effect of their actions fosters empathy, resulting in higher-quality work.
The organizational objective of DevOps is to attain a shared mindset and empower everyone to deliver customer value.
Actions without consequences can lead to apathy and reduced quality. Allowing teams to feel the effects of their actions fosters empathy, accountability, and higher standards. The DevOps objective is to create a shared mindset and empower all members to deliver customer value through distributed control and responsibility.