No because is easier than yes if

There are two ways to answer an idea that probably won’t work and which one you reach for decides what gets built.

The first is to explain why it fails. Someone proposes a basic income for a country where a third of the population in some areas has no bank account and you point out that the money will be spent on status symbols, that gold and mobiles will inflate, that the delivery mechanism doesn’t reach the people it’s aimed at. Every one of those is true and none of them is unfair, and you’ve read the proposal carefully enough to find the holes, which is a good deal more than most of the people in the room will have managed.

The economist Harrison Price called that the “no, because” answer and set it against the “yes, if” one. The second looks at the same proposal and says: yes, if we can find a way to get people bank accounts and yes, if the money reaches people in a form they spend on getting out of poverty rather than on looking like they already have. Same facts. Same holes. A completely different conversation on the other side of it.

The reason this matters is that the two answers feel identical from the inside. Both are analytical, both are evidence-based and both leave you feeling like the reasonable person in the room. “No, because” even feels more rigorous because listing failure modes is harder work than waving them away and you can point at the list.

But look at what each one leaves behind. A “no, because” answer ends the discussion and hands back nothing. A “yes, if” answer ends with a list of conditions and a condition is a piece of work somebody can pick up. It converts an objection into a specification. The holes don’t go anywhere and you haven’t pretended they aren’t there, you’ve just written them down in a form that can be worked on rather than a form that closes the meeting.

There’s nothing wrong with being a “no, because” person and there are rooms where it’s exactly what’s needed. If somebody is about to spend three years and other people’s money on something structurally impossible, the kindest thing available is a clear account of why. Some ideas genuinely should die in the meeting they were born in and the person who kills them has done everyone a favour.

The trouble is that it’s the default. It’s what you fall into when you’re tired, when the idea came from somebody you don’t rate or when you’ve been burned by the last three versions of it. It costs nothing and it always makes you look right because an idea that never gets built can never be shown to have worked. The failure mode is silent and it flatters you the whole time.

So the useful discipline isn’t to stop finding holes. You should find them and you’ll be better at it than most people if you’ve been doing this a while. The discipline is to finish the sentence differently. Not “this won’t work because the delivery mechanism is broken” but “this works if somebody fixes the delivery mechanism” and that is the same observation pointed at a person who can act on it.

You’ll notice fairly quickly which of the two your team runs on. In a “yes, if” team the objections turn into tickets. In a “no, because” team they turn into a reputation for being the person who spots problems, which is a genuinely valuable reputation to have and also a very comfortable place to sit for a decade without shipping anything you’d want to talk about.

What makes the habit hard to see is that it only ever looks like competence from the inside. Nobody thinks of themselves as the person who stops things. They think of themselves as the person who reads the proposal properly and says the thing everybody else was too polite to say, which is a genuinely useful role right up until it becomes the only move you have. The tell is whether anything ever leaves your desk in better shape than it arrived.