Skip to content

Why Founders Who Know the Product Best Sometimes Shouldn't Make the Call

October 10, 2026

og-cover

The short answer: going deep on the details and monopolizing the decisions are two different jobs. Knowing the product determines where your spike is — it does not determine whether every decision ends in your pocket. And the moment decisions get monopolized, the first casualty is the founder's own supply line of information: the raw signal and the bad news that direction calls run on are the first two things your own decision filter screens out.

One boundary before anything else. This piece is not another round of the posture debate over whether founders should sweat the details. It is about whether each individual decision sits in the right bucket. It covers decisions inside the efficiency logic only; red-line and identity-level calls are out of scope — some things need you in the room even if all you do there is close a gate. The cases below come from the interview account of the executive who lived them: one company's retrospective, not a proof of Founder Mode. Where the whole framework breaks, there are three situations named at the end.

After the Meeting, the Product Lead Left One Instruction

Monday's product review, and the founder takes the floor last, as always. Three proposals sit in front of him. He works through them one by one and asks in detail: why does this interaction flow this way, why is the copy written like this, why is this cycle sequenced like that. When he is done asking, he decides. Whether a proposal lives or dies is one sentence from him.

Was he right? Most of the time, yes. He knows the product; his eye is sharper than anyone else's in the room — that is precisely why he could found this company.

The problem starts after the meeting adjourns. The product lead keeps his team behind and leaves them one instruction: next time, don't bring three proposals. Bring the one he is most likely to approve, plus a write-up on why there is no other way.

Six months on, this founder is still making the calls, and every call lands. Only, nobody argues direction with him anymore, and nobody brings a half-formed question into that room. Questions die downstairs; the answers come upstairs wearing suits.

This is not a fable. The interesting part is who turned the ledger over for everyone to see: the people who stood next to him. On Lenny's podcast, Vlad Loktev — who spent years as a leader at Airbnb reporting directly to Brian Chesky — walked through the working method that got mythologized as "into everything." By the host's count, the Chesky episode is the most popular one the show has run; two years ago, Paul Graham's essay "Founder Mode" nailed the myth into a methodology. And yet by Vlad's ledger, Brian never managed everything.

The Slogan Says "Into Everything." The Man Who Was There Says "Selectively."

Take the slogan apart first. By the time Founder Mode reached the startup world, it had been compressed into a single line: into everything, down to the details.

The picture Vlad describes is a different one. Brian walks into the room where calls get made, and most of what he does there is ask questions and listen. Sometimes he hears the answers and changes his mind. Sometimes he holds a strong conviction and doesn't. But one thing has no exceptions. Vlad's account of it: yes, he makes a lot of decisions — "he made sure he was informed... many of us were contributing."

Beyond being fed, there was a boundary. Founders, Vlad says, should be honest about where in the company they have a spike, an edge — the one area where they see more accurately than anyone else in the room. Brian's spike is product, design, and marketing, which made him, in Vlad's words, basically the CPO, and he attended every decision in those areas. As for the rest: let go of what you should let go of, and hand it to someone you trust who is going to uphold a certain quality bar.

So the real shape of the method is not "into everything." It is: bet heavy inside your spike zone; outside it, hand the decision over. Going deep is putting judgment into specific things. Monopolizing decisions is making everything terminate in "I decide." The first is a founder's advantage. The second is a different thing entirely.

Knowing the product decides where your spike is. It does not decide whether every decision ends in your pocket.

Even Picking His Spots, It Collapsed — and It Burned Out

By the slogan's logic, Airbnb should be a story of founder-touched quality taking off. Vlad keeps two very different accounts.

The first account is quality. Push, push, push; ship, ship, ship — everyone was shipping, and what shipped fell apart. Vlad himself, as a leader, wasn't proud of some of what went out the door. Later the company hit the brakes on purpose: miss targets if you must, but stand the quality bar back up first, and speed up only once everyone remembers what good means. His own summary: slow down for a bit, to then speed up later. Note the grade of evidence here — one company's self-told retrospective, not a controlled experiment.

The second account is a person. Around 2018, Vlad burned out: overloaded, crushed, unhappy. He lost friends, dropped many of his hobbies, spent less time with family than he wanted to, and at some point could not tell whether he was a person or a job. The reversal came later, in his own words: "I started spending less time on work and I became way more effective." That is his personal experience, not a management conclusion.

The two entries sit in the same ledger, and they say the same thing: even picking your spots carries a cost. Gather every decision up into your own hands, and the bill only gets longer.

The Cost Nobody Prices Is the Founder's Supply Line

The first two accounts are easy to understand. The third one, nobody prices.

Vlad explained why Brian forced every lead into the details: in the room where direction gets discussed, if a lead cannot say what is actually happening in the business, that group cannot make good decisions. When the details are not in the people, you compensate with headcount — a meeting that fits a team of like ten blows up to a team of thirty, and if those thirty still are not in the details, bring in like fifty. For every inch the information runs short, the meeting room grows a foot.

Brian's system worked because the feeding mechanism was alive: the leads were in the details, the channels were open. Vlad added one thing deliberately: as long as you do not self-censor — as long as you are willing to poke the bear — you can always get the information up.

Now comes a piece of mechanism reasoning, with my register declared first: this paragraph is my judgment, not a claim about things that happened at Airbnb. The moment a founder pulls enough decisions in to become everyone's terminal node, the incentive to feed him changes. Everyone who reports to you learns the same lesson: he is going to re-think it anyway, so hand him a well-formatted answer he wants to hear. Every decision you take away hands the next person one more reason to feed you conclusions only — and the more the team defers to you, the faster that pipeline runs.

A supply line does not snap with a sound. Direction calls run on raw signal and bad news, and those are the first two things to get filtered. The day you notice that every call lands and nobody argues anymore, that is not a victory of decision-making power. That is a room going quiet.

I run this same arithmetic on myself. In eighteen years, the work I did most inside organizations was breaking work down and dividing authority; this year, building my own agent system as a staff of one, the question finally landed on me: which calls must be mine, and which stop being mine once I have fed in the standard. I redraw that line every day, and the cost of drawing it wrong is concrete — the more diligently I decide, the more familiar what the system feeds me becomes, and the faster my own judgment rusts.

The endgame of decision monopoly is not Airbnb. It is nobody bringing you the bad news anymore.

What Gets Divided Isn't Power. It's Three Buckets of Ownership.

Do not swing from here to the other slogan — "founders should let go." Letting go is not a virtue; it is organization design. Put the magnanimity question — am I big enough to release this? — back in the drawer, and use a three-bucket table instead:

BucketWhat goes in itThe key moveWhat happens when you step in
Bucket one: only you can call itDirection, red lines, identity-level calls — wherever your spike livesCome in with questions: ask more, listen moreAdds judgment — you walk in carrying information the room doesn't have
Bucket two: set the principle, then delegateCalls where you have a view of "what is good" but need not rule on each oneTranslate "what I think good looks like" into standards others can reuse; hand it to someone you trust to hold the quality barThe standard stands guard; you don't have to be there
Bucket three: hands offOther people's professional judgment — a craft that takes years to learnRecognize it, and route around itCloses a gate — your intuition lands as noise, and the channels for user voice and expert opinion shut

Bucket one: the calls only the person can make. Brian attended every product, design, and marketing decision because his judgment in those areas is one of a kind. The key move in this bucket is not "managing." It is coming in with questions — in that room, he mostly asked and listened.

Bucket two: the calls a written principle can carry. This is what Brian was doing: he wanted to teach every lead how he judged things and what made a judgment good — and Vlad says he has been grateful for that over the years. Airbnb turning PM into PMM and standing up a separate program management function to take over sequencing and cross-team coordination is the same gesture: move one class of judgment, people and standard together, from one role's hands into another's. One honest footnote on how that reform landed: even by Vlad's account it is "no blanket statement... it depends." Do not copy it as the standard answer.

Bucket three: the professional calls that were never yours. Vlad flags one directly: marketing, he says, it takes years to learn that skill. Your intuition, landing in someone else's professional bucket, is not judgment — it is noise. Worse, the channels for the user's voice and the expert's opinion open exactly in this bucket. Step in, and the channel closes.

The three-bucket table does not audit how much you manage. It audits whether each decision sits in the right bucket. Sitting right, you can be deeper in the work than anyone alive. Sitting wrong, the harder you work, the more anemic the organization gets.

Power answers who gets the final say. Ownership answers who has to be in the room — and ownership is the thing that actually needs dividing.

One Question to Take Into Your Next Call

Next time you are about to make the call, stop for three seconds and swap "am I willing to let this go" for a different question:

Does this decision actually require me? When I step in, am I adding judgment — or closing a gate on a channel?

If "requires me" does not hold, and you are not about to write a new principle, then this is bucket three — you are shutting a channel that should have stayed open. Whether you added judgment or closed a gate, nobody knows better than the person doing it: did you walk in carrying information the room didn't have, or carrying only your title?

Pull every decision you made last week and run each one through this three-second test. Which ones added judgment, which ones closed gates — one sheet of paper will tell you.

Where This Framework Fails

Evidence grade first. The first-hand material in this piece is one executive's interview account: the quality collapse and the deliberate slow-down are a participant's retrospective; working less and becoming more effective is his personal experience; Airbnb is one company's story, not a controlled experiment. None of it proves Founder Mode good or bad, and this piece does not try to. Vlad poured the water himself: don't copy another company's ways of working.

The three-bucket table has failure modes of its own — three of them.

An early-stage company that has not yet produced someone who can hold the quality bar has an empty bucket three, and bucket two has nowhere to go. Force the hand-off by the table, and what you delegate is not a decision — it is an accident. Push-push-push, ship-ship-ship is what speeding up without a quality bar looks like. The move at that stage is not letting go; it is standing the bar up first, then talking about handing things over.

An organization whose information channels are already broken cannot be saved by the table. Once people have learned to feed you answers, delegating the decisions does not help — what reaches the "come in with questions" bucket is still processed goods. The first move is not drawing buckets; it is repairing the channel: make it safe to carry bad news first, and argue about who decides later.

And red-line, identity-level decisions sit outside this efficiency logic altogether. Some things need you present even when stepping in "only closes a gate." That is responsibility. It is not in the table's jurisdiction.

So the next time you sweep into the room for the final call, hold on for a second. Look at the people around the table: did they come carrying questions, or only answers?

The day the answers get too tidy, the problem is not at that table anymore. It is in the ledger of how many decisions you have taken.


How to fill the three buckets, the piece above has covered. The hard part was never drawing the table — it is a founder accepting the buckets where "requires me" doesn't hold. And once judgment has been handed out, how does the credit get recorded? Another piece works the other end of the same problem — “Does Managing More Mean Contributing More?” — on why the scope you were dealt is the company's cards, not your achievement. Align the ledger of the calls you make with the ledger of the cards you were dealt, and authority and responsibility are finally split clean.

I'm Uncle J. I run a one-person AI organization, and the bucket I police most diligently is my own: the day my agents start agreeing with me too neatly, I read it not as a smarter system but as a quieter room — and I go reopen the channel.

AI Organization OS Diagnostic

If this essay describes your organization, run the diagnostic next.

Use 26 questions to locate the broken layer: roles, workflows, knowledge, accountability, or governance.

Open diagnostic

Want to turn this into an operating system? Send Uncle J the context →

J叔

Subscribe to Uncle J's Insider

Notes on AI organization, AI HR, agentic engineering, and content systems when they are worth sending.