Inversion: The Easier List Is the Backwards One

Suppose you want to be a good manager. Ask people how and you will get a long list of admirable qualities — be inspiring, communicate a vision, empower your team, lead by example. All true, all quite hard to act on tomorrow morning.

Now ask a different question. What would guarantee you were a terrible manager?

The answers come faster and land harder. Take credit for your team's work. Change priorities constantly. Give vague instructions and then criticise the result. Never tell people how they are doing until the annual review. Be unavailable when someone needs a decision.

That second list is more useful than the first, and it is more useful for a specific reason: it is concrete, short, and immediately actionable. You can check tomorrow whether you did any of those things.

This is inversion — approaching a problem backwards. Instead of asking how to get what you want, you ask what would reliably produce the opposite, and then avoid that.

Why backwards is often easier

The asymmetry between the two lists is not an accident. It comes from a structural difference between success and failure.

Success usually has many possible paths, and they are hard to specify in advance. There are countless ways to run a good business, and the right one depends on the market, the moment, and the people. Any general advice has to become vague to stay true.

Failure has fewer paths, and they repeat. Running out of cash. Building something nobody wants. Losing the people who knew how everything worked. These recur across industries and decades, which means they can be named precisely.

There is a second reason. We recognise bad things more reliably than we can define good ones. Everyone can identify a badly written sentence; describing exactly what makes prose excellent is much harder. The same is true of meals, meetings, and software. Our judgement of faults is sharper than our judgement of merit, so a method that works from faults is working with our better instrument.

Put those together and you get the practical claim: removing known failure modes gets you most of the way to a good outcome, without requiring you to specify what the ideal outcome looks like.

Using it in practice

Before starting something, run a pre-mortem. Imagine it is a year later and the project has failed badly. Ask the team to write down why. This is far more productive than asking "what are the risks?", because it removes the social awkwardness of predicting failure — you have declared it already happened, so naming causes is now description rather than pessimism. People raise things they would otherwise keep quiet.

For any goal, write the anti-goal. Trying to build a healthy team? Write down what a toxic one looks like, specifically. Trying to write clearly? List the things that make writing unclear. The negative list is usually more actionable than the positive one, and you can audit yourself against it.

Ask what you should stop doing. Improvement is usually framed as addition — a new process, a new tool, a new habit. Often the larger gain is subtraction. Whatever is actively going wrong tends to cost more than whatever good thing is missing.

Protect the downside first. In anything with real stakes, the first question is not "how much could this earn?" but "what would ruin me, and have I ruled it out?" This is the same instinct as margin of safety — survive first, optimise second. A plan that cannot fail catastrophically has time to work.

Design against the failure, not for the ideal. Safety engineering works almost entirely this way: rather than specifying perfect operation, you enumerate what can go wrong and ensure each has a defence. Checklists in aviation and surgery are inversion made routine — they do not describe excellence, they prevent known errors.

Where it fits and where it doesn't

Inversion is a tool with a clear best use, and knowing the boundary keeps it from becoming its own trap.

It works best where failure modes are known and costly. Anywhere people have been failing at something for a while, the failure list is well documented and avoiding it is high value.

It works less well where nobody knows what goes wrong yet. For genuinely novel work, there is no reliable failure list, and inventing one from imagination mostly produces caution about the wrong things. There, exploring forwards and failing small and often is the better method.

Avoiding failure is not the same as producing excellence. A meal with no faults may still be unremarkable. Inversion reliably clears the floor; it does not raise the ceiling. Most things benefit from clearing the floor first — but if you only ever invert, you end up with something safe and forgettable.

It can tip into paralysis. Once you start listing ways things could go wrong, the list does not naturally end. The discipline is to enumerate failures, address the plausible expensive ones, and then act — not to keep enumerating.

The manager question is the neat illustration of the whole idea. Nobody becomes inspiring by being told to be inspiring. But a manager who stops taking credit, stops changing direction weekly, and starts giving clear instructions has improved enormously — and every one of those changes came from the easier list.