I think there's a middle ground. I used to be intensely critical of "doing things just to do things." The more perspective I get, the more I realize that, in a situation where things are not going right by whatever criteria you use to determine that (outside scope here), you need to make changes.

The right way to make those changes, or at least one way and I don't know a better one, is to perturb the system and see how it responds. This is necessarily risky and uncomfortable, and choosing the right things to perturb and the magnitude of those peturbations is a very, very tricky skill.

But ultimately if you're dealing with an opaque system, which most companies are, and you want to make it a more transparent system that can change, that risk and discomfort are necessary side effects.

This is of course very situational, and the methodical method is by far preferred, but if you'll permit a metaphor: you get dropped into an unfamiliar cockpit, and the controls are labeled in some foreign language. The plane is crashing, or at least you don't know if it is. What do you do? You wiggle things and hope that, in doing so, you don't crash, and you take very careful note of what happens.