This closer is deliberately a workbook, not another thesis. No new theory. Every claim from Parts 1 through 5 collapses into one worksheet you can run against a real project, in either language, in under an hour.

The worksheet

First, list every rung of your own ladder. Borrow Part 1's list, then rename the rungs to fit your domain. For a sales team, "syntax error" might become "a bad line in a lead record," and "deployment" might become "campaign launch." For a research org, "deployment" might become "publication."

Second, for each rung, estimate current cycle time and current queue depth, using Part 2's terms. Most teams, technical or commercial, will realize somewhere around here that they've never actually measured this for the top three or four rungs.

Third, classify each backed-up queue by why it's stuck, using the full Bottlenecks Institute taxonomy from Part 2: coordination, talent, cultural, technical, market, or regulatory. The fix differs by category, and this classification works identically whether the queue is a slow build pipeline or a slow lead-to-call handoff.

Fourth, score each queue on rough value sitting behind it, times how easy it is to drain, and rank them.

Fifth, pick exactly one rung to fix next quarter. Resist the urge to fix three at once. Just one. That just moves the queue around instead of actually shrinking the total, a direct callback to Part 2.

Sixth, tag whether the fix you picked is a value loop or a capacity loop, per Part 4, before you start. That way success gets defined correctly from day one, instead of argued about after the fact.

Worked example A: a small software team

Numbers below are anonymized and composited across a few real sprints, not one specific team. Cycle time first, queue depth second, at each rung. Syntax and type errors: seconds, effectively zero queue — the editor catches them before anyone else sees the code. Unit tests: four minutes, usually two or three commits waiting on a run. Integration tests: twenty minutes, six to eight commits deep before anyone checks the results. End-to-end tests: ninety minutes, and here's where it gets ugly. The suite itself runs fine in parallel — CI isn't the bottleneck. But twelve to fifteen commits' worth of results regularly sit unreviewed before anyone looks, because a 90-minute run is slow enough that nobody checks it eagerly. Deployment: same day, one to two releases queued. Deployment results: three to five days to know if the metrics moved right. Feedback: one to two weeks. Business impact: a full quarter.

Run the worksheet's third step, the why, and the end-to-end rung classifies as technical — but not the way it looks at first. The queue isn't runner capacity. It's attention. Nobody's watching the results closely enough to catch a regression before three more commits land on top of it. Score it on value times drainability and it wins by a wide margin, both because the queue is the deepest on the ladder and because the fix is genuinely cheap: a dashboard that pages someone the moment a run goes red, instead of waiting for the next person to check. That's the one rung this team picks for the quarter — tagged, per step six, as a capacity loop. It doesn't ship a feature. It makes every future feature ship faster.

Worked example B: a sales and GTM team

Same worksheet, an ordinary revenue pipeline: lead generation, qualification, proposal, close, onboarding, renewal. Lead generation to first qualification touch: same day, rarely more than a handful of leads waiting. Qualification to first contact — this is the number that matters — five days, and eighteen to twenty-five qualified leads sitting untouched in that stage at any given moment. Proposal sent to response: four days, six to eight proposals in flight. Close to onboarding kickoff: two days. Onboarding to first renewal signal: a full quarter, by design.

Score every stage the same way as example A, and qualification-to-first-contact wins clearly. It's not the slowest stage in isolation — proposal review takes almost as long. But it's carrying the deepest backlog by a wide margin, and every day a lead sits there is a day closer to going cold. The fix picked for the quarter: qualified leads get a first-contact SLA of one business day, not five. Tagged as a capacity loop too, same as example A, structurally — it doesn't close one more deal by itself. It changes how fast every future lead gets worked.

Run the identical worksheet against two genuinely unrelated domains and the deepest queue beats the slowest station both times, not because the domains are secretly alike, but because the worksheet is built to find backlog, not speed.

Worked example C: a look inside Bottlenecks Institute itself

One flag upfront: this is Parni's own organization, not a neutral third case. It's included as a lived, detailed example we can speak to with real numbers, not as independent proof the framework generalizes. Example B already carries that weight on its own.

Our own expert-survey-to-funder-matching pipeline, same worksheet: survey design to fielding — roughly a week, one to two candidate bottlenecks waiting. Fielding to data collection complete: two to three weeks depending on expert response rates, three to five bottleneck write-ups accumulating in that window. Data collection to peer review, and here's the deep one: five to six weeks, eight to ten write-ups sitting in the review queue at any point, because peer review draws on a small volunteer pool with its own day jobs. Peer review to ranking: one week once review clears. Ranking to funder matching: two to three weeks.

Peer review classifies as a talent-constrained queue in the Part 2 taxonomy, not a technical one, so the fix isn't "build a faster tool," it's "grow the reviewer pool or shrink the batch each reviewer sees." That's the rung picked for the quarter: smaller review batches, more reviewers, rather than trying to make any one reviewer faster.

The recursive close

The companion piece to this series, How Tight Is Your Feedback Loop?, already has a section called "The Meta-Feedback Loop," arguing you should apply the tightening principle to your own feedback loops. This worksheet is that argument made concrete. Re-running it every quarter is cheap, and treating "did we pick the right rung last time" as its own feedback loop is the one practical takeaway worth leaving any reader with, engineer, operator, or researcher.

That earlier piece said tighter loops win everywhere. This series has been the operating manual for finding which loop, in your own stack, whatever that stack happens to be built from, to tighten first.

A Field Guide: Auditing Your Own Loop Stack