This by the same team who brought you the DORA metrics and the SPACE framework. I suspect it is really a vehicle to sell books and consulting, despite the article largely making sense.

Maybe it is atonement of some sort.

Thanks for pointing that out. Although I do think DORA metrics make some sense, it seems like an unnecessary framework considering what the folks in queueing theory have done over the years.

Anyone claiming we need to invent our own metrics needs to read Reinertsen.

I'm sure you have seen it already, but there has been some sound criticism of the DORA metrics: https://isthisit.nz/posts/2022/state-of-the-dora-devops-metr...

Though I disagree with Logan about the change failure rate (see https://two-wrongs.com/you-can-reliably-measure-change-failu...), I still think he is spot on in terms of MTTR.

Strongly seconding Reinertsen for anyone interested in this, though. I think this article of yours is particularly insightful and of high quality: https://lucasfcosta.com/2022/08/31/engineering-metrics.html

Well, yes, taking established findings and twisting them into a memorable or easily usable shape is what one does when trying to popularise concepts. (E.g. how the Shewhart/Deming cycle is related to the scientific method, or how the cost/speed/quality triangle restates "everything is a trade-off".)

That says very little substantive about their results, though, so I'm curious how you think that matters to the discussion of developer productivity!

> Although DevEx is complex and nuanced, teams and organizations can take steps toward improvement by focusing on these three key areas.

I feel like they are aware that not everything fits into the framework perfectly, but if your organization was trying to improve DevEx, this framework is a place to start.