Why the problem you have named is probably not the problem you have

There is a particular kind of meeting that I have sat in more times than I can count — the kind where a leadership team arrives already certain of what the problem is, and where the rest of the session is spent debating solutions to that named thing, never once pausing to ask whether the name is right. The named problem has a kind of authority by the time it reaches a working group or a strategy offsite. It has been repeated enough that it feels like a fact rather than a hypothesis. And yet, in my experience working with organisations across sectors, the named problem is almost never the actual problem — it is, instead, the symptom that was most visible, most politically safe to name, or most recently complained about by someone senior. This matters enormously, because the energy, money, and goodwill that organisations spend on wrong problems is not recoverable, and the damage done by solving the wrong thing with great competence can persist for years. What follows is not a methodology deck or a process checklist — it is an attempt to think carefully, in writing, about why this happens, how to notice it, and what a more honest kind of problem-naming might look like.

The authority of the named problem ¶

When a problem acquires a name inside an organisation, something subtle but consequential happens: the name begins to function as evidence. 'We have a talent retention problem' or 'our digital transformation has stalled' or 'the culture isn't aligned with the strategy' — these phrases arrive in meetings with the weight of diagnosis, when in fact they are closer to first impressions. The philosopher Ian Hacking wrote extensively about how naming something — classifying it — changes the thing itself and changes the people who interact with it. He was writing about people, not organisations, but the dynamic is recognisable. Once the leadership team has agreed to call something the talent retention problem, the entire apparatus of the organisation begins to orient toward that name: HR commissions an exit survey, a consultant is hired who specialises in retention, a budget is allocated. The name has created a reality, and that reality is now defended not because it is accurate but because a great deal of organisational energy has already been invested in it.

Why the misname persists: three quiet forces ¶

The first force is political safety. In most organisations, the visible symptom is easier to name than the structural cause, because the structural cause usually implicates a decision that someone powerful made. Saying 'we have a retention problem' is safer than saying 'we reorganised the company eighteen months ago in a way that eliminated the career paths that our best mid-level people depended on.' The second force is proximity. The problem that gets named is almost always the problem that was most recently felt, or felt most acutely by whoever had the ear of the person who commissioned the work. This is not cynicism — it is just how attention works. The third force is the grammar of organisational problem-solving itself, which tends to reward speed of diagnosis. Leaders who say 'I'm not yet sure what the problem is' are experienced as hesitant, while leaders who name a problem confidently and move immediately to solution are experienced as decisive. The incentive structure runs directly against careful naming.

The gap between symptom and structure ¶

One of the clearest ways I have found to explain the symptom-structure gap is through a case that a colleague described to me after working with a mid-sized financial services firm. The firm had named its problem as poor cross-functional collaboration. Teams weren't working together, handoffs were slow, the left hand didn't know what the right hand was doing. A collaboration consultant was brought in, workshops were run, a new project management platform was introduced. Eighteen months later, the collaboration was measurably no better. When my colleague went back in and spent three weeks doing interviews — not surveys, interviews, sitting with people for an hour at a time — what emerged was a completely different picture. The organisation had, over a decade, developed a compensation structure in which individual performance metrics were so dominant that any time spent helping another team came at a direct personal cost. People were not failing to collaborate because they didn't know how; they were failing to collaborate because the incentive structure punished them for doing so. The problem was not collaboration. The problem was the design of the reward system. The misname cost the firm two years.

A method for testing whether you have the right problem ¶

The test I have found most useful is one I think of as the 'so therefore' chain, though it is really just disciplined causal reasoning applied slowly. You begin with the named problem stated as plainly as possible. Then you ask: if this is truly the problem, what would we expect to observe in the organisation that we are not currently observing? And: what would we expect not to observe that we are in fact observing? This is hypothesis-testing in the most basic sense — not statistical, not complex, just honest. If the problem is genuinely a collaboration problem, you would expect to find that people want to collaborate but lack the tools or the relationships to do so. If instead you find that people have the tools, know each other perfectly well, but consistently choose not to collaborate when it conflicts with their individual targets, you are looking at something else. The second part of the method is to ask who named the problem and what they could see from where they were standing. Every diagnosis is a view from somewhere. A CFO names problems that are visible from the P&L. An HR director names problems that are visible from attrition data and engagement scores. Neither view is wrong, but neither is complete, and the problem that gets named is almost always the problem that was most legible to the person with the most naming authority.

The underrated value of sitting with uncertainty ¶

There is a passage in Maggie Nelson's 'The Argonauts' where she writes about the discomfort of categories — the way they simultaneously clarify and distort. I think about that passage often in the context of organisational diagnosis, because the pressure to name a problem is really a pressure to categorise, to make legible, to move from the discomfort of not-knowing into the relative comfort of having a plan. But the organisations I have seen navigate genuinely hard problems well are the ones that were willing to spend real time — sometimes weeks, sometimes a full quarter — in a state of structured uncertainty, gathering evidence, running small experiments, revising their hypothesis about what the problem actually was. This is not the same as being paralysed or indecisive. It is the opposite. It requires more rigour, more confidence, and more organisational maturity to say 'we are not yet certain enough of the problem to invest in a solution' than to name something quickly and start spending. The Japanese have a practice in manufacturing contexts called 'going to the gemba' — going to the actual place where the work happens, looking at it directly, before drawing conclusions. The equivalent in organisational strategy is less celebrated but just as necessary.

What honest problem-naming looks like in practice ¶

Honest problem-naming tends to have three qualities that distinguish it from the more common kind. First, it is explicitly provisional — it carries its own uncertainty, phrased as a hypothesis rather than a conclusion: 'our current best understanding is that the problem is X, and we are holding that lightly.' Second, it names the evidence that would cause the hypothesis to be revised: 'if we find that Y is true, we will need to reconsider.' Third, it has a named author and a named date, so that when the organisation returns to it in six months, it is possible to ask whether the hypothesis has been tested rather than simply assumed. None of this requires a complicated framework. It requires the habit of treating problem statements the way a good scientist treats a hypothesis — as a starting position to be tested, not a conclusion to be defended. The organisations I have seen do this well tend to have at least one person in the room whose explicit role is to ask 'but what if that's not actually the problem?' — not as a disruptive move, but as a structural function of the diagnostic process.

I don't think organisations misname their problems because they are careless or incompetent — I think they do it because naming is hard, uncertainty is uncomfortable, and the incentive structure of most organisations rewards confident action over careful thinking. What I keep coming back to, after years of sitting in the rooms where these namings happen, is something quite simple: the most expensive thing an organisation can do is solve the wrong problem well. The work of getting the problem right before reaching for solutions is not a delay — it is the work.