Half of what we were building shouldn't exist

Half of what my ops team was about to build didn't need to exist.

I only realized it because I sat down to look at the operations roadmap in our business, a list of every task and project on deck at MSP Sales Partners, and ran every single item through the same filter:

Have we questioned the requirement?

Have we deleted everything we could?

Have we simplified what's left?

Have we sped it up?

Then — and only then — should we be automating it.

By the time I got through the list, entire projects were crossed off. Not because we'd done them wrong, but because questioning the requirement and deleting everything we could revealed they shouldn't have been on the list in the first place.

That filter is Elon Musk's five-step algorithm.

And the reason it's so powerful isn't the five steps — it's the order.

Most of us run it backwards, which is why we end up with bloated processes, automations that don't really help, and half the stuff we're building that probably shouldn't exist.

I'm fascinated by people who repeatedly do things that are next to impossible.

Very few people have built a $100 million company. Fewer have built a billion-dollar one. Almost none have built multiple billion-dollar companies across entirely different industries — Tesla, SpaceX, Starlink, now xAI.

When someone pulls off something improbable once, you can chalk it up to luck. When they do it repeatedly, across different domains that share almost nothing in common, at some point you have to acknowledge it's not luck.

That's worth studying.

And the piece of his thinking I keep coming back to is what he calls The Algorithm.

He developed this the hard way — as an engineer solving the wrong problems at Tesla and SpaceX before figuring out the right approach. He's open about the fact that he ran it backwards many times before he got it right. Which I find strangely comforting.

1. Question every requirement. Make every requirement earn its place, especially the requirements from smart people. Smart people have a track record of being right, which lets them make assumptions nobody challenges. Those assumptions become invisible requirements baked into whatever you're building. Your job is to surface them.

2. Delete any part of the process you can. Subtract first. Our natural tendency is to add — "we'll bolt this on to make that easier, add that to handle this, tack this on to fix that" — and before you know it you've got complexity, integration points, room for error, and changing anything becomes a project. Elon's rule: if you're not adding 10% back, you haven't deleted enough.

3. Simplify and optimize. Only now — after you've questioned and deleted — do you ask how to simplify what's left. Because if you simplify first, you're potentially engineering something that didn't need to exist.

4. Accelerate cycle time. Speed it up. Reduce the time from start to finish. But not before the prior steps — because speeding up something that shouldn't exist is the fastest way to waste effort at scale.

5. Automate. Last. Always last. Because automating a broken, bloated, or unnecessary process just bakes the dysfunction in and makes it harder to change later.

Two recent examples from my own business:

The CRM migration. We moved from GHL to Close. On the roadmap of things to build in the new system was a list of automations that had existed to operate in GHL. But when we ran them through the algorithm and asked, "Do we still need this?" — half of them were workarounds for things GHL was missing that Close just handles natively. They were completely obsolete.

But there they were on the list, because no one had questioned the requirement. We would have faithfully rebuilt them to work in Close and then spent quarters maintaining automations that shouldn't have existed at all.

The contract workaround. Someone on the team flagged a contract issue and proposed a fix: automated tasks, automated reminder sequences, and automated payment adjustments to match the terms.

When we ran it through the algorithm — delete first, simplify what's left — the actual fix was a minor text change in the contract and one task that fires 30 days before the term ends. That's it. No automation required.

In both cases, starting with “how do we automate this?” would’ve meant building an infrastructure to solve problems that evaporated the moment we questioned them.

Here's what I've come to believe: we think automation speeds things up. Applied at the wrong time, it actually makes the business less flexible.

Every automation is something that has to be untangled later when the process needs to change. Zaps, workflows, triggers, integrations — layered on top of each other until a small change means unwinding five things in the background.

So people settle for slightly-less-effective processes because changing them is painful. And over time, the business leaks efficiency it was supposed to be gaining by automating in the first place.

When you actually clock the time from the start of a process to the end result, you'll often find the slower, dumber, less-automatic way is more efficient.

Unless you run the algorithm first.

There's a famous quote about writing: "I would have written a shorter letter if I had more time."

That's what this algorithm does to a business. We complicate things by default because it's faster in the moment. Simplifying takes more time and more thought upfront — which is exactly why most operators skip it and just keep adding.

The ones that don't? They end up with lean operations where every piece earned its place.

Here's Elon breaking it down himself:

Adios,

Ray