How to be the only human in the loop without being the bottleneck

Being the only decision-maker doesn't make you the bottleneck. Being the only person who can do the analysis in front of the decision does. The fix is a fixed brief format: situation, recommendation, the specific weigh-in needed, ideally answerable in one word. Then protect the two things that genuinely need you, taste and the acceptance walk, and count how often you have to raise the same thing twice.

Every founder I work with has some version of this problem. Everything routes through them, they know it's slowing the team down, and the advice they get is "delegate more." So they try, and one of two things happens. Either they delegate decisions they should have kept and spend a month undoing it, or they delegate nothing and stay the constraint.

The framing is wrong. The bottleneck was never the number of decisions you make. A real decision takes seconds. The bottleneck is the work sitting in front of the decision: reading the thread, reconstructing the context, weighing the options, figuring out what's actually being asked. That's the expensive part, and it's the part that can move.

I've been testing this at an extreme. I'm building a product with a fleet of AI sessions and I'm the only human on it, which means there's no one to absorb sloppy delegation on my behalf. If the interface between me and the work is bad, I feel it that day.

Everything arrives in the same shape

Nothing reaches me as a question. Everything reaches me as a brief with three parts.

Situation. What is true right now, in a few lines, written for someone who has not been following.

Recommendation. What the person or session bringing it to me thinks we should do, stated plainly, with the reasoning compressed to its load-bearing parts.

The specific weigh-in needed. Not "thoughts?" but the exact call, scoped so tightly that the answer is a word.

The third part is the one people skip, and it's where most of the time goes. "What do you think about the onboarding flow" is not a decision request, it's an invitation to do someone else's analysis. "We can ship the three-step version now or hold two weeks for the personalized one. Recommend shipping now and testing personalization after. Go or hold?" is a decision request.

The best brief I got in the last month asked me to settle four things about a large rollout at once. I answered all four in four short phrases. Not because I'm decisive, but because someone had already done the thinking and left exactly four forks with a recommendation on each.

<rect x="30" y="88" width="330" height="52" rx="10" fill="hsl(var(--card))" stroke="hsl(var(--border))" stroke-width="1.5"/>
<text x="52" y="112" font-size="12" font-weight="800" fill="hsl(var(--foreground))">RECOMMENDATION</text>
<text x="52" y="130" font-size="10.5" fill="hsl(var(--muted-foreground))">What I think we should do, and the reason</text>

<rect x="30" y="152" width="330" height="52" rx="10" fill="hsl(var(--card))" stroke="hsl(var(--teal))" stroke-width="2"/>
<text x="52" y="176" font-size="12" font-weight="800" fill="hsl(var(--foreground))">THE ASK</text>
<text x="52" y="194" font-size="10.5" fill="hsl(var(--muted-foreground))">One scoped fork, not "thoughts?"</text>

<path d="M 360 50 C 420 50, 420 114, 470 114" fill="none" stroke="hsl(var(--border))" stroke-width="1.5"/>
<path d="M 360 114 L 470 114" fill="none" stroke="hsl(var(--border))" stroke-width="1.5"/>
<path d="M 360 178 C 420 178, 420 114, 470 114" fill="none" stroke="hsl(var(--border))" stroke-width="1.5"/>

<rect x="472" y="86" width="218" height="56" rx="10" fill="hsl(var(--card))" stroke="hsl(var(--ember))" stroke-width="2"/>
<text x="581" y="110" text-anchor="middle" font-size="12" font-weight="800" fill="hsl(var(--foreground))">THE ANSWER</text>
<text x="581" y="129" text-anchor="middle" font-size="10.5" fill="hsl(var(--muted-foreground))">One word. Seconds.</text>

<line x1="30" y1="222" x2="360" y2="222" stroke="hsl(var(--teal))" stroke-width="2"/>
<text x="195" y="242" text-anchor="middle" font-size="10.5" font-weight="700" fill="hsl(var(--teal))">all of the cost is here</text>
<text x="581" y="242" text-anchor="middle" font-size="10.5" fill="hsl(var(--muted-foreground))">none of it is here</text>

That's the point worth holding onto. When an answer takes you twenty minutes, that's usually not a hard decision. That's a brief that made you do the work.

Protect the two things that actually need you

Compressing everything into briefs has an obvious failure mode: you start approving summaries of things you've never seen. So two categories stay unmediated.

The first is taste. Whether a thing is good is not delegable and doesn't survive summarization. A report saying the copy reads well is not evidence that the copy reads well.

The second is the acceptance walk. I go through the actual product myself, regularly, and that walk is the real gate. Not the tests, not the merge, not the report. In the same period where my decision input was a handful of short rulings, I also did six full walk rounds and sat with two teenagers using the thing. That's not a contradiction of the one-word interface, it's what makes it safe. The interface compresses decisions. It does not compress contact with the product or the user.

Count how often you raise the same thing twice

This is the habit I'd most want to hand to someone else, and it came out of being annoyed.

Every correction I raise gets an ID and goes in a ledger, and nothing closes until it's verified in the product. Which means repeat-raises are visible. If I flag the same thing three times, that's counted, and it's a signal about the system rather than about the person.

Here's the one that taught me. Something on screen felt wrong to me. It got "fixed" three times, and each fix addressed the animation of the element rather than the thing I was actually reacting to. I raised it a fourth time. That fourth pass finally measured it instead of guessing: an observer counted DOM mutations and found one element arriving as a single insertion with zero text mutations, while the line after it grew through 46. The subjective complaint had an objective signature the entire time, and three rounds of plausible fixes had never gone looking for it.

Three rounds of "fixed" meant nobody had found the actual mechanism. The count is what surfaced that. If you don't track your own repeat-raises you will read that pattern as your team being sloppy, when it's usually your team solving a different problem than the one you described.

The corollary rule: nothing a founder raises can be quietly parked. Killed on purpose is fine. Silently dropped is not, because you can't tell the difference from the outside and you stop raising things.

This is the same thing I ask of a team

None of this is AI-specific. The reason it shows up so sharply with a fleet of sessions is that the volume makes a bad interface unsurvivable within a day, where a human team can absorb a vague ask for a week before anyone admits they're stuck.

The rule I hold my own team to is the same one: never bring a question without a recommendation. Not because the recommendation is always right. Roughly half get changed. But a recommendation forces the thinking to happen before the escalation, and it turns my job from analysis into judgment, which is the only part that needed me.

The takeaway

If you're the constraint on your team, don't start by giving away decisions. Start by fixing the shape of what reaches you. Situation, recommendation, one scoped fork. Keep taste and keep the walk. Track your repeat-raises and treat a third raise as a broken loop, not a lazy team.

You want to be the person who answers in one word, because everything upstream of that word already got done properly.

Common questions

How do you delegate without losing control of quality?

Delegate the analysis, not the acceptance. Everything comes to you as a brief with a recommendation and a scoped decision, so you're spending your attention on judgment instead of reconstruction. Then keep two things unmediated: subjective quality calls, which don't survive being summarized, and a regular hands-on walk through the real product, which stays the actual acceptance gate.

What does a good decision request look like?

Three parts. The situation in a few lines written for someone who hasn't been following, a clear recommendation with the reasoning behind it, and one specific fork scoped tightly enough to answer in a word. If the ask is "thoughts?" it isn't a decision request, it's a request that you do the analysis.

Why track how often you repeat feedback?

Because a repeat is diagnostic. If the same issue comes back a third time, the usual cause is that each fix addressed a plausible mechanism rather than the real one, and nobody measured. Counting the raises makes that visible early, and it separates a system problem from a people problem, which are handled very differently.