A personal journey in Software Delivery Optimisation: Utilization (Part 1/3)
Preface: Being familiar with the state of DevOps reports will better help you understand the context of this blog; please check the latest information here.
“As the utilization approaches 100%, the waiting time / Lead time approaches infinity” — Kingman’s formula.
As simple as it sounds (given that it is mathematically proven), it appears to me as a counter-intuitive statement that applies to people before machines, software, and things getting produced. For me, I believe there is that utilization threshold when crossed, the less or nothing one can make. Of course, with the exception of superhumans, which fortunately I am not one of them.
In this series, I will be sharing some of the learnings I have acquired throughout the years working in technology as a software engineer and product manager. I am continually looking to better understand or maybe one day come with a new simple formula that accelerates the software delivery to better help myself & my team learning more about the customer needs, match business growth expectations, and leverage good software & technology practices.
Software delivery performance has been a growing domain for almost a decade now, big thanks to the State-of-DevOps-Reports, years of research and development that is publicly shared, gathered from thousands of technology experts of many sorts, who have been sharing their knowledge by answering surveys over the years (snowball sampling), and some continue to work on making sense with the data acquired. Having/voicing/repeating data is refreshing and easy — making sense of information is complicated yet prosperous.
Software delivery can be defined as simple as having the ability to push changes of all types; new features, configurations, bug fixes, and experiments into production safely, securely, and sustainably. Measuring delivery performance varies according to the method that suits the experts in-charge of the domain and business. However, I follow the school of “Accelerate,” in which I believe in the methods used to come to the measuring factors; deployment frequency(proxy measure to batch size), lead time(processing time + waiting time), mean time to restore(To err is human; to fix or rollback fast is divine), and change failure rate(how often do we push broken changes to production & to our customers).
I find measuring and lowering utilization are the cornerstones of an anti-fragile structure & organisational culture that will appear in higher product outcomes which will directly result (empirical studies) in happier humans/teams, expanding business, and more loyal customers (NPS, network effect, and you name it). A potential recipe for what I call a successful digital/technology product.
I happened to read and to think a lot about utilization; discovering the measures is a challenging task, but to begin with, I would categorize them momentarily into two buckets; humans and software. Why? Because collectively humans produce software.
Humans: How to measure if your team is overutilized?
There are many metrics that human resources can pull out of the systems at hand. However, I would go deeper and measure the following:
1- Cynicism: How often new good ideas/techniques are faced with cynical resistance or rejection just because it is hard to do by the majority of the team members? When the team has no time to invest in learning and changing the status quo, be assured that one of the underlying reasons is overutilization.
2- Technical Debt: How much time is invested in resolving technical debt issues? By either rethinking the entire model to reduce it or at least bring awareness to the amount of work that existed or continue to surface just because we have not figured things out before or yet.
3- Count the number of heroes you have in your company and team. With all due respect to a hero’s culture, it does not roll nicely in the long term (Truck/Bus factor), and also, heroes tend to dictate solutions for their own convenience. I will quote Kahlil’s Gibran iconic piece: “You have been told that, even like a chain, you are as weak as your weakest link. This is but half the truth. You are also as strong as your strongest link”. Helping your team grows and become stronger will result in a stronger culture and business. Easy to comprehend, difficult to execute but nonetheless it is the right investment.
4- How often is instant gratification pulling the team towards a decision that does not fit with what the product should be offering?
Having a calculated measurements of the above will help you and your team to better adjust to the actual reality and create transparency that is often appreciated than criticized.
Software: How to measure system(s) utilization?
Latency, throughput, CPU, and memory utilization. Easy, but not enough. To correctly measure utilization of the system/digital product, you need to measure your competition’s performance (or at least a parallel product) using a fair play model, then benchmark yourself against the numbers you acquired. While you can’t measure CPU and memory, you can still measure latency and throughput. Again be friendly and fair. Why is this important? Because you will always be happy with your numbers (Confirmation bias).
Throughout the years, I learned that a healthy team & dynamics fix broken processes that will continue to emerge as a result of simply: life. The purpose of any good product strategy is to prevent fragmentation and bad ideas (wastage) from making it into any release. In my next parts, I will be talking about platform-as-a-product and finally the culture.
Please note that this is my own studies and practical experience, which is prone to blind spots. What I have shared here is “a” way beyond/below the surface. I hope you find it helpful and inspiring in a way. Please Let me know what do you think? Thank you very much for taking the time to reach the end of this written piece.