---
name: bottleneck-attack
description: Use when deciding what to work on next, when progress is stuck, or when the reflex is to build or automate before proving the current bottleneck. Identifies the single dominating constraint, drills to an attackable mechanism, and applies the ordered sequence question requirements → delete → simplify → accelerate → automate.
---

# 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

```text
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`](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.

### 3. Simplify and optimize

Only optimize what survived deletion.

Ask:

- What is the simplest implementation of the remaining need?
- Where is coordination hiding complexity?
- Can an existing component replace a custom one?
- Is any input costing many times more than its underlying materials, compute, or labor?

**Gate:** no complexity remains that exists only to preserve an eliminated requirement.

### 4. Accelerate

Shorten the loop after the work is necessary and simple.

Ask:

- Which dependencies can run in parallel?
- Where is handoff or waiting latency?
- Can the operator go directly to the constraint today?
- What deadline has roughly a 50% chance of success?

**Gate:** the remaining delay cannot be removed without automation.

### 5. Automate

Automate only a stable, validated process.

Ask:

- Has the manual process worked often enough to deserve automation?
- What is the lifecycle cost of automation at the current volume?
- How expensive is reversal when the process changes?
- What observation will detect silent failure?

Automation is optional. “Not yet” is often the correct output.

## Workflow

1. **State the goal.** One sentence, measurable and time-bound.
2. **Drill to L3.** Use the top-down or bottom-up path.
3. **Classify failure.** Catastrophic or reversible.
4. **Check externalities.** Count costs outside the local metric.
5. **Run the algorithm.** Question, delete, simplify, accelerate, automate.
6. **Set a 50% deadline.** Uncomfortable but credible.
7. **Run a reality test.** Predeclare the measurement and decision rule.

## Output format

```markdown
## Bottleneck Decision: [goal name]

**Goal:** [measurable outcome and date]

**Bottleneck drill:**
- L1 — symptom: [what appears wrong]
- L2 — first-order constraint: [what limits L1]
- L3 — real constraint: [specific mechanism to attack]

**Failure class:** [catastrophic / non-catastrophic, with reason]

**Externalities:**
- [party]: [cost, consent, mitigation]

**Algorithm applied to L3:**
- Question: [requirements challenged; what survived and why]
- Delete: [what was removed and what was added back]
- Simplify: [what became smaller or clearer]
- Accelerate: [parallel work, removed waits, deadline]
- Automate: [what will be automated, or “not yet”]

**Deadline:** [date with approximately 50% likelihood]

**Reality test:** [measurement and predeclared pass/fail rule]

**What I am not doing:** [the attractive wrong move]
```

## Anti-patterns

| Anti-pattern | Failure |
|---|---|
| Automate first | Makes the wrong process faster and harder to reverse. |
| Optimize without questioning | Preserves requirements that should have been removed. |
| Attack several symptoms | Dilutes effort before the dominant constraint moves. |
| Drill forever | Converts diagnosis into avoidance. Stop at a measurable mechanism. |
| Inflate scope during deletion | Turns focus into an unrelated cleanup program. |
| Use unnamed requirements | Replaces evidence with organizational folklore. |
| Treat reversible tests as catastrophic | Slows learning while masquerading as rigor. |
| Offload externalities | Produces a local win subsidized by hidden debt. |

## Integration

- Ground in the domain before deciding which requirements are real.
- If the attack requires a feature, define the user job before planning it.
- Use an eval loop to verify that the chosen metric moved.
- For code changes, pair the attack with tests proportionate to failure risk.

## References

- [`references/worksheet.md`](references/worksheet.md) — fill-in-the-blank workflow.
- [`references/applied-example-mcp-retention.md`](references/applied-example-mcp-retention.md) — synthetic worked example showing the full decision sequence.

## Intellectual provenance

The ordered Question → Delete → Simplify → Accelerate → Automate sequence is commonly associated with Elon Musk's engineering algorithm. This skill combines that sequence with constraint analysis, falsifiable testing, explicit externality accounting, and a reusable decision format. The worked example is synthetic and contains no client or private operational data.