Optimize Nothing That Shouldn't Exist
Still on the Founders podcast episode about Elon Musk. There's another part that stuck with me.
There's a story from inside Tesla that I keep thinking about.
At some point during production, there was a battery mat - a component being built as part of the manufacturing line. The team spent significant time and resources automating the process to produce it. Streamlining it. Making it more efficient. Then someone finally asked: what is this mat actually for?
It was created to reduce noise. And it was no longer needed.
All that work - automating, optimizing, improving - on something that should have just been deleted.
Elon Musk talks about this directly. His rule is that simplification must come after deletion. Not before. The order matters more than most people realize.
Delete aggressively. If you don't end up adding back at least 10% of what you deleted, you didn't delete enough. The best part is no part.
Most of us do it backwards. We see something slow, something messy, something that could work better - and we fix it. We clean it up, tighten it, make it run smoother. It feels productive. It looks like progress.
But we never stopped to ask whether it should exist at all.
That's the mistake. We can spend weeks making something more efficient and still be moving in the wrong direction. A process that shouldn't exist doesn't become worth keeping just because it runs faster. We've just made it easier to do the wrong thing.
It happens in smaller ways too, every day.
When I work on a codebase I've never touched before, my instinct is never to delete. I find something I don't fully understand - a function, a module, a config that looks like it hasn't been touched in years - and instead of removing it, I work around it. I simplify it. I make it fit what I need without disturbing it.
Because deleting feels risky. What if it breaks something? What if there's a reason it's there that I just don't see yet?
So it stays. And I build around it. And eventually it becomes part of the thing I'm also afraid to delete.
Most of the time, when I finally do go back and trace it - the thing was outdated. Dead code. A workaround for a problem that no longer exists. It should have been deleted a long time ago. Instead it just kept accumulating weight, and I added more on top of it.
The reason it's so easy to fall into this is that simplifying feels safer than deleting. Deleting is final. Deleting means admitting that something was wrong to begin with, or that circumstances changed and nobody noticed. Simplifying lets us keep the thing while still feeling like we're doing something about it.
So we simplify. We iterate. We improve. And the thing that shouldn't be there keeps surviving, just in a cleaner form.
We've all done this. Optimized workflows that should have been scrapped. Refined systems that were solving problems we no longer had. Built better versions of things we should have just stopped doing. At the time it felt like improvement. Looking back, it was just tidying up something that should have been thrown out.
The question that should come before any optimization effort is blunt: should this exist?
Not can it be better. Not how do we make this faster. Should this exist at all, and if so, why?
If the answer is no - or if nobody can clearly explain why the answer is yes — then no amount of simplification is going to fix that. The work isn't to improve it. The work is to remove it.
Delete first. Then simplify what's left.
Everything else is just polishing something that shouldn't be there.
