# Five Step Algorithm > Systematically improve any product, process, or system by following Elon Musk's strict sequence: question requirements, delete, simplify, accelerate, automate. - Skill: `sethmblack/five-step-algorithm` (Agent Skill) - Install (CLI): `npx skillmds add sethmblack/five-step-algorithm` - Raw SKILL.md: https://api.skillmd.com/api/skills/sethmblack/five-step-algorithm/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: sethmblack (https://skillmd.com/u/sethmblack) - Updated: 2026-09-08 - Page: https://skillmd.com/skills/sethmblack/five-step-algorithm --- # Five-Step Algorithm Systematically improve any product, process, or system by following Elon Musk's strict sequence: question requirements, delete, simplify, accelerate, automate. --- ## When to Use - Optimizing a manufacturing process - Reducing costs in a product or service - Improving team or organizational workflows - Any situation where someone says "make this more efficient" - User asks "Apply the algorithm" or "How do I make this better/faster/cheaper?" --- ## Inputs | Input | Required | Description | |-------|----------|-------------| | process_or_product | Yes | What you're trying to improve | | current_state | Yes | How it works now (steps, parts, timeline) | | goal | No | Specific improvement target (cost, speed, quality) | --- ## The Algorithm Musk calls this "the algorithm"—a distillation of manufacturing wisdom from Tesla and SpaceX. The power lies in the **strict ordering**. You must complete earlier steps before moving to later ones. ### Step 1: Question the Requirements **"Make the requirements less dumb."** - Every requirement is suspect until proven necessary - Requirements from smart people are especially dangerous—you may not question them enough - Each requirement must have a **name attached** (not a department) - Ask: "Who originally requested this? Why? Is the reason still valid?" **Key questions:** - Why does this requirement exist? - What happens if we don't meet it? - Is this a true constraint or a preference? - Who owns this requirement? Can we talk to them? **Warning signs of bad requirements:** - "It's always been done this way" - "Legal/compliance requires it" (but no specific person can explain why) - "The customer expects it" (but no actual customer data) - Requirements from departments, not individuals ### Step 2: Delete Parts or Processes **"If you're not adding back at least 10% of what you delete, you didn't delete enough."** - The bias is always toward adding things "just in case" - Fight this bias ruthlessly - It's easier to add something back than to delete something that shouldn't exist - Deletion is the highest-leverage improvement **Key questions:** - What would break if we removed this entirely? - When was this last actually needed? - Is this a dependency or just a comfort? - Can we run a test without this? **Deletion targets:** - Steps that exist "for documentation" - Approvals that have never blocked anything - Parts added for edge cases that haven't occurred - Reports no one reads ### Step 3: Simplify and Optimize **"The most common error of a smart engineer is to optimize something that should simply not exist."** - Only simplify what remains after deletion - Resist the urge to make unnecessary things better - Look for ways to combine steps or parts - Reduce variation and special cases **Key questions:** - Can two steps become one? - Can multiple parts be consolidated? - Is there a simpler way to achieve the same outcome? - What would a beginner find confusing? **Warning:** If you find yourself optimizing, check whether you should delete instead. ### Step 4: Accelerate Cycle Time **"Every process can be speeded up. But only do this after you have followed the first three steps."** - Speed of iteration beats perfection of any single iteration - Look for bottlenecks and constraints - Parallelize where possible - Reduce wait times and handoffs **Key questions:** - What's the current cycle time? - Where do things wait? - What could be done in parallel? - What's the theoretical minimum time? **Warning:** If you accelerate a process that should be deleted, you're being efficient at something useless. ### Step 5: Automate **"Most people start with Step 5, and they automate a process that never should have existed in the first place."** - Automation is powerful but should be LAST - Never automate before questioning, deleting, and simplifying - Automation locks in the current process—make sure it's the right process - Consider partial automation where full automation is overkill **Key questions:** - Have we completed steps 1-4? - Is this process stable enough to automate? - What's the cost of automation vs. the benefit? - Can we automate partially? --- ## Critical Warning **Musk on his own mistakes:** "I have personally made the mistake of going backwards on all five steps multiple times. In making Tesla's Model 3, I literally automated, accelerated, simplified and then deleted." The most common error pattern: 1. See a problem 2. Jump to automation (Step 5) 3. Realize the process is wrong 4. Have to undo expensive automation 5. Finally question and delete **The algorithm prevents this by enforcing order.** --- ## Workflow ### Step 1: Gather and Review Inputs Collect all relevant information: - Review the provided data and context - Identify key parameters and constraints - Clarify any ambiguities or missing information - Establish success criteria ### Step 2: Analyze the Situation Perform systematic analysis: - Identify patterns and relationships - Evaluate against established frameworks - Consider multiple perspectives - Document key findings ### Step 3: Generate Recommendations Create actionable outputs: - Synthesize insights from analysis - Prioritize recommendations by impact - Ensure recommendations are specific and measurable - Consider implementation feasibility ## Output Format ```markdown ## Five-Step Algorithm Analysis ### Target [What's being improved] ### Current State [Brief description of current process/product] --- ### Step 1: Question Requirements **Requirements identified:** 1. [Requirement] - Owner: [Name] - Status: [Valid/Questionable/Delete] 2. [Requirement] - Owner: [Name] - Status: [Valid/Questionable/Delete] 3. [Requirement] - Owner: [Name] - Status: [Valid/Questionable/Delete] **Requirements to challenge:** - [Requirement]: [Why it should be questioned] - Action: [What to do] **Requirements validated as necessary:** - [Requirement]: [Why it's actually needed] --- ### Step 2: Delete **Candidates for deletion:** | Item | Last Actually Needed | What Breaks Without It | Recommendation | |------|---------------------|------------------------|----------------| | [Part/step] | [When] | [Impact] | Delete/Keep/Test | **Deletions to implement:** 1. [Item] - Rationale: [Why] 2. [Item] - Rationale: [Why] **Expected savings from deletion:** [Time/cost/complexity reduction] --- ### Step 3: Simplify and Optimize **After deletion, what remains:** [Simplified process/product description] **Simplification opportunities:** 1. [Current] → [Simplified] - Benefit: [What improves] 2. [Current] → [Simplified] - Benefit: [What improves] **Consolidation opportunities:** - [Multiple items] → [Single item] --- ### Step 4: Accelerate **Current cycle time:** [Time] **Bottlenecks identified:** 1. [Bottleneck] - Cause: [Why] - Solution: [How to speed up] 2. [Bottleneck] - Cause: [Why] - Solution: [How to speed up] **Parallelization opportunities:** - [Steps that could run in parallel] **Target cycle time:** [New time] --- ### Step 5: Automate **Automation candidates (ONLY after steps 1-4):** | Process | Stability | ROI | Recommendation | |---------|-----------|-----|----------------| | [Process] | High/Med/Low | [Estimate] | Automate/Partial/Manual | **Automation plan:** 1. [What to automate] - Timeline: [When] 2. [What to keep manual] - Reason: [Why] --- ### Summary | Metric | Before | After | Improvement | |--------|--------|-------|-------------| | Steps/Parts | [N] | [N] | [%] | | Cycle Time | [Time] | [Time] | [%] | | Cost | [Cost] | [Cost] | [%] | ### Next Actions 1. [Immediate action] 2. [Short-term action] 3. [Longer-term action] ``` --- ## Outputs **Primary Output:** A structured analysis document that identifies and articulates patterns, insights, and actionable recommendations based on the input data. **Format:** ```markdown ## Analysis: [Topic] ### Key Findings - [Finding 1] - [Finding 2] - [Finding 3] ### Recommendations 1. [Action 1] 2. [Action 2] 3. [Action 3] ``` **Example output:** See the Example section below for a complete demonstration. ## Constraints - Do not use this analysis as the sole basis for critical decisions - Do not apply this framework to situations outside its intended scope - Acknowledge that analysis is based on available data, which may be incomplete - Honor the complexity of real-world situations that resist simple categorization - Present findings with appropriate confidence levels - Recognize the limits of the methodology ## Example **Input:** "Our code review process takes 3-5 days and engineers are frustrated. How do we speed it up?" **Output:** **Why this works:** This example demonstrates the key principles of the skill in action. The approach is effective because: - It follows the systematic workflow outlined above - It shows concrete application of the framework - It produces actionable, specific outputs rather than vague generalizations - The analysis is grounded in observable details - The recommendations are prioritized and implementable **Alternative applications:** This same approach can be applied to: - Different contexts within the same domain - Related but distinct problem types - Scaled up or down depending on scope - Combined with complementary analytical frameworks ## Five-Step Algorithm Analysis ### Target Code review process ### Current State - Engineer submits PR - Assigned to reviewer based on rotation - Reviewer has 24 hours to start review (policy) - Review comments go back and forth (avg 2.3 rounds) - Final approval required from tech lead - Merge requires green CI and approval - Average time: 3-5 days --- ### Step 1: Question Requirements **Requirements identified:** 1. 24-hour start SLA - Owner: Engineering Manager (from 2019) - Status: Questionable 2. Tech lead approval for all PRs - Owner: CTO (2018 security incident) - Status: Questionable 3. Full CI suite must pass - Owner: QA team - Status: Valid 4. Assigned reviewer system - Owner: Unknown - Status: Questionable **Requirements to challenge:** - **24-hour SLA:** Creates batching behavior. Reviewers wait until deadline. Action: Talk to Eng Manager about whether this helps or hurts. - **Tech lead approval for ALL PRs:** Security incident was 6 years ago. Is blanket approval still needed? Action: Get data on what % of PRs tech leads actually change. - **Assigned reviewer:** Why can't anyone review? Action: Understand original rationale. **Requirements validated as necessary:** - CI passing: Real quality gate with demonstrated value --- ### Step 2: Delete **Candidates for deletion:** | Item | Last Actually Needed | What Breaks Without It | Recommendation | |------|---------------------|------------------------|----------------| | Tech lead approval (small PRs) | Rarely changes outcome | Nothing for <100 lines | Delete for small PRs | | Assigned reviewer system | — | Anyone could review | Delete, allow self-selection | | 24-hour SLA | Creates wrong incentive | Faster reviews if removed | Delete | | Multiple review rounds | Shows unclear requirements | Better first-pass reviews | Reduce | **Deletions to implement:** 1. Remove tech lead approval for PRs under 100 lines (covers 60% of PRs) 2. Remove assigned reviewer—anyone can pick up any review 3. Remove 24-hour SLA—replace with "same day" culture expectation **Expected savings from deletion:** 1-2 days average --- ### Step 3: Simplify and Optimize **After deletion, what remains:** - Engineer submits PR - Any available reviewer picks it up - One round of review (target) - Tech lead approval only for large PRs - CI passes - Merge **Simplification opportunities:** 1. Review rounds (2.3 → 1): Create PR template with checklist; reviewer blocks only for real issues 2. Large PR threshold: Clear definition (>100 lines OR touches auth/payments) --- ### Step 4: Accelerate **Current cycle time:** 3-5 days **Bottlenecks identified:** 1. Waiting for reviewer pickup - Cause: Batching behavior - Solution: Slack notification for open PRs 2. Back-and-forth rounds - Cause: Nitpicking - Solution: "LGTM with comments" option 3. Tech lead availability - Cause: Single person - Solution: 2-3 designated approvers **Parallelization opportunities:** - Review and CI can run in parallel (already happening) **Target cycle time:** <1 day for small PRs, <2 days for large PRs --- ### Step 5: Automate **Automation candidates (ONLY after steps 1-4):** | Process | Stability | ROI | Recommendation | |---------|-----------|-----|----------------| | PR size classification | High | High | Automate—tag as small/large automatically | | Reviewer notification | High | Medium | Automate—Slack bot for waiting PRs | | Auto-merge on approval | Medium | Low | Partial—only for small PRs with green CI | **Automation plan:** 1. PR size tagging via GitHub Action - Timeline: This week 2. Keep manual review selection—builds ownership --- ### Summary | Metric | Before | After | Improvement | |--------|--------|-------|-------------| | Required approvals (small PR) | 2 | 1 | 50% | | Average rounds | 2.3 | 1.5 | 35% | | Cycle Time (small) | 3-5 days | <1 day | 70-80% | | Cycle Time (large) | 3-5 days | <2 days | 50%+ | ### Next Actions 1. **Today:** Talk to CTO about tech lead approval history and data 2. **This week:** Remove 24-hour SLA, announce "same day" culture 3. **Next week:** Implement PR size auto-tagging --- ## Integration This skill is part of the **Elon Musk** expert persona. Use it to systematically improve anything—but always in the right order.