What does The Bottleneck Didn't Disappear. It Moved to My Reviewer mean in practice?
AI-assisted drafting increases draft production from ten to thirty proposals weekly, but total shipped output only rises from ten to eleven because human review capacity remains fixed at nine. Dr. Jonah Tebaa explains that every system has one binding constraint. To fix this, teams must track proposals shipped per week and apply an operating rule: restructure human checkpoints through risk tiering, pre-validated criteria, and batched review blocks before scaling AI drafting tools.
Ten proposals drafted a week. Nine reviewed. Then drafting tripled to thirty, and shipped output moved to eleven. Not thirty. Not even twenty. Eleven. That gap is the whole subject of this piece, and I've been sitting with it because it contradicts an assumption I held for a long time without examining it: that if you make production faster, output rises roughly in step. It doesn't, and the reason why is worth walking through carefully.
The Assumption That Breaks First
The assumption is simple and, on the surface, reasonable: faster drafting means proportionally more finished work. Give a team an AI-assisted drafting workflow, watch first-drafts multiply, and expect the output line on the dashboard to climb with it. In my work advising teams on how they structure AI-augmented production — most of it through Webspot, my AI strategy firm in Beirut — this is the single most common miscalculation I see, and it's usually made by smart operators who are otherwise careful with numbers.
The miscalculation isn't about the AI. The AI genuinely does what it's supposed to do — it removes friction from the drafting step. The miscalculation is treating drafting as the only step that matters. Most real workflows have a second step: a human who reviews, approves, or signs off before anything ships. That step has its own capacity, set by hours in a week and minutes per item, and it doesn't move just because drafting got faster. I want to walk through a composite example — invented, but built from patterns I see repeatedly — that makes this concrete.
The Team Before AI
Take a mid-market enterprise-software sales engineering function: five solutions engineers who draft technical proposals, and one principal solutions architect who holds sole sign-off authority before any proposal reaches a client. This is a common and defensible design — the liability and technical-accuracy risk on a custom proposal sits with one senior, accountable reviewer rather than being distributed.
Before any AI assistance, each solutions engineer hand-drafts about two proposals a week — discovery notes, pricing configuration, technical narrative. Five engineers, two each, gives the team a drafting capacity of roughly ten proposals a week. The principal architect spends about forty minutes reviewing each proposal and protects six hours a week for the task, which works out to a review capacity of about nine proposals a week.
Ten drafted, nine reviewed. Close enough that a single proposal carries over into the next week and clears itself without anyone noticing. Nobody on this team would describe the review step as a bottleneck, because functionally, it barely is one. The system is balanced, and balanced systems are invisible.
What Actually Happened After Drafting Tripled
Then the team adopts a structured AI-assisted drafting workflow. Each engineer's draft time collapses, and individual output rises to roughly six first-drafts a week. Team drafting capacity goes from ten to thirty — a genuine threefold increase, and by every measure the tool was supposed to move, it worked.
The principal architect's review capacity does not change. Review isn't a drafting task — it's a judgment task. Does the technical claim hold up. Is the pricing defensible. Does the scope match what was actually committed to the client in the discovery call. None of that gets faster because the draft arrived faster. Nine proposals a week, same as before.
Within three weeks, the unreviewed queue passes sixty proposals. Sales reps start chasing the architect directly for sign-off, which fragments his calendar further and slows review even more. Some proposals go stale before they're ever looked at — pricing shifts, the prospect's buying window closes, and drafts that were technically excellent become worthless simply by sitting too long. Net shipped output moves from ten a week to roughly eleven. A ten percent gain, riding on top of a three-hundred percent gain in drafting speed.
The Constraint Didn't Disappear. It Moved.
This is where the arithmetic stops being surprising and starts being useful, because it's actually a well-established idea from operations management, applied to a scenario most operations leaders haven't yet had to think about: every system has exactly one binding constraint at a time, and adding capacity anywhere except at that constraint does close to nothing for total output.
Before the AI rollout, drafting and review were close enough in capacity that it was hard to tell which one was the constraint. AI drafting made the answer unambiguous. The constraint was never drafting speed. It was always the review step — it simply hadn't been tested hard enough to show itself. Adding AI capacity to the drafting side didn't remove the bottleneck. It exposed it, and then made it worse, because now thirty proposals a week were arriving to be judged by a person whose week still only has room for nine.
What Restructuring the Checkpoint Looks Like
The instinct at this point is to hire a second reviewer. I'd hold off on that until the review step itself has been redesigned, because in most cases there's a large amount of throughput sitting inside the existing capacity — it's just being spent on the wrong things. In this composite case, the restructuring looks like this:
- Tier review by risk and deal value. Standard-terms proposals under a defined deal size move to a lighter, checklist-based peer review by a senior engineer. Only high-value or custom-terms proposals reach the principal architect.
- Pre-validate acceptance criteria. Define the structural checks — pricing math, mandatory clauses, scope alignment — that a draft must already pass before it enters any human queue at all. This cuts review time per item at every tier, because the reviewer is checking judgment calls, not catching arithmetic errors.
- Batch review into protected blocks. Two ninety-minute blocks a week instead of ad hoc interruptions throughout the day. Batching removes the context-switching cost that ad hoc review quietly carries — a reviewer moving between one proposal and an unrelated meeting loses more time than the review itself takes.
- Change the tracked metric. Stop measuring "drafts produced per week" and start measuring "proposals shipped per week." A team that's rewarded for drafting volume will keep producing volume that never clears the checkpoint.
- Only then, if needed, add reviewer capacity — specifically at the new bottleneck. Not more drafters. More judgment capacity, sized to the actual constraint.
With that restructuring, the principal architect handles roughly four high-value proposals a week — about 2.7 hours. The senior-engineer tier absorbs about twenty standard proposals a week in its own protected time. Total shipped output rises to roughly twenty-four a week — most of the theoretical thirty-a-week ceiling, reached without adding a single new hire, purely by redesigning the checkpoint the AI tool never touched.
The operating rule I now carry into every AI rollout conversation is straightforward: before scaling any AI production tool, map where the human checkpoint sits today, and ask what happens to that checkpoint at three times the volume. It's the same question I settle before putting anything live on BrianServes, my platform for deploying autonomous AI e-mployees into real workflows — an e-mployee that triples drafting into a checkpoint nobody resized hasn't added capacity, it's just moved the queue. If the honest answer is "it breaks," the restructuring work needs to happen before the rollout, not three weeks after the backlog has already formed.
Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.
