⬅️ Shock the Chaos Monkey 🧭 Fuzz Jam June ➡️

Can't Buy Me Lead Time

by Jay Cuthrell

Music: The Beatles - Can’t Buy Me Love (1964)

https://open.spotify.com/track/38Vb1J5W5LOs0i7SAF76pa?si=8102102993634e77

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.

Getting Informed

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

🎧 - Podcast episodes

📺 - Videos

I’ll get you anything, my friend 🎶

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.

But what I got I’ll give to you 🎶

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…

http://www.techmeme.com/230706/p35#a230706p35

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!

Disclosure

I am linking to my disclosure.

🤓


View this page on GitHub.

⬅️ Shock the Chaos Monkey 🧭 Fuzz Jam June ➡️
Share and discuss on LinkedIn or HN