Article

Work & Organizations

The Importance of Problem-Framing

The Importance of Problem-Framing

“A problem well-stated is a problem half-solved.” – Charles Kettering

A magnifying glass, envelope, thread, and connection markers sit outside a transparent barrier separating them from rows of profile and job-listing cards, illustrating how digital platforms create visibility without genuine access or reciprocity.

You will often be confronted with a symptom of a problem, or a series of symptoms, rather than the problem itself. You get an angry customer call, your manager calls you in for an urgent meeting, your spouse blows up, your friend blows you off, your finances feel out of whack. These are all most likely symptoms of an underlying issue, and most people will put a great deal of energy in resolving the symptom(s) at hand. This seems fine in the short-term until the same or a similar issue happens again or a series of seemingly unrelated problems stick their head up – yet are actually connected to the same underlying problem as your initial issue. This “putting out of fires” can feel exhausting (and frustrating!) over time, and I argue that we often need to take the time (or at least more time) to figure out what type of problem we’re dealing with, rather than merely treating the symptom(s) in the short-term.

 In the professional world, I often categorize problems as either: 1) People & Processes or 2) Tech & Tools. A user isn’t able to use a specific functionality that he/she expected upon the rollout of a new system. The user thinks, “there’s something wrong with this new system! I liked the old system.” At first glance, it’s not clear what type of problem we’re facing. Does the system have the capability but it just hasn’t been enabled for the user? Does the system have the capability but it is not available on the plan that was purchased? Is this functionality not even applicable at all in the new system? As people have problems with “the system” they automatically categorize it as “Tech & Tools” – and they may be correct. However, it is also plausible that the individual did not get the correct training materials or has not been informed of new process changes.

 A husband doesn’t reply back to a wife’s texts or calls in a timely manner. The wife gets upset, because he usually replies much sooner. What’s going on? The wife may automatically categorize this as a “People & Process” problem, but it’s possible something is wrong with his phone & connection: lack of service and hiccups in the network do happen. The husband’s plans may have also changed and he didn’t communicate (or see the need to communicate) those changes back to his wife. If so, then this becomes more of a “Process” problem under “People & Processes” whereas the wife may have initially framed this as a “People” problem. The couple may need to discuss how they will handle communicating changes in plans.

 I get it: it may not be feasible to take the time to frame all symptoms of all underlying problems. Sometimes (or many times!) intensely-felt problem symptoms require immediate solutions. But if the same issue keeps recurring with the same system, process, or people, then it may be time to properly frame the problem.