Wicked problems: when the problem fights back.

The most expensive decision on any hard problem is the one you make in the first sixty seconds without noticing: what kind of problem is this? Here is the worst-behaved category, told through one small drone, and a dare at the end.

You have been in the room. A kickoff, a war room, an escalation, an offsite. Someone described something broken, said make it go away, and the table went straight to solutions. Maybe you were fastest to the whiteboard. It felt like competence.

Here is why it should bother you. Get the problem TYPE wrong and everything downstream is wasted. The cleaner the execution, the more it costs, because you are building an excellent answer to a question that was never the real one. Whole quarters disappear this way. So do products. And nobody hands you a label: problems do not arrive stamped tame or wicked. You classify them yourself, early, before the momentum of solving makes the choice for you. That skill is rarely taught. It is, quietly, what separates teams that compound from teams that thrash.

Two words, and the solving begins.

A room full of engineers. No briefing, no constraints. The instructor sets one object on the table, a small quadcopter trailing a hair-thin glass fiber that spools out behind it, and says two words: fix it.

And they cannot help themselves. Within seconds the room is solving. Make the fiber lighter. Redesign the spool. Build a cutter. Detect the heat and burn through it. Net it. Trace it. Three solutions deep, arguing about drag coefficients. Nobody, in those first sixty seconds, asks the only question that matters: fix what? For whom, in what setting, measured against what?

That reflex, straight to the build, is the whole subject of this piece. Because the thing on the table is not a problem you fix. It is a problem that fights back.

Follow the object’s history, and the trap appears.

The drone is the fiber-optic tethered FPV: flown through goggles, its control and live video running down the glass as pulses of light. There is no frequency to jam. The room sees that and reaches for a counter. But watch where the object came from, because its history is the trap drawn in slow motion.

First the drone was the problem, and the answer was jamming. So someone deleted the radio and ran the signal through glass. Jamming stopped mattering. But the tether cannot fly past its own cable; it drags, it tangles, it can be traced and cut. So the next room builds the cutter, the net, the heat-detector, exactly what our engineers just sketched. And the room after that hardens the fiber. Each answer rearranges the problem and hands the next room a fresh thing to fix. There is no last move.

The engineers did not solve the problem. They took their seat in an argument that has no end, and they did it without noticing they had sat down.

A tame problem you finish. A wicked problem you only ever leave.

One of these closes. The other never does.

The idea is older than the drone and has nothing to do with weapons. In 1973, two urban planners, Rittel and Webber, split the world into tame problems and wicked ones. A tame problem has a stable definition, a finite solution space, and an answer you can verify. A wicked one has a contested, shifting definition, an effectively infinite solution space, and no test that will ever confirm you got it right, because by the time you could run the test, the problem has already moved. The room treated the drone as tame. It is wicked. That single misread is the entire mistake.

How to know the problem is fighting back.

You do not fix these. You intervene.

This is the trap that capable teams fall into hardest. They take a problem that fights back, declare it tame because they wish it were, build something excellent, and field it everywhere. Then the system fights back, the arms race they ignored writes the next chapter, and they are caught holding a flawless answer to a question that already changed.

Wicked problems are managed, not solved. The shift is from fixing to intervening: find the leverage points, map the stakeholders and the feedback loops, make a move, watch what actually shifts, and adjust. The deliverable is not a solution and a victory lap. It is an intervention strategy and a standing agreement to keep watching. The fix for the room was never a better spool. It was the question they skipped, the same one that opens all four problem types: which kind of problem is this, before I pick up a tool?

Copy the story. Mindrian kicks in.

I want to solve a problem, and I am not even sure I have named it correctly.

The object: a fiber-optic tethered FPV drone. You fly it through goggles, but instead of a radio link its controls and live video run down a hair-thin glass fiber that spools out behind it. There is no frequency to jam, so it flies through heavy electronic interference as if it were not there.

Its history is a chain of solutions, each answer creating the next problem:
- The drone was the problem. The answer was to jam the radio link.
- So the radio was removed and the signal moved to glass. Jamming stopped mattering.
- But the tether drags, tangles, and can be traced and cut. So the answer became cutters, nets, and heat-tracing.
- So the next answer hardens the fiber. Then the next counter. Then the next.

And the same drone is not one problem. In a contested zone it is one thing; over a worksite, a stadium, or a border crossing it is a completely different problem wearing the same body.

Help me think this through properly. First classify it: is this undefined, ill-defined, well-defined, or wicked, and why? Do not jump to a fix. Then tell me which method fits the type you found, and walk me through the first move.