Defining the problem well enough that the work of solving it becomes tractable.
Structured problem solving is the discipline of doing the boring parts in order: state precisely what the problem is and whose problem it is, break it into pieces small enough to investigate independently, work out which piece actually carries the weight, and only then start solving. Almost all of the value sits in the first two steps, and almost all of the time gets spent in the last one. A problem stated as "the deploys are slow" is not yet workable; a problem stated as "the test stage takes eleven of the fourteen minutes, and eight of those are one suite" is nearly solved. The method matters less than the habit of not skipping to the part that feels like progress.
Fixes the visible thing, every time, quickly and competently. The service is restarted, the record is corrected by hand, the alert is silenced, and the incident is closed within the hour to general appreciation. Does this on the fourteenth of every month, has done for two years, and has never had a quiet enough afternoon to ask why the fourteenth — the recurring fix having become routine enough that nobody now experiences it as a problem at all.
Responds to any concrete question by widening it until it becomes the whole system. Asked why one report is late, produces a review of the data platform, the team structure and the intake process, all genuinely relevant and none of it actionable this quarter. Ends with an accurate map of everything that is wrong, no first step, and a shared sense that the situation is too large to begin on, which is the one conclusion the exercise reliably produces.
Has a preferred tool and a demonstrated competence with it, and discovers, on investigation, that each new problem turns out to be one that tool addresses. The framing is done sincerely and early, before anyone notices it has happened, so the diagnosis and the remedy arrive together looking like a single insight. Everything is a caching issue, or a communication issue, or a hiring issue, depending entirely on who was asked.
Recognizes at week three that the approach isn't working and continues for eleven more, because stopping would waste what has already gone in. Each additional week makes the accumulated investment larger and the reversal correspondingly harder to propose, which is the mechanism operating exactly as designed. Eventually stops, having spent four times the sunk cost that was being protected in week three.
An incident recurs monthly and each occurrence is fixed within the hour. What would you do — keep fixing it, since the fix is fast and reliable, or spend one of those hours instead on why it recurs?
You're asked why a report is late and can see six contributing causes. What would you do — present all six, or find out which one accounts for most of the delay and lead with that?
Three weeks into an approach, you can tell it won't work. What would you do — push on, since so much is already invested, or stop now while the investment is only three weeks?