I might be applying my own mysticism about the original authors of the posts that this article speaks; but I think people are missing the point. Yes. 100%. The

I might be applying my own mysticism about the original authors of the posts that this article speaks; but I think people are missing the point. Yes. 100%. The map is not the territory here. The models presented in these examples are not perfect representations of the teams that people have built at all companies. It is easy and fun to poke holes in them as we're prone to do. But for whatever it's worth, software delivery absolutely is a system. The level of understanding about how that system operates is all over the place. Some managers have absolutely zero idea about how their software goes from "issue open" to "its running in production" and they need to. Engineers need to as well. If it's informally occurring or informal knowledge, it should be made explicit. The part where we all get our back up is when a manager goes "improve this metric" without understanding system dynamics. The example about constraints stands out to me. If you're going to optimize a hot path in your software, you don't throw your hands up and go "All models are wrong!" You can actually instrument the way it works and see which method or areas require attention and thought. If we take these as analogies and apply them to how we eliminate variability then life is generally better for everyone. I do tend to agree however, that these things are not leadership. But leadership requires situational awareness. Situational awareness is only acquired over time by "intuition" (which is often wrong) or by explicitly writing it down. Intuition is very difficult to explain to other executives, managers, and yes even software engineers. People like tangible things that reduce the resolution of the objects they represent and that's not going to change any time soon.