attack-the-constraint — quality + safety report

---
name: attack-the-constraint
description: Find the single bottleneck slowing everything else and attack it; ignore the rest. Use when the user is debugging a slow system, prioritizing a long list of open issues, asking "why is this taking so long?", "what should I focus on next?", "where should I spend my time?", auditing a supply chain or pipeline, triaging a backlog, planning a sprint, staring at a Gantt chart, or feeling generally stuck on a multi-part project. Also use when the user is shotgun-fixing many small issues at once, optimizing the wrong layer, or treating all open problems as equally urgent. The framework: the system moves as fast as its slowest, least-lucky part — find that one part, attack it relentlessly, and ignore everything else as noise. Trigger eagerly even when the user does not name Musk or the framework.
---

# Attack the Constraint

> "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."
> — Elon Musk, *The Book of Elon* (Chapter: Attack the Constraint)

## What this skill captures

A throughput system — factory, codebase, pipeline, org, ML training run, deploy chain, your own week — has exactly one rate-limiting constraint at any moment. Everything else has slack. Work spent on the non-constraint is wasted: it does not increase throughput, it just creates the illusion of progress. The job is to identify the constraint, attack it until it is no longer the constraint, and then repeat on whatever became the new constraint. The constraint is often boring, unsexy, embarrassing, or "someone else's problem" (a flaky supplier, one slow test, one PM who blocks reviews, a single 200ms DB query). That is precisely why it is the constraint — nobody wanted to deal with it.

It is also stochastic: "things move as fast as the least lucky or least competent supplier." Variance compounds in serial systems. Slack in the wrong place buys you nothing.

## When to use this skill

- User has a long list of open issues and is asking what to do first.
- User says "this is slow" / "this is taking forever" / "we keep missing the date."
- User is debugging system latency or pipeline throughput.
- User is auditing a supply chain, dependency graph, or build pipeline.
- User is doing sprint planning, roadmap prioritization, or quarterly review.
- User is shotgun-optimizing multiple layers simultaneously without measurement.
- User feels stuck on a multi-part project and is asking for a "next step."

## The how-to

1. **Refuse the list. Demand the rate.**
   Ask: "What is the throughput you actually want, and what is the throughput you are getting?" If they cannot state both numbers, that is step zero — measure. Without a rate, "constraint" is meaningless.

2. **Walk the line. Find the one part that sets the rate.**
   Enumerate every stage that work flows through. For each, ask: *if this stage went 10x faster tomorrow, would total throughput go up?* Exactly one answer is "yes, a lot." That is the constraint.
   > "If you have 9,999 things working and one that isn't, that sets the production rate."
   > — *The Book of Elon* (Attack the Constraint)

3. **Attack only the constraint. Treat everything else as noise.**
   Other problems are real. They are also not your problem this week. Working on non-constraints does not move the rate.
   > "Design is overrated, and manufacturing is underrated. There is 1,000 percent, maybe 10,000 percent more work that goes into the production system than the product itself."
   > — *The Book of Elon*

4. **Spend disproportionately. 10x–100x is normal.**
   The fix for the real constraint is usually 10–100x more expensive in effort than fixing a non-constraint. That is correct. Pay it.
   > "We spent ten to one hundred times more effort on designing the manufacturing system than on designing the Raptor engine."
   > — *The Book of Elon*

5. **Plan for bad luck, not just bad design.**
   The constraint is often the least-lucky link, not the least-competent one. A serial system inherits the worst variance of any of its parts.
   > "Things move as fast as the least lucky or least competent supplier. Any natural disaster you care to name has happened to our suppliers."
   > — *The Book of Elon*

6. **Re-measure. The constraint moves.**
   Once you have beaten the old constraint, the rate goes up and a new stage becomes the bottleneck. The list of things to attack changes. Re-walk the line.

## Common failure modes

- **Optimizing the easy stage.** You profiled the function you understand best, not the one on the critical path.
- **Parallel busywork.** Ten people each "improving" a different non-constraint stage. Throughput unchanged.
- **Confusing utilization with throughput.** A stage being 100% busy is not the same as it being the constraint.
- **Refusing the boring constraint.** The real bottleneck is a flaky vendor, a single legacy script, or a person who will not return Slack messages.
- **Treating luck as someone else's problem.** "But our suppliers are fine *right now*." Variance is the constraint even when the mean isn't.
- **Stopping after one fix.** You beat the old constraint and went back to general optimization instead of finding the new one.

## When NOT to use this skill

- The system is not a throughput system (e.g. a one-shot creative decision, a negotiation, a policy choice). Constraint logic assumes flow.
- You genuinely do not know what the desired rate is. Define the goal first.
- You are early in research / exploration where the bottleneck is "we don't know what to build." That is an epistemic problem.
- The "constraint" you identified is a person, and the right move is replacing or unblocking them, not "attacking" the role.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Attack the Constraint" (in "We Must Make Stuff"). Pages ~156–157.