Don’t be fooled by single metrics of failure

Context is key

Chances are you’ve heard the term single point of failure (SPOF) before and have experienced the real-world ramifications when a single part of a system goes down and stops the entire system from working properly – or at all. You may have even heard the term ‘single person of failure’ thrown around in the modern workplace (think “person gets hit by a bus scenario” but a little less morbid). 

Technology systems are generally designed and built with redundancy in mind in order to avoid consequences that range from catastrophic, like the tragedy that stemmed from a lack of redundancies built into the Boeing 737 MAX ’s design (among other aspects that were problematic), to less catastrophic but noticeable disruptions, such as an ISP outage that impacts your home internet network temporarily. It’s a commonly accepted practice to build in redundancies in order to avoid SPOFs because it reduces risk.

These examples highlight both the small and large impacts of SPOF. We can apply the same concepts around avoiding SPOFs above to inform how we build and use effective engineering metrics to measure aspects throughout the development workflow, such as developer productivity. Conceptually, it provides a great starting point when deciding what to do vs. what not to do. 

Metrics in isolation don’t tell the whole story

When engineering organizations consider how to measure developer productivity or efficiency, the answer should never be “you can’t” and it should never rely on a single metric to provide valuable developer insights. There’s a lot to unpack surrounding the viability of measuring developer productivity, reinforce the importance of avoiding single metrics of failure, and share what “good” looks like in case your organization or teams have room to improve.

Looking at the 3 metrics below in isolation tells a much different story than if we look at them together and explore how they interconnect. 

Reduce defects

Enhances system interoperability and compatibility, leading to less time spent diagnosing and fixing defects in production. This, in turn, frees up valuable developer time.

Increase velocity

Indicates faster time to market and more frequent deployments, contributing to a competitive advantage. Better cycle times and rapid value delivery result in improved overall productivity.

Changing focus

Improves developer experience by minimizing disruptions to planned work and fostering efficient decision-making. This ensures that the team can prioritize and deliver value-add projects effectively.

Looking at how these are interconnected is important to see the difference through the lens of the business. Reducing defects can decrease the mean time to resolve issues and free up more valuable developer time. When combined with a change in focus to work on value-add projects with minimal disruptions, that freed up time positively impacts developer experience and can increase overall velocity. This means that value is getting into the hands of customers sooner, features are higher quality, and developers are working more efficiently with a higher level of satisfaction. 

Together, all of these metrics look at developer productivity more holistically, indicating that productivity is improving but with the necessary context that aligns to the business.

So what?

The journey towards effectively measuring engineering in a way that aligns with the business involves a shift from single metrics of failure to a holistic and interconnected approach. This simulates the same type of built-in redundancy for engineering metrics by design that I mentioned at the beginning of this blog, following best practices for any system prone to single points of failure. 

By defining clear goals, choosing a balanced set of metrics, considering developer experience, and evaluating interconnected metrics with the business in mind, teams can shape a successful strategy that aligns with strategic objectives and delivers meaningful value. In my humble opinion, that’s not very controversial at all.

Remember, it's not about measuring for the sake of measurement; it's about understanding how productivity translates to business value and fostering an environment where developers and the business can thrive together.

For more details on effective metrics and how to best use them, see our Simple Metrics to Measure Engineering Efficiency whitepaper or check out our Two-headed VSM Monster: Culture & Metrics webinar.

Interested in seeing Allstacks for yourself? Book a demo.