The Algorithm

One-sentence summary: Exponential growth comes not from working harder inside an existing process but from relentlessly asking "Why?" of every rule, deleting every step the customer does not pay for, simplifying and accelerating what survives, and only then automating, all held together by a culture of urgency, accountability, and leaders who live inside their own product.

Key Ideas

1. The Algorithm Is a Sequence, and the Order Is the Point

Jon McNeill, president of Tesla from 2015 to 2018, describes the operating system Elon Musk called "the Algorithm": five steps applied in strict order to any process, product, or business. Question every requirement. Delete every possible step. Simplify and optimize what remains. Accelerate cycle time. Automate last. McNeill's central argument is that the sequence matters more than any single step. Most companies run it backwards: they buy software or robots to speed up a process nobody has questioned, which cements waste in place and makes it expensive to remove later.

The book's most vivid illustration of the wrong order is Tesla's own near-death experience. In 2017 Musk built a heavily automated Model 3 line, the "Alien Dreadnought," before the assembly process had been questioned, trimmed, or simplified. The robots could not synchronize, production stalled at close to zero, and the company edged toward default. The line was torn out and rebuilt by hand, then re-automated only once every motion was understood. McNeill frames this not as a failure of automation but as a failure of sequence.

The steps overlap in practice. Almost every case study in the book touches three or four of them at once, because questioning a requirement usually reveals a step to delete, and deleting steps usually simplifies what is left. McNeill treats the first three steps as enablers that put the pieces in place, and the last two as the moment "revenue and growth take flight."

Practical application: Before approving any automation, optimization, or tooling project, ask which step of the sequence the team is on. If nobody has yet listed every step in the process and challenged each requirement behind it, the project is premature. Run steps one through three first, even if only for an afternoon.

2. Question Every Requirement: Most Rules Are Conventions Wearing a Uniform

Step one rests on an observation McNeill makes repeatedly: in a large organization, good ideas become rules, and rules become requirements. When Tesla investigated a constraint, it usually turned out to be a recommendation, a custom, a supplier's best-practice note, or a bank lawyer's precaution rather than a law. Laws had to be obeyed, especially the laws of physics, but most "requirements" came from nowhere in particular and could be changed or ignored.

The case studies show the range. Musk refused the conventional wisdom that a foreign carmaker in China needed a 50/50 joint venture, kept asking, and won a 100 percent-owned Shanghai factory. Engineer Doug Field questioned the century-old assumption that a car plant needs a body shop welding hundreds of stamped parts, which led to gigacasting the chassis and cutting roughly 300 parts to fewer than ten. A stack of state-by-state loan paperwork turned out to be almost entirely bank lawyers protecting the bank, not regulators, which opened the door to a one-click lease document. And at McNeill's incubator DVx Ventures, an outrageous one-size-fits-all cyber-insurance premium for Lululemon exposed a market that had never priced its customers individually, spawning the startup Cork.

McNeill adds two useful signals. First, "impossible" often just means "unsolved," and consensus that something cannot be done is where breakthroughs hide. Second, any requirement or price that applies to everyone identically is a flag: it means nobody has done the work to understand the customers, and the market is ripe for someone who will.

Practical application: Take one process you own and list every rule it obeys. For each, write down who imposed it and what would happen if it were broken. Sort into three piles: law, physics, and everything else. The third pile is your opportunity list. Start with the rule that costs the most money.

3. Delete Every Possible Step: Circle What the Customer Does Not Pay For

Step two has a concrete technique. McNeill has a team write out every step in a process, then circle each one the customer does not pay for. Rechecking accounting, performance reviews, internal handoffs, approvals, and status meetings all get circled. Then cut hard, harder than feels safe. His rule of thumb is that about 10 percent of deleted steps will need to be reinstated, and that is the point: by going slightly too far, you find where the real limit is instead of guessing at it from the safe side.

The flagship example is Tesla's online car purchase, which took 64 clicks. McNeill set a stretch goal of ten. Getting there required challenging the company's sacred made-to-order model, since thousands of configuration options were what generated the clicks. The team collapsed 300,000-plus combinations into two packages. Conversion rose because customers were no longer paralyzed by choice, and manufacturing got simpler as a side effect. The final flow was 12 clicks. The same logic drove the Hurricane Irma decision, when an engineer pushed an over-the-air software update to unlock extra battery range for owners fleeing Florida without waiting for approval.

That last story introduces the cultural condition that makes deletion safe: freedom to improvise. Tesla's working rule was that people could act without sign-off as long as they did not hurt anyone, break the law, or put millions of dollars at risk. Approval steps exist because leaders do not trust the people doing the work. Restore the trust and the steps can go.

Practical application: Map one customer-facing flow end to end and count the steps. Set a target of cutting it by at least half, not 10 or 20 percent, so the team is forced to question the structure rather than trim the edges. Cut, ship, and watch what actually breaks. Reinstate only the steps that cause real damage.

4. Simplify and Optimize: Replace Accretion With a Single Idea

Step three attacks what McNeill calls accretion: the way training manuals, checklists, and procedures grow because humans can imagine endless scenarios and add a rule for each. Tesla's new-hire training had swollen to a full month of videos, quizzes, and reading. McNeill's stretch goal was two hours. The team's answer was more radical: replace the entire regime with a single aspirational sentence, "Be so great that they'll talk about you at dinner."

The sentence worked because it shifted employees from fulfilling requirements to solving problems for a specific human in front of them. McNeill tells the story of a Florida service manager who, guided only by that line, drove a stranded couple to the hospital for the birth of their child, then stocked their house with groceries for the grandparents watching the kids before dropping off a loaner. Asked why, the manager said: you asked us to make them talk about us at dinner. The stories spread by word of mouth, which mattered for a company spending nothing on advertising.

McNeill draws a general lesson about what he calls the double bonus. One radical simplification (cut training to 10 percent) led to a second (eliminate training entirely). Innovators, in his telling, pursue "better, not best," and every so often a series of small improvements tips over into a reinvention. The same chapter reinvents vehicle delivery, replacing an hour-long white-glove handover with a self-serve process so a 40-person team working 12-hour days could keep up with 200 cars a day.

Practical application: Find the longest document your team maintains, whether a training deck, SOP, or checklist. Ask what single outcome it is trying to produce. Write that outcome as one sentence a new hire could act on without reading the document. Test whether the sentence plus on-the-job learning gets a better result than the document did.

5. Accelerate Cycle Time: Visibility Is the Prerequisite for Speed

Step four is about squeezing time out of a process that has already been questioned, trimmed, and simplified. McNeill's main example is Tesla's sales and operations planning, which in 2015 ran on Excel spreadsheets traded in a Monday afternoon meeting where manufacturing, sales, and supply chain yelled at one another with different numbers. Nobody could see the whole system, so cars were built in ones and twos, the wrong vehicles went to the wrong countries, and quarterly forecasts were routinely missed.

A three-person team led by Neal Suidan built the Vehicle Plan, a single real-time view of every constraint from the supply chain through the factory to demand forecasts in hundreds of local markets. The first version ran on a laptop that crashed constantly. It still let Tesla scale Model 3 production 25-fold, from 20,000 units a quarter to half a million, while cutting car-production cycle time from 14 days to under six. For the first time the company hit its Wall Street projections. The rollout to Shanghai in 2019 landed weeks before COVID-19 scrambled every supply chain, and the tool let Tesla respond to shocks that would have been invisible on spreadsheets.

McNeill's point is that speed does not come from pushing people harder. It comes from everyone working from the same numbers so that the constraint is visible and decisions can be made where the work happens. He explicitly borrows from Goldratt's Theory of Constraints: a process cannot run faster than its slowest step, and inventory piling up in front of a station is how you find it.

Practical application: Before trying to speed up a process, ask whether every team involved is looking at the same live data. If planning still happens by reconciling separate spreadsheets in a meeting, build the shared view first. Then find the step with the biggest queue in front of it and work only on that.

6. Automate Last: Do It by Hand Until You Understand Every Motion

Step five is the one smart people most want to skip. McNeill states the rule plainly: do not automate until you know exactly what you are doing, every motion, every turn, the pathway of every component. Only when the process flowchart has been shorn to its simplest form should you consider inviting in a robot or a line of code. Software written before the system is simplified becomes very hard to change, and the people who wrote it will resist throwing it away.

Beyond the Alien Dreadnought, McNeill points to companies that got the order right. DoorDash's founders scanned local menus, put them on a website with a Google Voice number, and delivered orders by hand until they understood the restaurant and delivery process, then automated. At DVx, ventures run manually first as a matter of policy, using the manual phase to discover which steps deserve to exist before anyone writes code to perform them.

The principle is counterintuitive because automation feels like progress and manual work feels like falling behind. McNeill argues the opposite: manual operation is the cheapest possible way to learn what the process actually is, and every hour spent there is an hour not spent rewriting code.

Practical application: When a team proposes automating a workflow, ask them to run it by hand for a defined period and document every step and exception they hit. Use that log, not the original process description, as the automation spec. Expect the log to be shorter than the description.

7. The Culture That Makes It Stick: Whole Product, Weekly Cadence, Dog Food

Part II of the book covers three practices that keep the Algorithm running after the initial burst. The first is to define the product as the customer's entire experience. At Tesla, the charging network is part of the car, because a beautiful drive up the coast is ruined by a dead battery. The same lens produced Tesla Insurance, which removed the miserable step of shopping for coverage before driving off the lot, and mobile service, which let senior mechanics fix 80 percent of cars in under 20 minutes in the customer's driveway.

The second is urgency and accountability, embodied in what Tesla called the weekly cadence. Every Tuesday, small teams reported to Musk directly on the two or three most pressing problems. McNeill stresses that the mechanism is not the meeting; it is that the CEO understood the details well enough to have a real conversation, and that a team with no progress often saw a leadership change. He has carried the practice into every venture since as weekly one-on-ones with a single agenda: what milestone are we working toward, and what is in the way?

The third is eating your own dog food. McNeill got his Tesla job partly because Musk had never test-driven his own cars as a customer and never received the follow-up messages that did not exist. Sam Walton walked his own store aisles and brought doughnuts to the truckers. GM's Mary Barra removed the ignition button from the electric Lyriq after leaders drove it and felt the vestige. McNeill's rule: any time a customer needs YouTube to figure out a feature, the design needs a tweak. Leaders who live inside their product create a fast, unfiltered feedback loop, and the habit spreads downward once the team notices the boss is doing it.

Practical application: Buy your own product through the same channel your customers use, this week, without announcing it internally. Write down every moment of friction. Bring the list to a standing weekly review where the owners of the top two or three items report progress to you directly.

Frameworks and Models

The Algorithm (Five Steps, Strict Order)

1. QUESTION every requirement
        ↓
2. DELETE every possible step
        ↓
3. SIMPLIFY and optimize what remains
        ↓
4. ACCELERATE cycle time
        ↓
5. AUTOMATE last

The Circle Test for Deletion

• Step 1: Write every step in the process, in order, with no summarizing.
• Step 2: Circle each step the customer does not pay for (approvals, rechecks, internal handoffs, reviews).
• Step 3: Delete every circled step, deliberately overshooting.
• Step 4: Ship and observe. Expect roughly 10 percent of deletions to need reinstating.
• Step 5: The reinstated steps mark the true limit. Everything else stays gone.

Three Conditions for Freedom to Improvise

People may act without approval as long as the action does not:

1. Hurt anyone.
2. Break the law.
3. Put millions of dollars at risk.

Leaders must back people up when an improvised decision goes wrong. Occasional failures are evidence the culture is working.

The Weekly Cadence

• Scope: The two or three most pressing problems in the business, not a general status update.
• Owners: Small named teams, each with a firm goal and a deadline.
• Audience: The CEO or top leader, who understands the problem well enough to contribute to the solution.
• Rhythm: Same day every week. At DVx this becomes a weekly one-on-one with two questions: what milestone are we working toward, and what is standing in the way?
• Consequence: Progress is expected every week. No progress triggers a change of owner, not an extension.

Requirement Triage

Key Quotes

"Question every requirement. Delete every possible step in a process. Simplify and optimize. Accelerate cycle time. Automate last." — Jon McNeill, stating Musk's five steps

"When you have a large organization, things that started out as good ideas can become rules, and then those rules can become requirements." — Jon McNeill

"Maybe 10 percent of the steps actually need to be reinstated. But by going a bit too far, we establish where the limit is." — Jon McNeill

"Be so great that they'll talk about you at dinner." — Tesla's replacement for a month of customer-service training

"Don't automate until you know exactly what you're doing—every motion, every turn, the pathway of every component." — Jon McNeill

"Anytime a customer needs YouTube to find a switch or understand how something works, the design needs a tweak." — Jon McNeill

Connections with Other Books

• thinking-in-systems: Meadows gives the theoretical grounding for McNeill's practical instinct that a process is a system with a constraint, and that pushing on the wrong lever produces nothing. The Vehicle Plan chapter is essentially an argument for making system state visible before intervening.
• the-checklist-manifesto: Gawande argues for adding structure; McNeill argues for deleting it. The two are compatible if read carefully: Gawande's checklists are short and target known failure points, which is exactly what survives McNeill's circle test. The disagreement is about accretion, and McNeill is the corrective.
• the-lean-startup: Ries's build-measure-learn loop and McNeill's "automate last" reach the same conclusion from different directions. Both insist on running the manual, cheap version first to learn what the product or process actually is before investing in scale.
• essentialism: McKeown's discipline of eliminating the non-essential is the personal-productivity version of step two. McNeill applies the same logic to organizations and adds a concrete test (does the customer pay for it?) that McKeown leaves implicit.
• the-hard-thing-about-hard-things: Horowitz describes the emotional reality of running a company through crisis; McNeill's Production Hell and near-default chapters read as a companion case study, with the Algorithm as the operating method that got Tesla out.
• thinking-fast-and-slow: McNeill cites Kahneman directly when explaining why requirements go unquestioned. Heuristics that were once true harden into rules, and the first step of the Algorithm is a deliberate practice for catching them.
• the-innovators-dilemma: Christensen explains why incumbents cannot delete their own processes; McNeill's GM chapters, with Mary Barra simplifying and setting stretch goals inside a century-old company, are a rare account of an incumbent actually doing it.

When to Use This Knowledge

• When the user is streamlining any process (sales flow, onboarding, approvals, manufacturing, fulfillment) and needs a method for deciding what to cut.
• When someone justifies a step with "that's a requirement" or "we've always done it that way" and the user wants to test whether the rule is real.
• When a team is proposing automation, new software, or robotics and the user needs to judge whether the underlying process is ready for it.
• When the user is setting goals and wants to understand why an outrageous stretch target (10x, 20x, cut to 10 percent) forces different thinking than a 15 percent improvement.
• When the discussion involves bottlenecks, cycle time, or why a process cannot go faster despite more effort.
• When the user is designing an executive review rhythm or accountability system and wants a model for a weekly cadence that actually drives progress.
• When leaders are relying on surveys and dashboards to understand customer experience and the user wants an argument for firsthand use of the product instead.
• When the user asks about Elon Musk's operating methods at Tesla or SpaceX and wants a practitioner's account rather than a biography.
• When training materials, SOPs, or documentation have grown unmanageable and the user is deciding whether to trim them or replace them with a simpler organizing idea.