What We'd Have to Change: The Legibility Trap

The Legibility Trap, Part 2. In Part 1, I tried to explain why smart people skip the upstream question. This one is about what it would take to stop.

In Part 1, we looked at why capable people, with the right data in front of them, skip the one question that would have changed the answer. We called it the Legibility Trap.

The Legibility Trap: In most systems, legitimacy comes from visible response. Thinking is invisible, so it earns no credit. Action, even the wrong action, is legible, so it gets rewarded.

Two forces make the skip almost inevitable: the visibility force, because thinking produces no deliverable, and the ownership force, because the upstream question drags the failure into the past and pins it on the room.

Together they produce a brutal equation: invisible work earns nothing, visible thinking is dangerous, visible action is safe.

Which means the skip isn't carelessness. It's the rational play.

And that's exactly the problem.

Rational things don't yield to "try harder." Telling people to ask better questions, think more carefully, or just feel safer doesn't change the payoff structure, and in the absence of the right payoffs, the same behavior continues.

This article isn't about how to make teams "feel safe," or how to get individuals to be braver in the room. It's about something narrower: the small, systemic change that would make asking the right question the rational play, instead of the risky one.

How do you fix the payoff?

We are all problem solvers by nature. Whenever a problem arises, we tend to jump straight to explaining it, figuring out the pattern, and solutioning it. I previously talked about how the human brain is wired to find causes close to effects, and that complex systems don't work that way.

A similar bias shows up in how we judge the performance of a team. Put yourself in the shoes of a leader responsible for a team that took on a high-stakes initiative and missed. You'd want to know, roughly in this order:

1. How big is the problem?
2. What went wrong, and why?
3. What are we doing about it, and what could still go wrong?
4. How can I help?

This is what the format demands. Leaders are managing multiple priorities at once and have to answer a version of these same questions one level up. As long as the problem is contained and there's a credible plan, the finer detail doesn't travel.

However, notice the jump from the second question to the third. The first two are still in diagnosis mode: what happened and why. But the third has already shifted to acting. You could read it generously: maybe the leader is asking how we're solving it. Or less generously: they want to know it's contained. The honest answer is the format doesn't distinguish between the two, and neither does the team's answer. A patch and a real fix both answer "what are we doing about it" equally well on the surface. The problem hasn't been fully understood, and the format has already moved on.

Similarly, the jump from the third question to the fourth assumes the right solution has already been found. None of these questions ask whether the response is even aimed at the right problem.

Now, from the team's perspective, as long as they have a strong answer to that third question (notice I said strong, not correct), and can present a good story, they can downplay the problem itself, because this line of questioning can feel like it's questioning their competence.

Now, this isn't solely the leader's job to catch, and that's partially correct. A leader who doesn't want to micromanage often won't ask how the team arrived at its solution. But without that question, there's no space for the team to say the most useful thing they could say: we spent the week realizing we're solving the wrong problem. In a format built for progress reports, that sentence reads as having no answer.

So the fix isn't a more curious leader, and it isn't a braver team. It's adding a slot, one question asking what the others aren't:

How did we validate that this solution won't fail six months from now?

Or, in the language of leadership:

How will we minimize the time we spend chasing the wrong solution?

That reframing matters. It translates thinking, which is invisible and earns no credit, into reducing wasted cost, which is legible and does. It gives the team a way to show where they are in validating their solution without feeling their competence is on trial. And it works from either direction: a leader can ask it to open the space, or a team can volunteer it before anyone has to ask.

When should you ask the hard question?

The whole reason the upstream question feels unsafe is when it's asked after the failure. By then it becomes forensic. The questions come from outside the team, people feel threatened, and the instinct is to come up with patching proposals rather than honest answers. The later it arrives in the process, the more it feels like an accusation rather than a question.

Which means when you ask matters as much as what you ask.

The earlier you ask "how will we minimize the time we spend chasing the wrong solution," the better your chances of arriving at the right one. Obviously it can't be guaranteed. But when asked early, the question prevents failure. Asked late, it locates the source of it. That's the reflex we need to build: pull the question forward, before anyone owns the outcome.

The practical way to do this is assumption-testing. I first came across this through Continuous Discovery Habits by Teresa Torres. The book is product management oriented, but the principle applies anywhere you're solving a problem.

Every solution has assumptions built into it. Those assumptions need to be validated before you commit to the solution, not after it fails. The better you are at defining and documenting what you're assuming, the better you'll be at validating those assumptions and probing in the right direction, and the earlier you do it, the less threatening it feels, because no one owns the failure yet.

But aren't we supposed to fail fast?

Absolutely.

Fail Fast demands action and quick iterations because you can spend countless hours thinking and validating, but real progress comes from putting potential solutions into real world situations.

But Fail Fast is actually a questioning discipline: you form a hypothesis, define what failure looks like, and test it. What tends to happen instead is that it gets adopted as permission to move, without the hypothesis-building discipline it demands. A methodology designed to force questioning gets converted into a more legitimate-sounding flavor of action.

The bike-share scenario we discussed in Part 1 is a clean example. They could have sided with hiring a redistribution crew and called it an experiment, increased cost to the city, but framed as learning. Without a proper hypothesis, it tests nothing.

A real hypothesis might have been: hiring a redistribution crew to move bikes overnight will solve the dock imbalance.

The specificity matters, because adding the constraint of overnight redistribution immediately tells you something useful. If the docks are unbalanced again by midday, the solution isn't working, and it's likely unsustainable because you'd need to run the crew multiple times a day, not just once.

The difference between a real experiment and a patch in experiment's clothing is the hypothesis. Without it, Fail Fast becomes another way to dodge the thinking and delay the underlying problem.

Who has already solved this?

Consider a goalkeeper facing a penalty kick. The data is clear: staying in the center is statistically the best move. Yet keepers dive left or right nearly every time. They know the data. They still dive. Which tells us that even when the right answer is known, there's another layer underneath: an internal pull toward doing something visible, something that looks like trying. The structural forces we identified in Part 1 sit on top of this layer. But this layer exists independently of them.

This matters because it means the structural fix, building the slot, making the question early and routine, is necessary but won't fully override the instinct on its own. The goalkeeper's team could mandate a rule that he must hold center, and he'd still feel the pull to dive. Structure can force the question. It can't fully silence the bias underneath.

But it's still the best tool we have. And a few institutions have built it well by making the question mandatory before the moment when the instinct would otherwise take over.

The pre-mortem. Before a project kicks off, the team runs a short exercise. The facilitator says: assume it's a year from now and this project failed badly. Write down why. Everyone writes independently for a few minutes, then the reasons go up on the board one by one. The trick is in the framing. A normal planning meeting asks "what are the risks?", which invites people to sound confident and list the risks they've already handled. The pre-mortem assumes the failure has already happened and asks people to explain it. That small shift in tense gives everyone permission to voice the doubt they were sitting on, the concern that felt too speculative or too impolitic to raise while everyone was nodding along. Gary Klein, the decision researcher who studied the technique, found it surfaces far more, and more honest, concerns than a standard risk review. The output is a list of the ways the plan could die, generated before a single resource is committed to it.

Toyota's hansei. Roughly translated, hansei means self-reflection, and at Toyota it's a structured meeting held at project milestones, including after the ones that went well. The point that trips up most outsiders is that a successful project still gets a hansei, and a manager who reports that everything went fine is told, in effect, to look again. The guiding line is "no problem is a problem", meaning the absence of identified issues isn't success, it's a failure to inspect. So the meeting isn't a search for someone to blame, it's an expectation that every effort, including the good ones, carries lessons that are invisible until you deliberately go looking. Over time the team stops treating reflection as a reaction to things going wrong and starts treating it as a normal part of finishing anything.

The military's After Action Review. After an operation or exercise, the unit runs through four questions in order: what was supposed to happen, what actually happened, why the two differ, and what we'll do differently next time. It's run on a peer footing, not as a top-down debrief, so a junior soldier can name something the commander missed. And critically it happens after every operation, the successful ones included, not just the disasters. Because it's a fixed format applied to everything, walking into the room doesn't mean you're in trouble, it means the operation ended.

So how do all three actually defuse the trap?

First, timing. Each one pulls the failure question to a point where no one owns the failure yet. The pre-mortem asks before the decision is committed. Hansei and the AAR ask on a fixed schedule rather than as a reaction to a specific blowup. In Part 1 we saw that the upstream question feels dangerous because, asked late, it points at a decision someone already made. Asked early or on schedule, it points at nothing personal, so it lands as curiosity instead of accusation.

Second, routine. Because the slot runs every time, not just after failure, stepping into it stops being a confession. If reflection only happened when things went wrong, attending one would itself be an admission of guilt. Make it happen every time and that signal disappears. Which also fixes the visibility problem from Part 1, because once the question is a scheduled, expected part of the work, asking it is no longer the risky thing you raise. It's the legible thing you're supposed to produce.

That's the whole move. Make the question early and make it routine.

The smallest version can fit in a single meeting: before a decision is final, someone asks how will we know, six months from now, if we chased the wrong solution?, and the room treats answering it as part of the work rather than an interruption to it.

Where does this break?

There are some decisions that need to be taken immediately. A surgeon with a bleed has a fraction of a second to decide. A firefighter in a collapsing structure. In those moments, a bias toward action is justified. The way you get around this is through practice. Fire drills, scenario playing, first responder's training are all ways to develop muscle memory and a trained judgement that will aid in a crisis situation.

The trap I'm describing belongs to the rooms that had time to ask and didn't. So the real skill isn't "always ask first", it's telling the two situations apart, which is itself an upstream question: do we actually have time to think here, or not? Most rooms have far more time than the urgency in the room suggests.

The second limit is harder to be sure about. I don't think the underlying bias is getting worse. It's probably about as old as we are. But I do think the conditions that used to let teams catch it are eroding. The slot needs dedicated, unhurried time, and that's exactly what modern work is removing.

A few concrete examples of what I mean:

• When your work is visible in real time, an afternoon spent thinking reads as a quiet afternoon doing nothing, so the pressure to produce something visible arrives faster than it used to.
• A doctor with a packed appointment schedule has no slot to ask whether the obvious diagnosis is the right one.
• A parent rushing between activities has no slot to ask whether the routine they're optimizing is the one worth running.

The faster the surrounding system moves, the more the upstream question feels like a luxury you can't afford, even though it's the one thing that would save you the most time. So I'd say the skip isn't more tempting than it used to be. It's that recovering from it has gotten harder, because the space to catch it is being squeezed out.

There are also two questions that can come up as we develop the reflex of asking upstream questions:

The first: who decides which question was the right one to ask? If we start rewarding good questions the way we reward visible action, then someone has to judge which questions count as good, and now we've just moved the whole problem up a level. The audience that used to judge your actions now judges your questions, and there's nothing stopping the same trap from forming around that. I don't have a clean answer yet. The best I can offer is that a question asked early, that can be tested, is harder to fake than a finished-looking action, so the move at least raises the cost of pure theater. But it doesn't eliminate it.

The second: what about the opposite failure? I've spent two essays attacking too little upstream thinking. I've said almost nothing about too much of it, the team that questions endlessly and never ships, that mistakes deliberation for rigor. That failure is real too. To be clear, I'm not arguing for more thinking as a virtue in itself. I'm arguing for creating the space where the question can be asked at all, because right now that space mostly doesn't exist. Where it already exists in abundance, my advice doesn't apply, and you have a different problem to solve.

So what changes?

I expected to find a flaw in people. I found a flaw in what we reward.

The skip persists not because people are careless, but because asking the upstream question is the riskiest move in most rooms. Change what the room rewards, and you change what's rational to do in it.

That's the whole bet. Build the slot. Pull the question forward. Make asking it the expected move, not the brave one. When it stops being brave, it starts being routine. And when it's routine, the skip stops being rational.