alt Hacker NewsI had a role, we got a new CTO. This man could not stop wiggling things. Almost from day one. Not just small things but larger things too (let's migrate to a new issue tracker/wiki thing (back when Redmine was popular)). Flipping staff to new focus (eg: moved a help-desk staff to top NetAdmin, replacing Cisco Certified guy, which caused some havoc during an audit). What a mess, just had to put his fingerprint on everything!
Another time we got bought, merged into a new company, their CTO was our new CTO. In one of the initial meetings said "things won't change much" and, naturally, we didn't believe. She moved slow on all the things, methodical. Spent some time with each component team. It was months before we started making changes to better mesh with the new company. Very little chaos. Still admire that management style.
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.