pick-and-move — quality + safety report

---
name: pick-and-move
description: Force a decision when two options are roughly tied and the team is burning time trying to prove one is slightly better. Use aggressively whenever the user is in decision paralysis, design bikeshedding, or low-stakes vacillation — and on triggers like "which should we choose", "what's the right call here", "we keep going back and forth", "I can't decide between X and Y", "should we use Postgres or MySQL", "what should we name this", "which framework", "let's have another meeting to decide", "we need more data before we pick", "I want to make sure we get this right", or any moment a team is treating a near-tie like a high-stakes irreversible bet. Also fires on roadmap debates where the options have similar expected value, naming arguments, formatting and style debates, and any choice whose cost-of-delay exceeds the cost-of-being-wrong. The bug is vacillation, not picking the slightly worse option. Trigger eagerly even when the user does not name Musk or the framework.
---

# Pick And Move

> "Better to pick a path and keep moving than just vacillate endlessly on a decision."
> — Elon Musk, *The Book of Elon* (Chapter: Listen Well, Correct Fast (pick-a-path subsection))

## What this skill captures

When two options are close, the act of choosing is worth more than the choice itself. Musk's PayPal-era rule: "If there were two options, and one wasn't obviously better than the other, rather than spend time trying to pick which one was slightly better, we would just pick one and go. Sometimes we were wrong and picked the suboptimal path, but at least we moved fast." The cost of vacillation compounds — meeting after meeting, doc after doc, Slack thread after Slack thread — while the cost of being wrong on a near-tie is, by definition, small and recoverable.

The value: you stop paying the vacillation tax. You get back the hours, the team focus, and the downstream work that was blocked behind the non-decision. Near-tie wrongness is cheap. Indecision is not.

## When to use this skill

- The user is debating two (or three) options that all sound roughly fine, and the debate has run longer than the work would take.
- A naming, formatting, framework, or style choice has eaten a meeting and is heading for a second.
- The user keeps asking for "more data" before picking, but the data won't actually move the needle.
- A roadmap is stalled because nobody will commit to one of two similar paths.
- The user is asking you to break the tie because the team can't.
- The decision is reversible — a wrong pick can be undone in days or weeks, not years.

## The how-to

1. Name the tie out loud. Force the user to state, in one sentence, why neither option is obviously better. If they can't, the options aren't actually tied — there's a real winner buried under noise.
   > "If there were two options, and one wasn't obviously better than the other, rather than spend time trying to pick which one was slightly better, we would just pick one and go."
   > — *The Book of Elon*
   Surfacing the tie kills the illusion that more analysis will produce a clear answer.

2. Check reversibility. Ask: if we pick wrong, how long does it take to switch? If the answer is "days" or "one sprint," the decision is cheap and the vacillation is the only real cost.
   > "Sometimes we were wrong and picked the suboptimal path, but at least we moved fast."
   > — *The Book of Elon*
   Reversible decisions deserve speed, not ceremony.

3. Pick. Right now, in this conversation. Coin-flip if you have to. The mechanism doesn't matter — the commitment does. Write down the choice and the date.
   > "Better to pick a path and keep moving than just vacillate endlessly on a decision."
   > — *The Book of Elon*

4. Move. Identify the next concrete action that was blocked behind the decision and start it today. The pick only matters if it unblocks motion.
   > "At least we moved fast."
   > — *The Book of Elon*

5. Set a correction trigger, not a re-debate. Decide in advance: "We revisit this only if we hit metric X" or "only after Y weeks of real use." Otherwise the decision stays made. Re-litigating a near-tie is just vacillation in a new outfit.
   > "It's important to take feedback from your environment… You want to close those loops as quickly and clearly as possible."
   > — *The Book of Elon*

## Common failure modes

- **Treating reversible as irreversible.** Acting like a tool choice is a one-way door when it's a two-way door. Most picks are recoverable; vacillation isn't.
- **Demanding more data to break a near-tie.** If the existing data didn't separate the options, more of the same data won't either. You're stalling, not analyzing.
- **Picking, then re-opening the debate next week.** A pick that gets re-litigated wasn't really a pick. Set the correction trigger and honor it.
- **Outsourcing the call to a "decision meeting" instead of just deciding.** Another meeting is another vacillation cost.
- **Optimizing the wrong layer.** Spending a week choosing between two libraries that each save a day of work.

## When NOT to use this skill

- The decision is genuinely irreversible or catastrophic if wrong (architecture you'll be stuck with for years, a hire you can't undo cheaply, a public commitment that anchors the brand). Vacillation has a cost; so does picking wrong on a one-way door.
- One option is actually obviously better and the team just hasn't done the 30 minutes of analysis. Don't coin-flip past a real signal.
- The "tie" is hiding a values disagreement (security vs. speed, user vs. revenue). Pick-and-move papers over the real conversation that needs to happen.
- High-stakes safety, legal, or compliance calls where the wrong pick has asymmetric downside.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Listen Well, Correct Fast (pick-a-path subsection)" (in "Becoming a Founder").