do-things-in-parallel — quality + safety report

---
name: do-things-in-parallel
description: Audit any plan, schedule, pipeline, or rollout for serialized dependencies and force gestating work into parallel. Use when the user is doing project planning, timeline estimation, sequencing decisions, pipeline design, multi-step rollouts, vendor/integration coordination, hiring + procurement + buildout planning, or asks "how do we ship this faster", "how do we compress this timeline", "what's the critical path", "why is this taking so long", "should we do X then Y", or presents a Gantt-style sequence. Also use when reviewing any roadmap longer than a few weeks — long timelines are almost always wrong because someone serialized things that could gestate concurrently. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - speed-is-both-offense-and-defense
  - timeline-is-wrong-if-long
  - set-aggressive-timelines
  - break-down-the-impossible
---

# Do Things in Parallel

> "Avoid serialized dependencies. A lot of things have a 'gestation period' and there is nothing you can do to accelerate it. If you can have all those things gestating in parallel, that will substantially accelerate your overall timeline. People tend to serialize too much. Put as many gestating elements in parallel as possible."
> — Elon Musk, *The Book of Elon* (Chapter: Do Things in Parallel)

## What this skill captures

Most timelines are long because someone unnecessarily chained independent work items end-to-end. Many tasks have an irreducible "gestation period" — a vendor lead time, a permit cycle, a hiring loop, a model training run, a legal review, a hardware lead time. You cannot shrink the gestation. You *can* start them all on day one instead of one-after-the-other. The default human tendency is to serialize. The skill is to attack that default and force concurrency wherever the dependency is fake.

Musk's heuristic: **"If a timeline is long, it's wrong."**

## When to use this skill

- User shares a multi-step plan, roadmap, Gantt, or rollout sequence
- User says "first we'll do X, then Y, then Z"
- User asks how to compress, accelerate, or de-risk a schedule
- User is planning a launch, migration, hiring ramp, procurement, integration, or build-out
- User presents a critical path and asks for review
- Any timeline > ~2 weeks where the chain isn't obviously physically forced

## The how-to

1. **Frame in time-risk, not task-risk.** Ask "what is the time risk associated with each item?" — not "what could go wrong". Time is the one thing you cannot replace.
   > "Everything is measured in terms of time. What is the time risk associated with something? The one thing you cannot replace is time."
   > — *The Book of Elon* (Do Things in Parallel)

2. **List every gestating element.** Inventory every item with an irreducible wait: vendor contracts, hiring, legal/compliance, procurement, training runs, permits, certifications, data collection, hardware lead times, third-party integrations.

3. **Mark each dependency as real or fake.** A real dependency means item B literally cannot begin until item A produces an output B consumes. Everything else is a fake dependency — usually a calendar or org-chart artifact ("we'll start hiring after we finalize the design"). Fake dependencies are the entire target.

4. **Start every fake-dependency item on day one.** Kick off contracts, hires, procurement, and integrations *now*, in parallel with design and development. Use the PayPal pattern: software development and back-office deals ran concurrently and landed together.
   > "By doing them all in parallel, it all came together simultaneously. Developing the software and having it ready for the general public coincided with us concluding deals with the outside vendors. All that took about a year."
   > — *The Book of Elon*

5. **Re-derive the timeline from the longest single gestation, not the sum.** New estimated timeline = max(gestation periods of independent items) + the truly serial tail. If your current estimate is much longer than that, you have serialization to delete.

6. **Sanity-check with the heuristic.** Read the compressed timeline aloud. If it still feels long, it's still wrong — find more fake dependencies.
   > "If a timeline is long, it's wrong."
   > — *The Book of Elon*

## Common failure modes

- **Org-chart serialization.** "Team B starts when team A hands off." Almost always avoidable with a spec stub or a parallel embed.
- **Risk-aversion serialization.** "We'll start procurement after we're sure of the design." You eat the lead time twice when the design shifts; instead, start procurement on the most likely design and accept rework cost — it's cheaper than the calendar.
- **Budget-gate serialization.** Waiting for phase-1 approval before kicking off phase-2 long-leads. Pre-authorize the long-lead spend.
- **False causality.** "We need X before Y" — interrogate this; often Y only needs a stub or interface contract from X.
- **Confusing "parallel" with "faster gestation."** Parallelism does not shrink any single item's gestation. It removes the *sum*. Don't try to rush the gestating thing — start it sooner.

## When NOT to use this skill

- Genuinely physical serial dependencies (you can't pour the foundation after framing the house).
- Tiny tasks where coordination overhead exceeds calendar savings.
- Safety-critical sequences where the serialization exists for a regulatory or correctness reason.
- Single-threaded creative work where parallel branches would fragment the artifact.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Do Things in Parallel" (in "Maniacal Urgency").