supplier-as-bottleneck — quality + safety report

---
name: supplier-as-bottleneck
description: Force a variance-not-mean analysis of every external dependency whenever the user is doing supply chain audits, vendor selection, third-party risk reviews, BOM reviews, or production planning. Trigger aggressively on phrases like "we keep getting delayed by X", "the supplier slipped again", "our vendor missed the date", "we're blocked on a third party", "the chip shortage hit us", "their factory had a fire", "we're waiting on parts", "the API provider went down again", "our cloud vendor had an outage", "we picked the cheapest supplier", "the dependency broke our build", "we're at the mercy of one vendor", "they promised a lead time of X weeks", or any moment a team is planning capacity off a supplier's promised mean instead of their realized tail. Also fires when a roadmap assumes zero supplier failures, when a postmortem blames "bad luck", or when a team is shopping suppliers on price without modeling their variance and competence floor. Trigger eagerly even when the user does not name Musk or the framework.
---

# Supplier As Bottleneck

> "Things move as fast as the least lucky or least competent supplier. Any natural disaster you care to name has happened to our suppliers. A supplier had a factory burn down. An earthquake. A tsunami. Massive hail. A tornado. A ship sank. A shoot-out at the Mexican border. I'm not kidding. That delayed trunk carpet."
> — Elon Musk, *The Book of Elon* (Chapter: Attack the Constraint, in "We Must Make Stuff")

## What this skill captures

Your real throughput is not set by your suppliers' promised lead times. It is set by the worst one — the least lucky, the least competent — on the worst week of the year. Musk's lesson from Tesla is blunt: "The production line will move as fast as the slowest and least lucky part of the entire production line. Let's say there are ten thousand things that have to go right for production to work. If you have 9,999 things working and one that isn't, that sets the production rate." Every external dependency is a probability distribution with a fat tail, not a deadline.

This skill forces the user to stop planning off supplier means and start planning off supplier tails. The value: you stop being surprised by "freak" supplier failures (they are not freak — they are the base rate at scale), you stop building roadmaps that assume every vendor hits their date, and you correctly diagnose when your throughput is gated by external variance — which is the precondition for the harder fix (vertical integration, covered by the sibling skill).

## When to use this skill

- Auditing a supply chain or third-party dependency graph for fragility.
- Choosing between vendors and the debate has collapsed to "who is cheapest" or "who promises the shortest lead time".
- A roadmap or production plan is being built on top of supplier-promised dates with no variance buffer.
- A postmortem keeps citing "bad luck" — a fire, an outage, a port strike, a regional disaster — as if it were a one-off.
- A team is single-sourced on a critical input and the conversation is "but they're reliable".
- Capacity planning where every line item assumes the supplier hits their P50.

## The how-to

1. **List every external dependency on the critical path.** Not just physical suppliers — APIs, cloud regions, data vendors, contractors, model providers, anyone whose failure stops your line.
   > "The production line will move as fast as the slowest and least lucky part of the entire production line."
   > — *The Book of Elon*
   The point is exhaustiveness. If you missed it on the list, you cannot reason about it.

2. **For each dependency, write down the realized tail, not the promised mean.** What is the worst delay or outage they have actually caused you or a comparable customer in the last 24 months? That number is your real plan input.
   > "Things move as fast as the least lucky or least competent supplier."
   > — *The Book of Elon*
   Promised lead time is marketing. Realized P95 is engineering.

3. **Enumerate the disaster classes that have already happened at scale.** Fire, flood, earthquake, tsunami, hail, tornado, sunk ship, port closure, border incident, regulatory shutdown, cyberattack, key-person loss, bankruptcy. Assume each one will hit some supplier in your chain within the planning horizon.
   > "Any natural disaster you care to name has happened to our suppliers. A supplier had a factory burn down. An earthquake. A tsunami. Massive hail. A tornado. A ship sank. A shoot-out at the Mexican border. I'm not kidding. That delayed trunk carpet."
   > — *The Book of Elon*
   At ten thousand parts, "freak" events are the base rate. Plan accordingly.

4. **Rank dependencies by competence floor, not by best-case performance.** A vendor whose median is great but whose 10th-percentile day is a catastrophe is worse than a steady mediocre one. Score on tail behavior.
   > "Things move as fast as the least lucky or least competent supplier."
   > — *The Book of Elon*
   The least-competent supplier in your chain is the one setting your rate. Find them.

5. **Stress-test the plan by deleting your single worst dependency for a quarter.** If the company stops, that vendor is your real bottleneck — not whatever the Gantt chart says. Mark it.
   > "If you have 9,999 things working and one that isn't, that sets the production rate."
   > — *The Book of Elon*
   One broken link sets the throughput of the entire system. The diagnostic is to ask which link.

6. **Name the diagnosis explicitly and hand it to the remediation.** This skill ends at "your throughput is gated by external supplier variance on dependencies X, Y, Z". The remediation — second-sourcing, buffer inventory, or vertical integration — is a separate decision (see the sibling `vertical-integration-when-blocked` skill).

## Common failure modes

- **Planning off the supplier's promised mean.** The vendor said 6 weeks, so the Gantt chart says 6 weeks. The realized distribution says 6–22 weeks. You will miss.
- **Treating tail events as "bad luck" instead of base rate.** At ten thousand parts, a fire, a flood, or a sunk ship somewhere in your chain is not an outlier — it is Tuesday. Postmortems that blame luck are skipping the diagnosis.
- **Single-sourcing because the vendor is "reliable".** Reliable until they aren't. Reliability is a sample, not a guarantee. The first time the sample fails, your line stops.
- **Shopping suppliers on price or promised lead time.** Both are means. Your throughput is set by the tail. Score variance and competence floor, not headline numbers.
- **Conflating diagnosis with cure.** Recognising "we're supplier-gated" is step one. Jumping straight to "let's build it ourselves" without first proving the dependency is on the critical path wastes engineering on the wrong constraint.

## When NOT to use this skill

- The bottleneck is internal — your own team, your own code, your own factory. Use `attack-the-constraint` instead.
- You have already diagnosed the supplier as the constraint and are ready to debate build-vs-buy or in-housing. Use `vertical-integration-when-blocked` for the remediation.
- The dependency is genuinely non-critical — its failure does not stop the line. Do not over-engineer resilience for things off the critical path.
- Early-stage prototyping where you are not yet at production volume. Supplier variance does not bite at one-off scale; it bites at ramp.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Attack the Constraint (supplier subsection)" (in "We Must Make Stuff").