Can't Buy Me Lead Time
This week we take a look at the importance of lead time as a metric on a path to DevSecOps, platform engineering, and product-led culture.
For most folks, the term “lead time” might come up when they order something. For example, your ordered something physical and the thing’s manufacturer or supplier replies that they are experiencing longer “lead time” on a particular something — meaning you will wait longer until your consumer satisfaction is achieved.
Within software application development teams that embrace DevOps cultural attributes, it is increasingly common to hear about measurements. One measurement in particular borrows the terminology for the latency between the start and end of a process — and is referred to as “lead time”.
Now it’s time for reading 📖, watching 📺, and listening 🎧 suggestions:
📖 - Blog posts
First, 📖 A New Approach To Measuring Developer Productivity in which Abi Noda continues to highlight recent research worth checking out in depth.
Second, 📖 A Getting Started Guide to Establish an Internal Product Culture in which Ben Voss continues exploring internal developer platforms _as products_.
🎧 - Podcast episodes
First, 🎧 The Intersection of Supply Chains, 3D Printing, and Sustainability in which Tom Raftery interviews Len Pannett and brings to mind many analogous parallels to the software product world.
Second, 🎧 Unleashing Team Potential in which Kevin Gentry and Lou Cirillo talk through lead time (and cycle time within), deployment frequency, mean time to restore, and change failure rate referenced in a Dan Olsen talk with Marty Cagan (a meta critique of the third video below!)
📺 - Videos
Second, 📺 Devops - More than the tools and tech in which Martin Comstedt of OnBird makes the case that tools and technology alone are not the entire story of DevOps principles and measurements (and uses a flip board!).
To be clear, definitions for “lead time” might vary depending on perspective and who you ask within a software application oriented supply chain. For some the “lead time” is a measure of going from ideas to realities and for others there are far more granular definitions.
If “lead time” was related to was a physical item you ordered, getting it faster is one thing. However, getting it faster but missing parts or with a defect that puts you at risk is not acceptable — quality assurance and security matters.
An insufficiently cooked meal _could_ arrive faster. But, would you really want to eat it?
Being faster still requires care across quality and safety/security dimensions.
I like to say that “lead time” can be thought of as the measurement of _the time between when a developer contributes to the product experience until an end user of that product experiences **a desirable impact** from the developer’s contribution_.
Of course, as the modern hybrid cloud experience drifts towards greater SaaS and PaaS with further abstraction of IaaS, it is reasonable to expect “lead time” expectations to be increasingly top of mind for business leaders charged with digital transformation.
Or, as I was saying…
Global public cloud services revenue hit $545.8B in 2022, up 22.9% YoY; SaaS-Applications led with 45%+ of the revenue, then IaaS with 21.2%, and PaaS with 17%
By Michael Shirer / IDC. View the full context on Techmeme.
To be clear, getting a shorter “lead time” should not be due to lowering quality or completeness — and cannot be the result of bypassing security considerations.
So, I’d argue that DevOps pursuits should, holistically, be DevSecOps pursuits rooted in secure software development practices combined with quality engineering, automation first thinking, and — long term — seek to become platform engineering pursuits on a path to express a more product-led growth culture.
So, what will be the next big thing in “lead time” and related DevSecOps, platform engineering, and product-led culture measurements?
Until then… Place your bets!
As a reminder, after a +25 year walkabout, I’m an IBMer (again). For 2023, in “Work Plug”, I share a new link each week that is educational, accessible, and relevant to platform engineering from fellow IBMers in the wider IBM Community.
I am linking to my disclosure.