Bottleneck Attack

Bottleneck Attack

Identify the one constraint whose removal unlocks the most downstream progress, then attack it in the right order.

Speeding up something that should not exist is not progress.

When to use

Use this skill when:

• deciding among several plausible initiatives;
• a metric is underperforming and the cause is unclear;
• progress feels diffused or stuck;
• someone proposes new infrastructure before proving what it unlocks;
• several teams are optimizing different symptoms of the same problem.

Do not use it when:

• the root cause is already verified and the fix is obvious;
• the work is pure exploration with no decision to make;
• the constraint is taste or creative judgment rather than throughput;
• a simple, bounded bug should just be fixed.

The tell: if the proposed action begins with “build,” “add,” or “automate” and nobody can name the exact constraint it removes, run this skill.

Core beliefs

1. Attack the tip of the spear. Concentrate effort on the dominant limiter instead of improving several secondary problems.
2. Find the bottleneck of the bottleneck. Abstract labels such as “retention,” “complexity,” or “alignment” are symptoms. Drill until the constraint is a specific mechanism, step, object, or requirement.
3. Use the algorithm in order. Question → Delete → Simplify → Accelerate → Automate. Starting at automation compounds the wrong decision.
4. Instrument disagreements. When two explanations compete, run the smallest test that allows reality to decide.
5. Engineer cheap failures. Reversible failures are information. Irreversible, compounding, or reputational failures require assertion gates.
6. Count externalities. A local improvement that transfers cost to people who cannot consent is debt, not optimization.

Find the real bottleneck

Choose the direction that matches the evidence you have.

Top-down: drill from a broken metric

L1 — Surface symptom
  “Activation is low.”
        ↓ What is limiting L1?
L2 — First-order constraint
  “Most approved users never complete setup.”
        ↓ What is limiting L2?
L3 — Attackable mechanism
  “The approval message has no setup path or observable completion event.”

Stop only when L3 is:

• specific enough to change today;
• causal enough that removing it should move the goal metric;
• general enough to measure across more than one anecdote.

Bottom-up: drill from a specific anecdote

1. Take the detail seriously.
2. Recreate the journey yourself.
3. Ask whether the instance represents a class.
4. Measure the class.
5. Fix the class-level mechanism, not only the original instance.

Use at least three comparable instances when possible. If the pattern does not generalize, treat it as a one-off rather than the system bottleneck.

The worksheet in references/worksheet.md supports both paths.

Classify the failure

Before attacking L3, ask whether a failed attempt would be catastrophic.

Catastrophic: irreversible data loss, public breach, burned customer relationship, regulatory harm, or a compounding failure that cannot be cheaply rolled back.

Non-catastrophic: local, reversible, observable, and inexpensive to undo.

For catastrophic work, add explicit preconditions, backups, staged rollout, and a second reviewer. For non-catastrophic work, shorten the feedback loop.

Check externalities

List everyone who bears a cost under the proposed fix:

• customers;
• employees and operators;
• neighboring teams;
• communities or shared resources;
• future maintainers.

For each party, ask:

1. What cost do they bear?
2. Is that cost included in the decision?
3. Could they refuse it?
4. What second-order effect may return as a worse bottleneck?

If the improvement depends on offloading meaningful cost to a party that cannot consent, redesign the attack.

The five-step algorithm

Do not advance until the current gate passes.

1. Question requirements

Every requirement needs a named owner and a current reason.

Ask:

• Who requested this?
• When was it decided?
• Is the original reason still true?
• Is it a hard constraint or an inherited preference?
• Is this the only way to achieve the outcome?

Gate: every surviving requirement has a person, reason, and failed deletion argument. Nameless requirements do not survive.

2. Delete

Remove everything that does not need to exist.

Ask:

• What happens if we stop doing this?
• Which steps exist only because of a requirement we removed?
• Can two steps, tools, or surfaces collapse into one?
• What is the minimum version that still produces the outcome?

Deletion should be aggressive enough that roughly 10% needs to be added back. If nothing was added back, test whether the cut was actually deep enough.

Gate: removing anything else would break the required outcome.