The Musk Method: Kill Processes, Embrace Explosions, Ship Results

TL;DR

• Musk replaced annual OKRs with "What did you get done this week?" — delivery cadence measured in weeks, not quarters
• His five-step method starts with “delete the requirement” and “simplify the process” — cut first, add back later if needed
• He moved his desk to the factory floor, collapsing the distance between decisions and execution
• SpaceX blew up dozens of rockets while NASA spent a decade on one perfect design — SpaceX got there faster
• This approach has real costs and real limits — not every company should copy it

“What Did You Get Done This Week?”

During the 2022 Twitter acquisition, there’s a scene that captures Musk’s style perfectly. Then-CEO Parag Agrawal was presenting the platform’s long-term vision. Musk cut him off: “What did you get done this week?”

This wasn’t a power move. It’s the starting point of how Musk thinks about management: measure output in weeks .

Most companies track progress with annual OKRs or quarterly goals. Musk thinks those timescales are too long — long enough for people to “look busy without actually shipping anything.” What he wants is concrete, demonstrable progress every single week. Not plans. Not reports. Stuff that’s built.

Shopify CEO Tobi Lütke has a similar instinct. Every six months he cancels all recurring meetings and only reinstates the ones that are truly needed. Musk goes further — he basically doesn’t do meetings. Or rather, his version of a “meeting” is walking over to an engineer and asking: is this problem solved yet?

The point isn’t to imitate Musk and interrogate your team. It’s to ask yourself: what did your team — including you — actually ship last week? If you can’t answer that, the problem probably isn’t the people. It’s the process.

Delete First: Musk’s Five-Step Simplification

Musk uses a framework he calls the “five-step process” across SpaceX and Tesla. The first two steps matter most:

1. Delete the requirement — Question why every requirement exists. If you can’t name who requested it and why, delete it
2. Simplify the process — After deleting requirements, simplify whatever’s left

His principle: better to cut too much and add back than to keep everything out of fear .

The Twitter case is the most extreme example. After taking over, Musk laid off roughly 80% of staff. Everyone predicted the platform would collapse. It mostly kept running. That doesn’t mean those people didn’t matter, but it revealed something: a huge portion of processes and headcount in large organizations exist to manage distrust — approval chains, alignment meetings, middle management layers, all stacked up because leadership doesn’t trust the people doing the work to get it right.

Musk’s approach: cut first, see what actually breaks, then fix those specific things. This runs counter to most managers’ instincts — we like to plan first, execute second, make sure nothing goes wrong. But Musk’s logic is simple: you can never figure out which processes are truly necessary by thinking about it. You only find out by removing them.

The CEO on the Factory Floor

Marc Andreessen described this scene in an interview: 10 PM, Musk sitting with SpaceX engineers around a table, discussing the next-generation Falcon rocket design. His dog is lying on the floor. No slides, no conference room booking. Just a group of people working through a technical problem.

This wasn’t for show. When Musk was at Tesla’s Nevada Gigafactory, he moved his desk right next to the production line. He wanted to see every bottleneck firsthand, talk directly with frontline engineers, and make decisions on the spot.

Traditional CEOs manage through reports and presentations. Information gets filtered through multiple layers before reaching the decision-maker. Musk skips all of it and stands where the problem is. Decisions happen fast — no waiting for information to travel up the chain, no waiting for managers to schedule a meeting, no waiting for conclusions to trickle back down. Where the problem is, that’s where the decision gets made.

There’s a subtler effect too: when engineers see the CEO understands the technical details and is willing to work alongside them at midnight, they show up differently. Trust gets built by solving problems together, not by quarterly all-hands speeches.

Early-stage companies already work this way — the founder is closest to the product and the tech. But as companies grow, many founders unconsciously retreat into “management,” spending their days in meetings and reading reports. The closer you are to the problem, the faster you solve it — that doesn’t stop being true just because your company gets bigger.

Trading Explosions for Speed

There’s a compilation video on YouTube of SpaceX landing failures — every crash edited together. It looks like a disaster reel. But flip the perspective: each explosion was a data point. The team learned exactly what went wrong and made targeted adjustments for the next attempt.

Compare that to NASA’s approach: spend five to ten years designing a rocket, perfecting every component, aiming for success on the first launch. The problem is you can never simulate every real-world variable in a lab. When you finally launch and it fails, the cost is higher and the feedback loop is slower.

Musk picked a different path: build fast, blow up fast, learn fast. SpaceX became the world’s lowest-cost space transport company not because they got it right from the start, but because they learned from mistakes faster than anyone else.

This logic should sound familiar to founders — it’s the MVP mindset taken to its extreme. Your product doesn’t need to be pretty or bug-free. What kills you is spending six months polishing a “perfect version” that the market doesn’t want. Ship first, get feedback, iterate.

Where This Method Breaks Down

Worth talking about the other side of this.

Musk’s management style comes with intense pressure and controversy. There’s the widely-told assistant story — she asked for a raise, Musk told her to take two weeks off while he handled her work, then when she returned he said “this job isn’t that hard” and fired her. You can call it an extreme efficiency standard. You can also call it cruel. Both are probably right.

Tesla and SpaceX have consistently high turnover. The people who stay tend to be mission-driven and willing to sacrifice work-life balance. That’s not a condition every company can replicate.

Think about when this approach works:

• Mission-driven organizations — the team believes they’re changing the world and will tolerate the pressure
• Technically dense products — the CEO can actually understand the technical details, which earns them the right to skip management layers
• High fault tolerance — rockets can explode, but if you’re building medical devices or financial systems, “blow it up and see what happens” probably isn’t the move

When it backfires:

• The team is there for the paycheck, not the mission — pressure just accelerates attrition
• The CEO doesn’t understand the technical details but skips management layers anyway — you get worse decisions, not faster ones
• Low fault tolerance — rapid iteration only works when the cost of failure is manageable

Rather than copying the whole playbook, pick the parts that fit your situation. Use “what did you get done this week” to check your cadence. Use the five-step method to audit bloated processes. Stay close to your product and your users. Copying Musk wholesale will probably blow up in your face — but selectively borrowing a few moves is worth it.

This article was inspired by Marc Andreessen’s interview with Lex Fridman, which goes deep into Musk’s management style.