Skip to content

How the Problem Is Managed

Definition

The client's first description of what's wrong — the "presenting problem" — is rarely the real problem, because managers' explanations of their own pain are the same explanations that already failed to fix it. Block's redefinition move splits every technical or business problem into two layers: the problem itself, and how the organization is managing that problem (its politics, its defensiveness, its communication patterns) — and treats the second layer as an equally legitimate, often more useful, object of inquiry.

In the Book

Block's central example is employee turnover at a large technical organization. First-line supervisors gave management the presenting problem: pay too low, housing too scarce, young employees too entitled. Management acted on it directly — raised compensation, built a housing-assistance program, ran workshops on career realism — and turnover didn't improve; in some sections it worsened. Internal consultants brought in afterward interviewed the departing employees directly and got a different story: no meaningful assignment for nearly a year, no accurate feedback from overworked supervisors, no real integration. Block frames the shift as moving "from the language of innocence... to accountability" — the first diagnosis blamed external, no-fault conditions; the second implicated the client's own management practices, and only the second diagnosis, once acted on, actually reduced turnover. Chapter 10 then generalizes with a table (Figure 10) pairing technical/business problems against parallel management problems by function — e.g., in finance, "too many reports" pairs with "withhold information and figures"; in HR, "HR specialists used as a pair of hands" pairs with managers fearing HR involvement in performance evaluation. Block argues consultants avoid this second layer because it feels like overstepping ("we've been asked to solve a business problem, not comment on the organization"), but that avoiding it is what leaves technical recommendations "distorted and only partially implemented."

Why It Matters

This gives a concrete alternative to accepting a stated problem at face value: treat the manner in which a problem is being handled — who's avoiding what conversation, what gets hidden, what gets repeated without resolution — as data about the real problem, not a distraction from it. It applies wherever a system's self-diagnosis is suspect precisely because that same system has already tried and failed to fix itself: the pattern of failed handling is often a more reliable signal than the story being told about the failure.