The Algorithm applied: why some unattended jobs finish the work

I applied Jon McNeill’s five-step sequence from The Algorithm to six recurring jobs in Command. The strongest opened 31 remediation pull requests in 30 days, and 29 had merged. Each one went through review, CI, and a gate that would not merge it until the review was clean and every review thread had an answer.

McNeill was President of Tesla, then COO of Lyft. The book’s spine is the sequence Musk runs at Tesla and SpaceX: question every requirement, delete every step you can, simplify, accelerate cycle time, and automate last. Applying that order showed what turned accurate automation into finished work in my own system.

Three of Command’s six recurring jobs produced durable output. One could not be measured, one was open at its acting end by design, and one was failing. The jobs that finished work did more than compute the right answer: they carried it through to a dated artifact or pull request.

The weaker handoffs are useful evidence because they mark that boundary. On 21 August, the two remediation pull requests that had not merged were still open behind unanswered review threads; both merged on 23 August. A cleanup job was holding 63 items for a person who did not exist, and 10 of 45 registered automatic mechanisms said in their own records that nothing acted on what they produced.

I went in with the opposite theory, that I’d built machinery around steps I should have deleted instead. The measurements didn’t support it. The useful distinction was whether an automated job finished the work or stopped after noticing what needed to happen next.

The five steps, in order

1. Question every requirement.
2. Delete every step you can.
3. Simplify and optimize what’s left.
4. Accelerate cycle time.
5. Automate.

Musk’s formulation predates the book. Walter Isaacson reported it in his 2023 biography, and McNeill’s contribution is a working manager’s account of running it, first at Tesla and then elsewhere.

The ordering is the load-bearing part, and it’s the part that gets dropped. Every public statement of the steps I checked puts them in this order, and more than one says the order isn’t optional. The reason is mechanical rather than philosophical. Machinery is committed. Once a job exists around a step, the job becomes a reason the step exists, so automating early doesn’t only optimize the wrong thing, it makes the wrong thing harder to remove later. Isaacson quotes Musk’s gloss on step 3, and it’s the cleanest statement of the failure: the classic engineering error is to “optimize a thing that should not exist.”

The system I scored is Command, the operator I run my projects through. It carries 45 registered automatic mechanisms and 29 scheduled jobs, 18 of them enabled and 14 recurring. Six of those recurring jobs are Command’s own; the rest serve other projects and are out of scope here. I counted all of this on 21 August, in one sitting, off the repository and the scheduler rather than off memory. That first pass read 44 mechanisms, but main had 45 after #632 added the forty-fifth card that evening. I either read before it landed or the working copy was one commit stale, and the committed record cannot settle which. I use 45 below.

The jobs that act are fine

The best of the six is a tick that fires every four hours, picks one defect off Command’s own backlog, fixes it, and opens a pull request. Over 30 days it had opened 31 pull requests. 29 had merged, 2 were still open, and nothing had been closed. Of the 20 that cite an issue, 15 closed it. The open pair were stuck behind unanswered review threads, further down. Both later merged on 23 August.

Two more clear the bar on durable output. A daily letter wrote 24 times in a 29-day window, 22 of them landing as merged pull requests. A nightly digest produced 23 ingest commits in 30 nights.

Scored honestly, Command’s own six recurring jobs come out at three producing real dated output, one I could not measure at all, one deliberately left open at its acting end by my own ruling, and one failing. Three of six, not four; I miscounted the first time by including a job that belongs to a different project.

Keep it in proportion. Across the same window Command merged 293 pull requests in total, and the two scheduled jobs whose output I can attribute by branch prefix account for 51 of them, about 17%. The jobs are a real contributor and a minority one.

Where they stop instead

Same shape every time. The measuring works, the writing-down works, and the handoff at the end goes to a person who was never named.

Two of those are worth walking through properly, because the compressed version makes them sound like statistics and they are not.

The day my best job did nothing, four times

The four-hourly tick is the strongest thing in the inventory. It is also the one I can show failing for an entire day with nobody noticing, because it happened while I was writing this.

My main working copy of Command was sitting on a branch called desk/20260820-where-the-work-went, left there by a session that finished and moved on. Command’s own rules name that exact state as the one that silently stops every scheduled job from reading current code. It had happened once before, on 4 August, and nothing caught it then either.

The tick writes a run record every time it fires. Here is that day, four firings, all of them halted at the preconditions before claiming any work:

• 00:02. Halted. Reason recorded: checkout-parked.
• 08:41. Halted, and noted in the record as the second consecutive.
• 12:01. Halted. The record’s closing line says clearing this needs the Owner, or an attended session, to return that checkout to main.
• 16:02. Skipped outright. The blocker, it says, is the Owner’s checkout, which only he can move.

Zero items claimed. Zero shipped. The backlog untouched for a day by the one job that drains it.

The field I keep coming back to is the escalation. On all four firings it reads already-open. An issue already existed, so no new one was filed, so nothing got louder. The fourth failure was quieter than the first.

Read that back and nothing in it is broken. The job detected a real blocker. It named the blocker correctly. It wrote down, in plain language, who needed to clear it. It declined to file a duplicate issue, which is the right call. Then it stopped, and did the same thing three more times.

The fix was git checkout main. It took about two seconds once I actually looked. Nobody looked for twenty-four hours, and the only reason anyone looked at all is that I was measuring something else and tripped over it.

Eighty-three seconds

Two pull requests sat finished for a day and a half. Both mergeable, both green, both carrying a signed review verdict pinned to the exact commit at their head. Nothing was wrong with either.

The auto-merge gate had evaluated both and declined, and it printed why:

declined: 1 unanswered inline review thread(s)
declined: 2 unanswered inline review thread(s)

The gate is right. An unanswered review thread is a real reason to hold a merge. What is missing is anything at all that reads the refusal.

Then I looked at the clock on one of them. The job that opened the pull request posted its own review verdict at 03:13:55Z and exited. The external reviewer posted the thread that blocked it at 03:15:18Z.

Eighty-three seconds.

The job was not ignoring that thread. The thread did not exist yet. By the time there was something to answer, the only thing that could have answered it had finished and gone.

Across every open pull request there were four unanswered threads, spread over three of them. Sort those by who opened the pull request and the split is clean:

• Opened by an unattended job: three of three carried an unanswered thread.
• Opened by a session I was sitting in: none of three did.

Every one of the four threads was written by an automated reviewer. One machine writes findings, a second machine correctly refuses to merge past them, and nothing closes that loop unless I happen to be in the room.

The other two, briefly

The weekly cleanup of leftover working copies. Every background session gets its own disposable copy of the repository and leaves it behind. Rather than question that, I built a weekly job to sweep up after it. Run read-only, its verdict was degraded: of the 63 items, 35 are held and 28 are orphaned husks git no longer tracks, none were rescued, and no escalations were raised. An audit on 8 August found the same job looking at 18 copies and removing zero, called that the headline fix, and fixed it. Thirteen days later it is looking at 63.

The registry itself. Of the 45 registered mechanisms, 33 declare a known gap in their own record. Ten state outright that nothing acts on what they produce, in wording like “report-only means nothing chases” and “no actuator”. One of those ten is deliberate: the nightly operations shift, monitor-only by my own ruling. Six state that nothing alarms when they fail silently. Three are dormant or have never fired. Those last two counts came from the original 44-card read and were not re-derived at 45, so both are lower bounds; the forty-fifth card is an explicit candidate for each. And exactly one of the 45 records anything watching whether it still works.

None of this is a concealment problem. Every gap above is already documented by Command, in Command’s own words, usually more harshly than I’d have put it. An audit I ran on 8 August had already named the shape: writing a note for a person to read later is not an actuator, it’s a sensor with extra steps.

The rule I’d apply

Take every mechanism that produces a “someone should look at this” output. Write one of exactly two things into its record: the name of the specific mechanism or session that consumes its output, or RETIRED with a date. No third option. If neither can be written, that is the answer.

Musk’s step 1 says a requirement must arrive attached to the name of a person, never a department. The same test works on actuators, and it’s cheap here because the honest gap text is already sitting in the registry. The work is deciding, not discovering.

Here’s the sentence I expect an argument about: a job that finds a real problem and writes it down, with nobody named to act on it, is worse than not running that job at all.

The strongest counter is that it costs almost nothing to run and the record is there when somebody does look, so it’s free optionality, and turning it off trades a small cost for a real loss. I think that’s wrong on the cost side rather than the value side. An accumulating queue nobody drains is not neutral. It makes the next reader’s search worse, it makes “we have a check for that” true and useless at the same time, and it converts a known gap into a documented one, which feels like progress. The sweep is the proof: it went from 18 items to 63 across the exact 13 days in which its headline defect was declared fixed, and its removal rate never left zero.

The failure in the other direction is real too. Retiring a mechanism whose output nobody currently reads throws away the sensor along with the missing actuator, and some of those sensors are cheap insurance against a rare, expensive failure. That’s why the rule allows a name as well as a date. If you can name the consumer, keep it. The rule exists to stop the third answer, which is the status quo.

Where this isn’t the defect

A loop that ends at a person on purpose is a different thing, and I don’t want the rule above used to flatten it.

Command’s nightly operations shift has been monitor-only since 8 August by my explicit ruling, and its own card records the loop as open at its acting end for nine of eleven checks, by decision. Somebody looked at it, decided a human should stay in that particular gap, and wrote down that they’d decided, which is what the rule asks for.

The same goes for the irreplaceable end of any pipeline. Some acts should stop at a person: the send, the merge of something consequential, the call. Automating up to that boundary and stopping is correct. Automating up to a boundary you never marked is the defect.

What I can’t claim

The attended-versus-unattended split is three to zero on six pull requests. Smoothed, that’s a confidence of 0.60, which is a pattern emerging and not a validated finding. The structural explanation is plausible, since a session I’m sitting in is still there when the review lands and a scheduled job has already exited, but the sample is six.

Everything here is a single-day snapshot of one machine, taken on 21 August 2026. The working-copy and directory counts describe that machine at that moment and aren’t reproducible from the repository alone. I did not read session logs, so the behavior I describe rests on repository artifacts: run records, pull requests, commits.

I also haven’t shipped the fix. Nothing above tests whether naming the consumer actually moves anything. The two numbers to watch are unanswered review threads across open pull requests, which was 4, and merged remediation pull requests per day, which was 1.34. If the diagnosis is right the first goes to zero and the second rises. If neither moves in a week, I’m wrong about where the constraint is.

One last one, about the book rather than my system. The jacket says the framework took Tesla from $2B to $20B in 30 months during McNeill’s tenure, and I couldn’t make that reconcile against Tesla’s annual filings. He joined in 2015 and left in February 2018; reported revenue across that span went from $4.05B to $11.76B. The $2B endpoint is fiscal 2013, two years before he arrived, and the $20B endpoint is fiscal 2018, the year he left. That’s five calendar years, not thirty months. The book may scope the figure to a business line or a run rate I can’t see from outside, so I’m not calling it wrong. I couldn’t reproduce it, and I’d rather say that than repeat it.

What I fixed, and what I haven’t

Three things are actually done.

The parked working copy is back on main and the tick’s preconditions pass again. How that happened matters more than that it happened: I noticed it while measuring something else entirely. None of the machinery whose job it was to catch that state caught it. And unblocked is not the same as producing. It has opened no new pull requests since.

Two fact-checkers on my decision board are running again. They had been dead over a key-name mismatch. The board asserted openPrsFleetWide and prsLandedToday, the probes registered as openPrs and landedToday, nothing matched, and both were quietly filed as unverifiable. One of four headline numbers was being checked. Three of four are now. On the first run after the fix they caught two live errors, one of them mine. The fix itself had already been written and reviewed and was sitting on an unmerged branch, which is the same defect as everything else here.

A re-entry brief now fires on its own when I come back after being away, covering only what changed while I was gone. That one is built to the rule above: a handoff to a named person that doesn’t wait for the person to ask for it.

Three more are specified and not built.

• Give every “someone should look at this” output a named actor or retire it. For the ten cards whose own records say nothing consumes them, write a name or RETIRED with a date. No third option. Lowest effort, highest leverage.
• Make the four-hourly tick answer its own previously declined pull requests before it claims new work. That is the direct fix for the failure that left those two stuck.
• Inventory the orphaned husks before deleting any of them.

Which leaves the obvious thing. On 21 August, those two pull requests were still open. They had been sitting a day and a half when I measured. Both merged on 23 August, while this post was still a draft. That resolution changes the state, not the diagnosis: the gate declined them correctly, the decline reached nobody, and writing all of this down had not moved either one at the snapshot. The fix for the missing consumer is specified and it isn’t built.