A problem is not a task list

The only problems that have simple solutions are simple problems. The only managers that have simple problems have simple minds. Complex problems do not have simple solutions.

— Russell Ackoff

Ackoff's second sentence is the one that gets him quoted, and it is the least interesting. The load is carried by the third.

The insight is not that complex problems are hard. Everyone accepts that. The insight is that they do not have simple solutions at all — not expensive ones, not slow ones, none. Which means the search for one is not merely optimistic. It is a search for something that does not exist, conducted with real budget.

The backlog as category error

Watch what happens when a genuinely complex problem enters an organisation. Within about a week it has become a list.

Users are churning after month two becomes eleven tickets: improve onboarding email, add tooltips, fix the slow dashboard, run an NPS survey. Each ticket is defensible. Each can be estimated, assigned and closed. And the transformation has quietly done something serious: the problem has been replaced by somebody's theory of the problem, and the theory is now unquestionable, because questioning it looks like obstructing progress.

A task list is a solution written in a format that conceals the fact that it is a solution. This is the category error, and it is nearly invisible because the format is so useful for everything else.

Simon's account of design gets at the mechanism. The hard part of design is not choosing between alternatives, it is generating the space of alternatives in the first place, and decomposition determines that space before anyone has had a chance to argue about it. Christopher Alexander spent Notes on the Synthesis of Form on precisely this: the way you cut a problem into parts largely determines what solutions can be found, and the cutting usually happens before anyone realises a decision is being made.

Wicked, not merely difficult

The distinction worth holding onto is between difficult and wicked. A difficult problem has a stable definition and an expensive solution: building a compiler is difficult. A wicked problem changes definition as you work on it, because every attempt alters the situation and reveals constraints that were not previously visible.

Richard Buchanan's essay on wicked problems in design thinking is the clearest treatment I know, and its uncomfortable conclusion is that for these problems there is no stopping rule. You do not finish. You decide to stop, which is a different act and requires a different kind of accountability.

Most product problems worth working on are wicked. Retention, trust, the sensation that a product is fast, whether a team can ship without fear — none of these have a definition that survives the work. Which is why plans expressed as task lists degrade so fast: they were written against a definition that expired in week three.

Donella Meadows adds the systems reading. In a system with feedback loops, an intervention's effect depends on where in the structure you intervene, not on how much effort you apply. Pushing hard on the wrong point produces motion and no change, and the motion is extremely convincing on a status report.

The consequence for how we work

Brooks's No Silver Bullet is the same argument aimed at software specifically. There is essential complexity, which comes from the problem, and accidental complexity, which comes from our tools. Tools keep improving. The essential part does not move, and no methodology has ever moved it.

Practically, this argues for something modest. Before decomposing, spend time on the problem in its undecomposed state — which is uncomfortable, because it produces no artefacts and looks like nothing is happening. Gause and Weinberg's book is a hundred pages on exactly this discipline, and its central question is worth stealing: whose problem is it? The answer reorganises the situation more often than any amount of analysis.

The second consequence is about mass. Because the work is non-linear, adding people to a complex problem does not divide it. It multiplies the coordination and leaves the problem intact — what could have been atomic ends up systemic.

Goldratt built an entire novel around the third consequence: in a system, improving anything other than the constraint improves nothing at all. Local optimisation is not a small win. It is a cost with the appearance of a win, and the appearance is what gets reported upwards.

A backlog is a fine instrument for coordinating work that has already been thought about. It is a terrible instrument for thinking, and it is very often the only one in the room.