{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib4lmjhcicxp4bamnaa2tvrlve74rlphxlzmv2ocdc7sxhybu4aq4",
    "uri": "at://did:plc:ewahtt65dq4k2bciturk5do6/app.bsky.feed.post/3mnr2v2ycpy52"
  },
  "description": "Why capable people skip the question that matters and why it's rational, not careless.",
  "path": "/why-smart-people-skip-the-upstream-question/",
  "publishedAt": "2026-06-08T06:34:44.000Z",
  "site": "https://www.thoughtmunchies.com",
  "tags": [
    "The Causal Stack",
    "To Think Outside the Box, First Squeeze It",
    "Was This a Problem of Knowing, Deciding, or Doing?",
    "The Street Sweeper Trap",
    "When Not to Fail Fast",
    "Why Does Your Team Keep Shipping and Missing?"
  ],
  "textContent": "_For the last few months, I've been writing about the questions we skip. This one is about why we skip them._\n\nIf you've read my articles, you've seen me circle the same idea from different angles.\n\nIn 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.\n\nDifferent domains.\n\nDifferent stories.\n\nBut 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.\n\nI 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.\n\n**Why do smart, capable, well-intentioned people skip the upstream question in the first place?**\n\nI'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.\n\nThis essay is my attempt to find out what else is at play.\n\n* * *\n\n## I Couldn't Reason About This in the Abstract\n\nMy first instinct was to theorize. Sit down, think hard about cognition and organizations, and try to produce a tidy explanation.\n\nBut 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.\n\nTo solve abstract problems, you need to ground them in specificity first, and only later attempt to generalize.\n\nSo 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.\n\nHere's the one I landed on:\n\n❓\n\n****Problem**** :\nA city launches a bike-share program. Eight months in, usage is well below projection. The bikes are fine. The app works. Pricing is reasonable. And yet riders keep slipping away.\n\nWhen 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.\n\nThe next morning, the imbalance causes further user frustration:\n\n  * **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.\n  * **Office and transit docks sit full**. The few who do bike in find nowhere to dock, circle the block, and give up.\n\n\n\nThe docks are almost always unbalanced because of this.\n\n* * *\n\n## The Room Fills With Options\n\nThe program director calls a meeting. The data is on the screen. And to the room's credit, the ideas come quickly:\n\n  * **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.\n  * **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.\n  * **Improve the software.** Show real-time availability, let people reserve a bike, nudge them toward docks with space.\n  * **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.\n\n\n\nLook 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.\n\n🗒️\n\n****A note before proceeding:**** It doesn't matter which one the room picks. I'm not interested in whether a penalty or a redistribution crew is the \"right\" answer. This is just a simulation. What matters is the thing all four have in common.\n\nEvery one of those fixes assumes the same thing: _that the job is to move bikes around more efficiently._\n\n**Not one of them stops to ask the question sitting underneath the entire problem.**\n\n* * *\n\n## The Question Underneath the Answer\n\nHiring 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.\n\nBut nobody questioned whether redistribution was the right frame at all.\n\nMaybe 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.\n\nSo the upstream question really is:\n\n> Were the docks ever placed for how this city actually moves?\n>\n> What if the one-way flow isn't a problem to correct, rather the way this city actually wants to use the system?\n\nThis question flips the narrative entirely. **It reframes an imbalance problem into a placement problem.**\n\nThe 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.\n\nOnce 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:\n\n  * **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.\n  * **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.\n  * **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.\n\n\n\nNone 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?_**\n\nThe 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.\n\nSo 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.**\n\n**But why?**\n\n* * *\n\n## My First Answer Was Wrong\n\nI asked myself: _why did the team skip the question?_ And I wrote down what came to me instinctively:\n\n  * They were under pressure to show results.\n  * Groupthink: someone proposed a fix and the room followed.\n  * The HiPPO (Highest Paid Person, usually by seniority) anchored everyone.\n  * People didn't feel safe pushing back.\n  * Nobody owned the problem deeply enough to chase it upstream.\n\n\n\nEach of these sounded plausible. But it didn't feel right. **These were all about the people**. Pressure, groupthink, ego, fear, ownership.\n\nAnd 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.\n\n**I had walked straight into the trap I was trying to take apart, while taking it apart.**\n\nThe 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.\n\nSo I made myself ask a different question by taking the people out:\n\n> **What is it about the _situation_ — not the people — that makes skipping the upstream question the rational, almost inevitable response?**\n\nThat question led me in two different directions.\n\n* * *\n\n## The First Force: Action Is Visible. Thinking Is Not.\n\nThe first force emerged almost automatically when I stopped blaming people.\n\nIn 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.\n\nSo I wrote down what felt true: **Any action feels like progress.**\n\nBut that phrase has something hiding inside it. _Feels like progress to whom?_\n\nNot 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.\n\nAnd that observer has one decisive limitation: **they can't see the thinking.**\n\nThey 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.\n\nSo 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.\"_\n\nThis is the core of what I've come to call **the Legibility Trap.**\n\n> **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.**\n\n⚽\n\n****Goalkeepers**** live inside this trap too, and the research makes it almost embarrassingly clear. Studies of hundreds of penalty kicks find that the statistically best move is often to __stay in the center.__ Yet keepers dive left or right nearly every time. Why? Because the norm is to dive, and a goal conceded after a committed dive __feels__ better than the identical goal conceded while standing still. Same outcome, different judgment. ****Standing still gets interpreted as having done nothing.****\n\n* * *\n\n## The Second Force: The Upstream Question Changes Who Owns the Failure\n\nI then pushed on the same question from a different angle:\n\n> **Why does asking the upstream question feel like the opposite of progress to the very people who built the solution in the first place?**\n\nWatch what happens to ownership as the framing changes.\n\nLook 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.\n\nNow someone asks the upstream question:\n\n> _What if the one-way flow isn't a defect, and we built the whole thing around a round-trip assumption we never validated?_\n\nThe answer points backward. At the dock placement, the demand model, the core premise the program was launched on.\n\nThose 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.**\n\nThe 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.**\n\nAnd 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.\n\nSo 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.\n\nI 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?**\n\n* * *\n\n## The Two Forces Are Really One\n\nFor 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).\n\nBut connect them, and you see how each one feeds the other until the skip becomes almost inevitable.\n\nThere are three kinds of stakeholders in this system:\n\n  1. The team who built the solution.\n  2. The users of the solution.\n  3. The observer of the solution.\n\n\n\nSince the users are also observers, we can collapse 2 and 3 and call them the **audience.**\n\nThe 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.\n\nPut those together and the logic collapses into something brutally simple:\n\n> **Invisible work earns nothing. Visible thinking is dangerous.\n>\n>  Therefore visible action — even wrong action — feels safe and legible.**\n\nGiven 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.\n\nThat 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._\n\nSo 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.\n\nThat's where I pick up in **Part 2: What We'd Have to Change**.\n\n* * *\n\n_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?",
  "title": "Why Smart People Skip the Question That Matters Most: The Legibility Trap",
  "updatedAt": "2026-06-08T07:18:11.260Z"
}