The Recursive Why

The most powerful question is the one you ask again.

← All posts

The wrong question

Someone has a problem with meetings. They ask: "How do I make meetings better?"

That's the wrong question. It assumes the meeting is the right shape and just needs polish. A shorter meeting is still a meeting. A meeting with a better agenda is still a room full of people optimizing for whoever talks the loudest.

"How do I fix X" accepts X as given. It tinkers at the surface. You can spend your whole career tinkering at the surface and never realize you were solving the wrong problem.

The right question is: Why does X exist?

Go again

Ask why. Get an answer. Then ask why again.

This is what "recursive" means — a process that repeats itself, each time going one level deeper, using the output of the last round as the input for the next. You keep asking why until you hit something that can't be broken down any further. Bedrock.

Most people ask why once and stop. They get a surface answer and start building on it. The recursive why doesn't stop at the first answer. It treats every answer as a new question.

That's the abstract pattern. Here's how it played out when I turned it on meetings:

The meetings example

Here's how this actually played out. I was sitting in a meeting. Forty people. One person talking. Thirty-nine pretending to listen. I opened a terminal and started asking why.

Why do we have meetings? To share information, solve problems, make decisions, build relationships.

Why do all four of those need the same format? They don't. They have completely different requirements. Sharing information doesn't need a room. Problem-solving doesn't need a live audience. Decision-making shouldn't reward whoever talks the most. Only human connection actually needs people in the same space.

Why would one pattern fit all four? It wouldn't. We forced it because there were no alternatives. Nobody designed anything better. The meeting was the default, and every function got crammed into it.

Bedrock: make a distinct pattern for each requirement. Then decompose each one with the people who do the work.

Four functions — status, problem-solving, decisions, human connection. Each one gets its own shape. I told Claude: "Build it." And it turned a plain English sketch into a 30-page corporate proposal with questionnaires, flow diagrams, a phased rollout plan, and a redefined role for the person who used to book conference rooms. One session. Forty-five minutes. The full tutorial is here.

Decompose each piece

Bedrock gives you the pieces. Now decompose each one. For every piece, ask two questions: what is this for? and what does it actually need? Then build something cheap and temporary to meet the need — using the tools your team already has.

The diagrams below color-code these four needs so you can see them working in each pattern:

Status

Purpose: know what's happening without a room. Build: a markdown template per person. AI reads them overnight, writes a summary, flags what's blocked. One prompt.

Problem-solving

Purpose: get everyone's real thinking without the group defaulting to whoever talks first. Build: a blind input form per person — nobody sees anyone else's answer until all have submitted. AI synthesizes. One prompt.

Decisions

Purpose: make traceable decisions without the loudest voice winning. Build: a markdown ballot per voter — named positions, named votes, dissent preserved in the record. AI tallies. One prompt.

Human connection

Purpose: build trust. Build: a calendar invite. No AI, no agenda, protected time. This one is irreducible — you can't automate trust, and you shouldn't try.

Notice what "software" means here. It's markdown files — plain text documents that AI can read, write, and process. Not an app. Not a platform you buy from a vendor and spend six months configuring. Text files. Each one took one prompt to build. Each one is disposable — if it doesn't work, throw it away and build another one in the same conversation. It costs nothing.

And every single one of these is better than what it replaced. Not because the tool is sophisticated, but because it's purpose-built for one job. A meeting tries to do four things and does none of them well. A markdown file that does one thing does it better than a room full of people ever could.

Why it works

The recursive why finds the unit. By the fourth question, I wasn't fixing meetings anymore — the meeting turned out to be the wrong unit entirely. The right unit was the function underneath: status, problem-solving, decisions, connection. Once you have the pieces, you can build something new for each one. You can't see that from the surface.

Why AI is the perfect partner for this

Asking "why" repeatedly is socially expensive. In a meeting (irony intended), if you keep asking why, people get uncomfortable. They think you're being difficult, or slow, or hostile. The room wants to move to solutions. The room doesn't want to decompose the problem. The room wants action items.

An AI doesn't need the preamble. It will answer "why" as many times as you ask, without rushing you to solutions or judging the question. You bring the judgment — which "why" to follow, when to stop, which answer is bedrock. The AI brings the patience — and once you hit bedrock, it builds the deliverable from your sketch.

When to stop

Every recursive process needs an exit condition — a rule that tells it when to stop looping. The recursive why has two.

Bedrock. The answer can't be broken down further and you can build on it. "Each function can have its own shape" was bedrock. Start building.

Metaphysical. You ask why, and the answer stops being useful. "Why do we have meetings?" leads somewhere productive. "Why do humans need to communicate at all?" leads somewhere else entirely.

Descartes kept asking "why" until the only thing he could prove existed was his own thinking. I think, therefore I am. Everything else — other people, the room, the meeting — might be a dream.

Berkeley gave one of the most beautiful wrong answers in the history of thought. Philosophers in his era were worried about what they called the veil of sensation — the idea that our senses might not show us reality as it truly is, that we're trapped behind a curtain we can never peek behind. Berkeley's comeback: there is nothing behind the curtain. Nothing exists unless it's being perceived. The chair isn't there when you leave the room. Your senses don't represent reality — they are reality.

Logically airtight. Internally consistent. Almost certainly wrong, in a way nobody has managed to prove in three hundred years.

Once you're asking those kinds of questions, you've gone one level too far. Back up. The previous answer was your bedrock.

The skill is knowing which exit you've hit. Bedrock feels solid — you can stand on it, build on it, hand it to someone else and they can build on it too. Metaphysical feels infinite — there's always another layer, but none of them help you do anything. If the next "why" would make a philosopher nod and a builder shrug, stop.

The skill underneath

This isn't an AI technique. It's a thinking technique. Toyota called it "the five whys" in the 1950s and used it to find the root cause of manufacturing defects. Philosophers have been doing it since Socrates sat in the agora and annoyed people by asking why until they contradicted themselves.

The AI doesn't change what the technique is. It changes what you can do once you've used it. Before: you hit bedrock, you understood the problem, and then you spent three weeks writing the proposal. Now: you hit bedrock, you understand the problem, and you ship the same afternoon.

The understanding is still yours. The speed is the machine's. That's the trade.

← Back to posts