Avoid Serialized Dependencies

Maximum risk, minimum timeline

The doctrine follows directly from pricing decisions against Time Is the Only Currency, the view that a day of delay costs future revenue rather than present cost. Eric Jorgenson uses PayPal to illustrate the default alternative: regulatory clearance, partner integrations, and product build could have run one after another, each stage de-risking the next, on the reasonable-sounding logic that building a product before knowing it would be legal wastes money.¹ Done that way, the project runs three years. Elon Musk ran all three simultaneously instead, on Jorgenson's phrase, maximum risk, minimum timeline, and launched in a year.

What that costs is real: had clearance failed, the product spend would have been wasted. The claim is not that the risk disappears, it is that the risk is denominated in a currency that can be replaced, money and effort, while the sequential alternative spends a currency that cannot be replaced, years. The same habit shows up as a deliberately compressed deadline: PayPal's first launch date was set for the Saturday of Thanksgiving weekend over the team's objection, on the stated grounds of "because I said."¹

At company scale

The pattern repeats one level up. Starting SpaceX and Tesla at the same time is the identical bet: two capital-hungry hardware companies in unrelated industries, both requiring full attention, both likely to fail, run in parallel because both needed to exist rather than queued behind whichever succeeded first.

The constraint on the doctrine

Jorgenson raises the counterargument himself, in Warren Buffett's form: you cannot get a baby in one month by getting nine women pregnant.¹ Some processes have an irreducible serial duration that no amount of parallel resourcing compresses. The distinction the doctrine actually rests on is that most organizational dependencies are informational rather than physical. Waiting for regulatory clearance before building is not a gestation period, it is a decision to withhold effort under uncertainty dressed up as a technical constraint, and almost everything on a project plan is negotiable once that distinction is drawn. This is the same discipline behind Bottleneck of the Bottleneck, aimed at a schedule instead of a supply chain.

Open question

Nobody counts the failures. The maximum-risk approach is described only in the companies where the bet paid off, and the same policy run with less capital, or against a less permissive regulator, produces a written-off product build and no story anyone tells afterward. The doctrine also assumes a founder who can hold several full workstreams in one head at once, which is the same rare property that makes the rest of the approach work and is not separately available to whoever tries to copy it.