Labels matter. They warn us when something is dangerous; they help us make sense of things; they're a basis for decision-making, simplifying complex facts and large quantities of information.
The DevOps community knows that labels matter, employing a wide range of performance metrics to analyze, measure, and label the performance of a software development pipeline. Metric assessments — like the DevOps Research and Assessment (DORA), for instance — can be extremely useful in providing DevOps teams with the essential data required to have visibility and control over the development pipeline. Through key metrics — including deployment history, lead time for changes, change failure rate, time to restore service, customer tickets, and defect escape rate — DevOps performance can be evaluated and labeled, helping to create and enrich the feedback loops needed to improve code over time based on real-world performance. They show which teams are delivering at the highest levels as well as where improvements can be made.
But labels aren't always what they seem, and the reality is that evaluations based on DevOps metrics don't always capture the full picture of what goes on behind the scenes. Think of these metric-based evaluations as a restaurant critic who assesses a dining experience solely on the quality of the food and the speed it's brought to the table, overlooking other essential elements like the ambiance, service, and overall atmosphere. Just as traditional metrics focus on deployment frequency and lead time for changes, restaurant critics might concentrate solely on the taste and promptness of dishes. However, just as a memorable dining experience encompasses more than just the food, a successful DevOps culture involves factors beyond the quantitative metrics, including collaboration, communication, and alignment with broader organizational goals.
Here's what traditional DevOps metrics can miss and how leaders can recognize and support their DevOps teams in every aspect of their work.
Not All Teams Are Built the Same, and They Shouldn't Be Measured the Same Way
While traditional DevOps metrics offer valuable insights into deployment frequency and lead time, they can also fall short in painting a complete picture of a team's capacity constraints and can be blind to the reality of how IT teams work on the ground. Team capacity is influenced by factors such as team size, expertise distribution, and the intricacies of project dependencies. These critical elements are key to understanding the capabilities and constraints that shape a team's capacity for effective software development and delivery.
Modern IT environments are more complicated than ever, thanks to more and more organizations moving to the cloud and balancing a mixture of on-prem, cloud, and hybrid environments. The use of AIOps is poised to help, but at the moment, DevOps teams are often pulled in many directions and are juggling multiple projects concurrently. DevOps metrics don't always account for or reflect the size, scale, or scope of individual organizations and their DevOps teams. This means that small but mighty teams, who are very efficient given their scale, can often be evaluated poorly if only focusing on performance metrics. In accounting for team resources while considering DevOps performance, smaller teams can feel supported and organizations can help prevent burnout, which affects IT pros at alarming rates.
Aligning with Company Goals, Not with External Measurements
Another key component of the work of DevOps teams that traditional performance metrics don't capture is the alignment of their work with the overall objectives and vision of the organization. Metrics like change failure rate and time to restore services, while very important, may not provide a nuanced understanding of how well different teams are synchronized toward common business outcomes. For instance, many DevOps pros spend a significant amount of their time identifying and remediating minor issues across applications and services. While AIOps and advancements in observability solutions are poised to help IT teams with automating the detection and resolution of service and application problems, DevOps teams are still largely on the ground troubleshooting these situations. Though these resolutions may be achieved quickly and lead to high-performance evaluations, this is still time taken away from a team's ability to build and deploy innovative solutions that customers need and can hinder moving forward with strategic projects.
Organizations should complement quantitative metrics with qualitative assessments and feedback mechanisms to gauge alignment, fostering a holistic approach that considers both operational efficiency and strategic coherence within the DevOps landscape.
The Customer Is Always Right: Accounting for End-User Satisfaction
Alongside traditional DevOps performance metrics, organizations should also consider accounting for and evaluating customer satisfaction. Traditional metrics do not directly measure or reflect the satisfaction levels of end users or customers who interact with the deployed applications, though it is potentially one of the most important indicators of a successful product.
Customer satisfaction is multifaceted and complex, influenced by factors beyond the scope of traditional DevOps performance metrics. User experience, usability, and feature relevance are essential components of customer satisfaction that may not be adequately addressed by typical performance measurements alone. For instance, a high deployment frequency might signify rapid development cycles, but it does not inherently guarantee that the delivered features align with user expectations or contribute positively to the overall customer experience.
Companies striving for a holistic understanding of their DevOps impact can complement traditional metrics with customer-centric feedback mechanisms, user surveys, and qualitative assessments to ensure that the development processes align with and enhance customer satisfaction.
Supporting DevOps Teams in All They Do
In our modern IT environment, it's essential that organizations adopt a balanced and inclusive approach to evaluate performance. Leaders must acknowledge that different teams may have distinct responsibilities and goals that contribute significantly to the overall success of the organization but might not be reflected by evaluations based on traditional performance metrics. DevOps teams that might not score as high in traditional metrics could specialize in other tasks that are equally critical, such as maintaining system stability, addressing technical debt, or ensuring stringent security measures.
Thankfully, there are a number of ways organizations can begin to improve the lives of DevOps teams while also achieving high performance in the standards of traditional metrics. Integrating observability solutions can allow teams to scale their work and more easily identify and resolve issues as they arise, freeing up time for smaller teams. Observability also can help measure and provide insights into end-user experience, ensuring that the needs of customers, DevOps pros, and organizations are aligned.
By recognizing the human element of our DevOps work, along with supporting team members through professional development opportunities, organizations can work toward building a positive culture that values diverse skill sets and contributions within the broader DevOps landscape.
Jeff Stewart is Vice President, Product, at SolarWinds.
