Deciding well is a matter of conditions

It happens more often than we'd like to admit: a capable team, working with a solid method and even some flair, makes a decision that turns out to be wrong. Not through distraction or incompetence - and just as often the opposite happens, with the same people deciding extremely well on a different project.

If the quality of a decision depended mainly on who makes it - on talent, seniority, instinct - this kind of swing shouldn't happen. The same people should decide with the same quality everywhere, and the fact that they don't tells us something uncomfortable: what makes the difference, from one project to the next, is the conditions in which the decision is made, even more than who makes it.

It's a small shift in how the question is framed, with large consequences. The interesting question stops being "who knows how to decide well?" and becomes "what makes a decision adequate?".
And, above all: "can those conditions be designed?"

Why the question has become urgent now

The question isn't new. It has become urgent now, for a specific reason.

With AI, the cost of execution has collapsed - prototyping, generating variants, producing artifacts now takes far less time and effort. We know the consequence: when execution is easy, the weight of the work shifts upstream, to the choices that shape execution. That's what we meant when we said that choosing is already designing.

There, though, we were talking about a person who chooses: where it makes sense to introduce AI, and with what role in the process. There's a second, less discussed shift, in which that person steps outside the moment of decision. AI begins to decide on its own, and there are systems that select, rank, recommend, and act without anyone present at the moment the choice is made.

This is where the model we're used to breaks down. As long as a person is deciding, we can rely on their judgment in that instant. If no person is there in that instant, judgment can't be inserted at that point - it has to have been built in beforehand, into the conditions the system inherits. What needs to be designed is no longer the single choice, but the context that makes it adequate even when no one is in the loop.

What makes a decision adequate

It's worth pausing on what we mean by "adequate."

An adequate decision isn't one that, in hindsight, turned out to be right. Hindsight can't be designed for. A decision is adequate when it's made under conditions that made a good choice possible and a bad one recoverable. The measure shifts from outcome to context: the question becomes whether we put ourselves in the conditions to decide well, before we even know whether we got it right.

What are these conditions? A first attempt, still to be tested:

• the problem is properly framed, so energy isn't spent answering the wrong question
• the stakes and the reversibility are made explicit, because a costly, hard-to-correct choice calls for a caution that a minor one doesn't justify
• it's clear who is accountable for the decision, since diffuse responsibility is just another way of saying none
• the relevant information is available and legible, including to the system that may end up deciding
• intentional constraints shape the space of choices, rather than leaving it open-ended

These are deliberately conditions, not rules. A rule says what to do; a condition says what has to be true for doing it to make sense. It's a distinction that, working on complex systems, we've learned not to take for granted.

Decision-making as an organizational capability

There's a temptation, at this point, to read all of this as a matter of individual skill: teach people to decide better, to recognize the conditions, to pause at the right moment. That's useful, but it's the wrong level.

If the adequacy of a decision depends on the conditions, then the real work is designing those conditions at the organizational level - not hoping that the right senior person, at the right moment, will have the clarity to create them on their own. A decision-making capability that depends on the heroics of a few people is, in fact, a point of fragility. The difference between an organization that decides well and one that decides well by chance lies entirely there.

It's also the point where debt quietly accumulates. It's usually read as an effect of speed, of execution outrunning judgment - we've written about this elsewhere. What interests us here lies further upstream: the decision conditions an organization has never designed, which until recently stayed invisible because there was always someone, in the right spot, making up for it with their own judgment. The tools that lower the cost of execution aren't the cause of that debt. They make it due, by removing the time and the people who had been covering for it.

And then there's accountability, which at this level is a very concrete condition before it's a principle. When a system decides on its own, the question "who answers for it?" has no obvious answer. If responsibility hasn't been designed into the conditions - assigned, made traceable, linked to whoever set up the system - autonomy doesn't distribute decision-making power: it opens a gap in which, when something goes wrong, no one answers for it.

Designing decisions in advance

Let's go back to the start. If the quality of a decision lives in its conditions, and if those conditions can be designed, then preparing them is, to all effects, an act of design - distinct from deciding, and often just as relevant, now that execution has become the easy part.

It's a direction we're exploring: designing the organizational conditions so that product decisions are sound, especially when the rush to ship pushes teams to skip steps, or when the product itself ends up deciding, autonomously. We're calling it, for now, Decision-enabling Design. The name matters less than the question it opens, and it's a question worth leaving open: when the product decides on its own, who designed the conditions of that decision?