ExpertsFMJon McNeill: The Algorithm Behind Tesla and SpaceX, Why Automation Should Come Last, and Setting Unrealistic Goals
In Good Company with Nicolai Tangen · September 16, 2026
5 Selected Lessons:
heuristic · 2 reasoning_pattern · 2 framework · 1
The Five-Step Innovation Algorithm (Question, Delete, Simplify, Accelerate, Automate)
Source
In Good Company with Nicolai Tangen — Jon McNeill: The Algorithm Behind Tesla and SpaceX, Why Automation Should Come Last, and Setting Unrealistic Goals (September 16, 2026) · at 0:00 ▸ · at 4:31 ▸ · at 8:26 ▸ · at 10:35 ▸ · at 14:01 ▸ · at 16:20 ▸ · at 19:12 ▸
When this applies
when trying to innovate or fix any business process, product, or workflow
The takeaway
Strip a process down to its irreducible core before adding speed or technology, because technology amplifies whatever process it's layered onto, good or bad.
Why it works
Automating or speeding up a flawed process locks in its flaws and makes them expensive and hard to remove, so removing waste and proving the process manually first ensures what you scale is actually sound.
One level up
Sequence interventions so that irreversible or costly commitments (automation, scale, capital) come only after reversible, cheap experiments (manual testing) have validated the design.
Where it stops holding
This stops working when the process underlying assumptions genuinely are fixed by law, physics, or safety, or when speed/automation is applied only after the process is already proven — applying the steps out of order is what causes failure.
Detail
procedure:
- 1. Question every requirement — identify untouched assumptions and test whether they are truly required by law/physics/safety or just habit.
- 2. Delete every step not required — map the process on sticky notes, keep only what the customer pays for.
- 3. Simplify and optimize — run the leaner process manually first before digitizing.
- 4. Accelerate cycle time — speed up the simplified process, which reveals remaining faults; speed yields good+fast+cheap together.
- 5. Automate last — only pour automation onto a process that has been perfected manually, because automation is like concrete that's hard to remove.
benchmarks: {"steps_eliminated":"~90% of steps in a typical process questioned at Tesla","gross_margin_target":"aimed for 30% (Apple-like) vs industry's 10%, achieved 24-28%"}
rationale: Each step builds on validating the prior step manually so that costly, hard-to-reverse investments (automation, scale) are only made on a proven foundation.
In their words
automate last. You've got to perfect the process before you automate. Otherwise, you just might bury yourself. And in that case, we almost did.
Speed as a diagnostic tool, not just an efficiency gain
Source
In Good Company with Nicolai Tangen — Jon McNeill: The Algorithm Behind Tesla and SpaceX, Why Automation Should Come Last, and Setting Unrealistic Goals (September 16, 2026) · at 8:26 ▸ · at 10:35 ▸ · at 19:12 ▸
When this applies
when trying to find hidden flaws in any newly designed process
The takeaway
Deliberately accelerating a process is a diagnostic technique: faults surface first, then get removed, enabling speed and quality and cost to improve together rather than trading off.
Why it works
Pushing a process to run faster exposes weak points (downtime, bottlenecks) that are invisible at low speed, because faults that cause delay become visible and costly once throughput targets are tight.
One level up
Treat stress-testing (via speed, scale, or load) as a discovery tool for weaknesses, not merely a performance goal.
Where it stops holding
This stops working when you accelerate before simplifying/deleting — then you're just reaching a bad outcome faster and more expensively, as happens when AI is bolted onto a flawed process.
Detail
approach: Set an aggressive speed target on an already-simplified process; use the resulting failures to find and eliminate downtime and inefficiency; repeat at higher speed.
signals:
- things sitting idle between process steps (downtime)
- repeated errors revealing where muscle memory/practice is needed
- costs rising instead of falling when speed is added to a bad process
rationale: Good, fast, and cheap are not inherently a trade-off — a truly great, simplified process achieves all three because speed exposes and removes the sources of waste.
In their words
a lot of people say you can't get good, fast, or cheap. Pick two. It turns out that really great process yields good, fast, and cheap.
Weekly compounding drives quantum innovation
Source
In Good Company with Nicolai Tangen — Jon McNeill: The Algorithm Behind Tesla and SpaceX, Why Automation Should Come Last, and Setting Unrealistic Goals (September 16, 2026) · at 19:12 ▸
When this applies
when trying to achieve a breakthrough (not just incremental progress) in any complex capability
The takeaway
Quantum-seeming innovation is often the compounded product of disciplined, frequent (e.g., weekly), leadership-driven incremental progress rather than single flashes of insight.
Why it works
Small percentage gains compounded weekly, under consistent leadership attention, accumulate over time into results that look like discontinuous breakthroughs, even though each individual step was incremental.
One level up
Sustained small cadence-driven gains outcompete sporadic large efforts because compounding dominates over time.
Where it stops holding
This stops working when leadership attention to the weekly cadence lapses, or when the organization lacks mechanisms to capture and retain each week's incremental gain.
Detail
approach: Run a weekly, CEO-driven review cadence demanding a few percent improvement each week.
signals:
- breakthroughs retrospectively explainable as compounded small weekly gains
- examples: landing/catching rockets, achieving 2x industry margins, self-driving cars
rationale: Weekly cadence under direct CEO attention turns incremental change into what looks like quantum leaps.
In their words
It's a weekly process that is driven by the CEO. And this, I think, is, I talk about secret ingredients, one of the things that I think academics, when they study Elon Musk 20 or 30 years from now and say, what made this person such an effective industrialist?
Dumb rule vs. real rule test
Source
In Good Company with Nicolai Tangen — Jon McNeill: The Algorithm Behind Tesla and SpaceX, Why Automation Should Come Last, and Setting Unrealistic Goals (September 16, 2026) · at 4:31 ▸
When this applies
when evaluating whether any rule, form, or requirement is actually necessary
The takeaway
Classify every requirement as either grounded in immutable constraints (law, safety, physics) or as an assumption, and treat all assumptions as deletable until proven otherwise.
Why it works
Many organizational rules persist simply because no one questioned their origin, not because they are legally or physically required; distinguishing the two categories reveals which can be safely deleted.
Where it stops holding
This stops working when the organization cannot clearly verify what is and isn't legally/physically required, risking removal of a genuinely necessary safeguard.
Detail
rule: A requirement is legitimate only if grounded in safety, law, or physics; everything else is 'dumb' until proven otherwise.
threshold: If a lawyer or expert confirms zero of the clauses are legally required, cut to the minimal necessary agreement (e.g., one paragraph instead of 12 pages).
rationale: Removing unnecessary complexity simplifies customer experience and operations without legal risk, since case law already covers the core protections.
In their words
Rules that make sense are, in our world, a requirement of safety, of law, or physics. And those are kind of immutable. So if there's an assumption based on those, a good one. Everything else is in the dumb category until proven otherwise.
Special forces model: short bursts of intensity, not sustained overwork
Source
In Good Company with Nicolai Tangen — Jon McNeill: The Algorithm Behind Tesla and SpaceX, Why Automation Should Come Last, and Setting Unrealistic Goals (September 16, 2026) · at 26:43 ▸
When this applies
when designing a high-performance culture that requires occasional extreme effort without burning people out
The takeaway
Reserve maximum intensity for short, bounded critical missions; maintain normal working rhythm otherwise, so the team doesn't burn out and remains capable of future bursts.
Why it works
Intense effort is only sustainable and high-quality when deployed in short, mission-specific bursts followed by normal-intensity periods, analogous to special forces versus a standing army deployed continuously.
Where it stops holding
This stops working when 'short bursts' become chronic due to poor planning, effectively becoming continuous overwork and causing burnout.
Detail
rule: Treat intense crunch periods as special-forces-style short bursts for key missions, not a continuous operating mode (e.g., normal office hours 8-6, roll a bowling ball through and hit nobody after 7pm).
threshold: Short bursts of all-night/factory-floor work during specific launches, not sustained nightly.
rationale: This design keeps top talent ('best of the best') engaged and prevents burnout while still enabling extraordinary output when needed.
In their words
special forces aren't deployed continuously. They're deployed in short bursts of time for key missions.