Why Smart People Skip the Question That Matters Most: The Legibility Trap

For the last few months, I've been writing about the questions we skip. This one is about why we skip them.

If you've read my articles, you've seen me circle the same idea from different angles.

In The Causal Stack, it was the team that ran a retro and never found the failure, because they started the causal chain too late. In To Think Outside the Box, First Squeeze It, it was the constraint nobody questioned. The arbitrary 5% target everyone optimized toward without asking where it came from. In Was This a Problem of Knowing, Deciding, or Doing?, you saw how the library pilot was declared a failure before anyone asked whether it had even been given a fair test.

Different domains.

Different stories.

But similar symptoms. A hard, upstream question that nobody asked, and a confident answer built on top of the gap where that question should have been.

I identified the pattern, named it, went over the cons, gave frameworks for catching it. But never answered the question of why we repeatedly get into such situations.

Why do smart, capable, well-intentioned people skip the upstream question in the first place?

I've skipped these questions myself, and watched plenty of capable people do the same. So 'just think harder' isn't the answer. If thinking harder were the fix, people who think for a living would've solved it long ago.

This essay is my attempt to find out what else is at play.

I Couldn't Reason About This in the Abstract

My first instinct was to theorize. Sit down, think hard about cognition and organizations, and try to produce a tidy explanation.

But every abstract answer I reached for was either obvious or wrong. "People are busy." "There's pressure." True, but shallow. They don't explain why the specific move of skipping the upstream question is so consistent across people who have nothing else in common.

To solve abstract problems, you need to ground them in specificity first, and only later attempt to generalize.

So I went looking for a concrete problem. Unfamiliar enough that my experience wouldn't short-circuit my thinking, and small enough that I could work it out on the back of a napkin.

Here's the one I landed on:

When the team digs into the data, a pattern emerges. Every morning, bikes flow in one direction: out of residential neighborhoods, toward the transit hubs and office districts. The problem is what doesn't happen: the return trip. Far fewer people bike home in the evening. So bikes pile up at the office and transit docks, but never cycle back.

The next morning, the imbalance causes further user frustration:

• Residential docks sit empty at 8 a.m. Exactly when people want to start their commute. A would-be rider walks to the dock, finds nothing, shrugs, and takes the car. Next time, they don't even check the app.
• Office and transit docks sit full. The few who do bike in find nowhere to dock, circle the block, and give up.

The docks are almost always unbalanced because of this.

The Room Fills With Options

The program director calls a meeting. The data is on the screen. And to the room's credit, the ideas come quickly:

• Hire a redistribution crew. Truck the bikes back to residential areas and empty docks. It would work, but it's a constant operating cost, paid by taxpayers.
• Buy more bikes. Flood the system so there are always enough bikes to go around. But more bikes need more docks, more capital, more space the city doesn't have.
• Improve the software. Show real-time availability, let people reserve a bike, nudge them toward docks with space.
• Change the incentives. Some want to penalize riders who abandon bikes at already-full docks. Another wants to reward riders who take the extra step to leave the bikes at an empty dock.

Look at that list. Four fixes, pointing four completely different ways. Operations, capital, software, behavior. Each implies a different budget, a different set of stakeholders, and a different roadmap. The room could easily spend weeks arguing about which one feels right.

Every one of those fixes assumes the same thing: that the job is to move bikes around more efficiently.

Not one of them stops to ask the question sitting underneath the entire problem.

The Question Underneath the Answer

Hiring a crew, buying more bikes, improving the app, giving incentives — underneath all these four solutions sits the same belief: the bikes are in the wrong places, and our job is to move them to the right places more efficiently. The whole debate is about the mechanism of redistribution.

But nobody questioned whether redistribution was the right frame at all.

Maybe the return journey is the problem. It's uphill, it's dark, they're tired, they take the train. People are usually spent at the end of the day and may not prefer cycling home.

So the upstream question really is:

Were the docks ever placed for how this city actually moves?

What if the one-way flow isn't a problem to correct, rather the way this city actually wants to use the system?

This question flips the narrative entirely. It reframes an imbalance problem into a placement problem.

The morning flood and the evening trickle stop looking like a malfunction. They start looking like data. The city is telling you, thousands of trips a day, that bike-share here is mostly a one-way, first-and-last-mile tool. Home to transit in the morning, and something else at night. Every one of the four fixes was an unintentional attempt to argue with that signal and force a round-trip pattern onto people who were voting, with their behavior, that they preferred one-way.

Once you stop fighting the tide, the problem transforms into an opportunity. You're no longer optimizing for balance. You're optimizing for the flow that already exists. Some new options open up that were invisible before:

• Discount the evening trips. The bikes sitting useless at office docks all day are wasted inventory. Discount the evening office-to-residential ride, or make it free at peak hours, and riders themselves become your redistribution crew. Feeding two birds with one scone.
• Right-size the docks to the flow. Residential areas don't need large docks. They need bikes staged there before the morning rush. Transit hubs don't need bikes, they need open slots to receive them. The asymmetry stops being a bug and becomes the specification to build to.
• Respect user behavior. If people won't bike home because it's uphill and dark, that's a product boundary. Maybe the evening return is an e-bike, or a transit handoff, or simply isn't bike-share's job at all. Knowing that stops you from spending capital on trips people don't want to take.

None of these were visible a few moments ago, because all four fixes were busy answering how do we rebalance the bikes? The upstream question replaces it with a better one: what is this system actually for, and can we optimize for that instead?

The room had everything it needed to reach the right conclusion. The data was right there on the screen. But the data described the symptom i.e. bikes in the wrong places, and the room mistook the symptom for the problem. This is the exact failure I wrote about in The Street Sweeper Trap: paying 5,000 sweepers to scrub the street every day, at enormous ongoing cost, instead of asking why it keeps getting dirty.

So now I had my concrete instance. A room of capable people, the right data in front of them, generating four confident answers, and skipping the one question that would have turned a cost center into an opportunity.

But why?

My First Answer Was Wrong

I asked myself: why did the team skip the question? And I wrote down what came to me instinctively:

• They were under pressure to show results.
• Groupthink: someone proposed a fix and the room followed.
• The HiPPO (Highest Paid Person, usually by seniority) anchored everyone.
• People didn't feel safe pushing back.
• Nobody owned the problem deeply enough to chase it upstream.

Each of these sounded plausible. But it didn't feel right. These were all about the people. Pressure, groupthink, ego, fear, ownership.

And then it landed: this was eerily similar to how the room had implicitly blamed people for the bike imbalance. The room saw an imbalance and reached for fixes that moved bikes around. I saw a skipped question and reached for explanations about the people in the room. Same move. Same error. Mistaking the symptom for the cause.

I had walked straight into the trap I was trying to take apart, while taking it apart.

The people-level explanation is a dead end. If I put a different team in that room, under the same conditions, they'd skip the question too. And the team after that. The pattern is too consistent to be explained by the character of whoever happens to be standing in the room.

So I made myself ask a different question by taking the people out:

What is it about the situation — not the people — that makes skipping the upstream question the rational, almost inevitable response?

That question led me in two different directions.

The First Force: Action Is Visible. Thinking Is Not.

The first force emerged almost automatically when I stopped blaming people.

In that room, every one of the four fixes is a deliverable. A redistribution crew, a bike order, an app update, a new pricing rule, each can be written down, announced, assigned, tracked. The upstream question: What is this system actually for? produces nothing you can show anyone. No artifact. No line item. No update for next week's status meeting.

So I wrote down what felt true: Any action feels like progress.

But that phrase has something hiding inside it. Feels like progress to whom?

Not to the team. The team isn't fooled because plenty of them probably suspect their favored fix won't fully work. The sense of progress isn't really for them. It's for the people watching. The stakeholder. The funder. The mayor fielding questions about a program that isn't hitting its numbers.

And that observer has one decisive limitation: they can't see the thinking.

They can't see someone in that room asking what the one-way flow is really telling them. They can't see the reframe, the reasoning, the upstream question being worked through. All of it is invisible from the outside. What the observer can see is a decision: a crew hired, a policy announced, a metric now being tracked. A response.

So the reward isn't really for solving the problem. It's for producing a legible response. Something an outsider can look at and read as "they're handling it."

This is the core of what I've come to call 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.

The Second Force: The Upstream Question Changes Who Owns the Failure

I then pushed on the same question from a different angle:

Why does asking the upstream question feel like the opposite of progress to the very people who built the solution in the first place?

Watch what happens to ownership as the framing changes.

Look again at the four fixes. A crew, more bikes, better software, smarter incentives. For all their differences, they share an underlying comfort: every one of them locates the problem as work still to be done. The system has a gap; we'll patch it from here forward. If the system just needs fixing, then the system isn't wrong, and the people who built it aren't wrong either. The program is fundamentally sound. It just needs another initiative bolted on.

Now someone asks the upstream question:

What if the one-way flow isn't a defect, and we built the whole thing around a round-trip assumption we never validated?

The answer points backward. At the dock placement, the demand model, the core premise the program was launched on.

Those weren't the users' decisions. They were the room's decisions. The failure stops being work-to-be-done and becomes a mistake-already-made.

The evidence is the same. The bikes pile up in the same places either way. What changed is who owns the failure and when it happened.

And this is where I started feeling vulnerable on the room's behalf: in a room already under criticism for not delivering results, the upstream question doesn't just cost time. It manufactures fresh evidence of the room's own misjudgment, and points it at decisions made by the very people who'd have to flag it. Under pressure, that's a career risk.

So the skip isn't laziness. It's self-protection but not even a conscious one. No one in that room consciously weighs the question and rejects it. The patch is simply the safer option: it keeps the failure in the future, where it's everyone's shared problem to solve, rather than in the past, where it's someone's fault.

I touched the edge of this in When Not to Fail Fast, asking who actually bears the cost when an experiment "fails." This is that same question turned inward: when the upstream question finally gets asked, whose competence is suddenly on the table?

The Two Forces Are Really One

For a while I held these as two separate forces. The visibility force (thinking is invisible, so it isn't rewarded) and the ownership force (the upstream question drags the failure into the past and pins it on the room, so it's dangerous).

But connect them, and you see how each one feeds the other until the skip becomes almost inevitable.

There are three kinds of stakeholders in this system:

1. The team who built the solution.
2. The users of the solution.
3. The observer of the solution.

Since the users are also observers, we can collapse 2 and 3 and call them the audience.

The audience can't see thinking — so thinking earns no credit. And when thinking finally does surface something legible, that something is often evidence of failure that points at someone inside the room — so it earns negative credit.

Put those together and the logic collapses into something brutally simple:

Invisible work earns nothing. Visible thinking is dangerous.

Therefore visible action — even wrong action — feels safe and legible.

Given that payoff structure, skipping the upstream question becomes the optimal play. Every incentive in the room points away from the question and toward the incremental patch.

That reframed the whole problem for me. I stopped seeing the skip as a failure of the people and started seeing it as a rational response to the structure they're standing in.

So the skip is rational. And rational things don't yield to "try harder." If the structure is what produces the skip, then the structure is what has to change — which turns out to be harder, and more interesting, than it sounds.

That's where I pick up in Part 2: What We'd Have to Change.

This is Part 1 of a two-part essay. It grew out of The Street Sweeper Trap, When Not to Fail Fast, and Why Does Your Team Keep Shipping and Missing?