I do not know quite what it is, but Lapa who is the CMO of Eficode has a way of triggering me in such a way that I must respond. He is almost my private [/r/writingprompts](https://www.reddit.com/r/writingprompts). ![[Screenshot 2023-09-18 at 11.55.51.png]] Even though I was already immersed a particularly phrasing here stood out to me. > If you know how much a feature can extract or accelerate revenue.. > > – Lapa I think this is the golden goose. If we have this capability or knowing in advance how much any given task is worth, we can reason very effectively on both priority, order and when we should stop throwing more money after a thing. This would allow us to do things like Weighted Shortest Job First and in general make economic decisions. I recommend [The Principles of Product Development Flow](https://amzn.to/2NX3SEu) for an in-depth treatment of this and many other insights. If we could do this, we would be able to much more reason about what we should do, and how we should approach it. We could reason about as in this figure  But, unfortunately for most organizations the view is more like so:  Which is obviously a huge problem. It really enables the Highest Paid Persons Opinion (HiPPO) decision making strategy and moves us away from the Measuring of CALMS. Some organizations are even further from that. They have a hard time figuring out what the cost and revenue is of a value stream. We talk so much about being outcome oriented, that we forget that many teams do not have the context and environment to be outcome _aware_, on a level more interesting that the number of magical story points they churn out. I like the focus [Mik Kersten](https://twitter.com/mik_kersten) brings to this in [Project to Product](https://amzn.to/3khUpE5). The flow metrics, combined with the Flow Items really brings some reasoning on a relevant level that can help us talk about productivity. If we then add in this paper: > Evaluating well-designed and executed experiments that were designed to improve a key metric, only about one-third were successful at improving the key metric! > > [https://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf](https://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf) It starts looking really gloom. In my experience most teams are not even at the starting stages of scientific thinking and [hypothesis driven development](https://roamresearch.com/#/app/Modern-Software-Development/page/E38lgmr7o). And yet well-designed and executed experiments are more likely to not improve the business. What a bummer. ## So, DevOps Transformations We were talking about DevOps transformations. In the previous I have mostly argued for the difficulty in reasoning on the impact of a task or feature on business value. So with regards to DevOps Transformations I have a few main points. First off, when we try to build the _business case_ of a DevOps transformation we almost always end up end some automation driven cost-down analysis. And while this might be true and valid, it is only tangentially related to DevOps, and no one was ever inspired by a visionary cost-down target. In my opinion strategy should be about raising the top-line, and then we should have a continuous focus on improving the bottom-line, but that is not for the vision. Second, a DevOps transformation is a huge undertaking and trying to estimate the business case of that entire transformation would be folly. I believe that we can argue that the DevOps transformation does not set much in terms of how far we will go, but it will make it more likely that we are moving in the right direction. Third, DevOps is about iterating, and we should be able to make many smaller business cases along the way. On specific, context-dependent initiatives. And these improvements should be done in a hypothesis driven way. Not everything will increase productivity, speed, developer happiness or what ever is the focus area. If we are not prepared to do stuff we might have to undo afterwards, we are in dire waters. Fourth, I haven’t really dug into the horrible overload of the word _Transformation._ We are not defining some function _f: f(x) = y_ that will move transform one state to another. DevOps is about continuous improvement and iterations. And creating a culture where this can happen. That is not a transformation. And Fourth again, the word transformation does not distance the desired end-state hard enough from the current state of affairs. This is particularly true for agile transformations. There will be blood. Someone will lose their job, or feel bullied to quit because their work has been transformed in a way that is not comfortable for them. The word transformation glosses over some of the ugly truths of a disruptive process. I paraphrase Geoffrey Moore in [Zone to Win](https://amzn.to/3ko2Xcr) when I say “A transformation is so disruptive it takes the full attention of the CEO. There can be only one transformation at any point in time”. I think we underestimate the disruptiveness, and as such we underprioritize it in top management, and there we have already set it up to fail. Fifth and Final, if we have such a hard time reasoning the impact that our work has on the business, it will be that much more difficult to reason about the impact of improving the way we work. That was way too many words, but thank you [Lapa](https://twitter.com/lpalokan) for making me think.