Most business problems show up a long way from where they start. The number that's wrong is a result, produced by rules, inputs and incentives set somewhere else, often long before you arrived. Fix the result directly and the system carries on producing the problem, so you end up fixing it again.
Systems thinking is the habit of following the problem back before you act. You ask what feeds the number, which rule decides how work, money or attention gets shared out, and who gains when things stay as they are. The answer is often a rule that made sense when someone wrote it and has been working against you ever since.
For a leader, the pull runs the other way. A symptom fix is quick and easy to report, and the board can see that you've acted. A change to an upstream rule is slower to show results and harder to explain, so it tends to lose the argument in the room.
The safer way to change a rule is to treat the change as a hypothesis and test it on one part of the system first. You see what it does to the part you changed and to the parts around it before the whole business depends on it.
The practical tell is a problem with a history. If it has already been fixed once and come back, ask what would have to be true for the business to be producing it on purpose; the answer usually names the rule doing the producing.
On the drive back from a client meeting, my boss put it bluntly: "If it costs us clients, it will cost us our jobs." Service across our 200 repair providers was poor, and adding support staff had only cut into profit. The cause sat in the rule that shared out the work, which booked each provider eight jobs a day per engineer as if they had no other customers. We tested a fix on our worst provider, giving him only the work he had room for. His service improved on every measure, and he did the same number of jobs for the same money.