The Art of Removal — What a Rocket Engine, a Dead Painter, and a Canadian CEO Taught Me About Building
In 1945, Pablo Picasso sat down in a lithography studio and drew a bull.
It was beautiful. Realistic. Muscular. Shaded. Every tendon rendered, every shadow in its place. The kind of drawing that makes you say, “That person can really draw.”
Then he drew it again. And again. Eleven times.
Each time, he removed something. A shadow here. A muscle there. The texture of the hide. The volume of the body. The specificity of the hooves.
The eleventh bull is barely there. A few curved lines on a blank page. No shading. No mass. No detail.
And yet — it is unmistakably a bull. More bull than the first one, somehow. The first drawing shows you what a bull looks like. The last one shows you what a bull is.
The Rocket That Learned the Same Lesson
Eighty years later, SpaceX built a rocket engine called Raptor 1. It worked. It was extraordinary, actually — the first full-flow staged combustion engine to fly. But look at it and you see chaos: a tangle of pipes, wires, sensors, valves, brackets, and tubes. Engineering spaghetti wrapped around a controlled explosion.
Then they built Raptor 2. Fewer parts. Fewer flanges. Welds where bolts used to be. Whole subsystems deleted.
Then Raptor 3. It looks like a sculpture. Almost no external plumbing. Clean metal curves. You could hang it in a gallery.
Here’s the part that breaks your intuition: Raptor 3 is more powerful than Raptor 1. Not despite being simpler. Because it’s simpler. Fewer parts means less weight. Less weight means better thrust-to-weight ratio. Fewer joints means fewer failure points. Fewer components means faster manufacturing, which means faster iteration, which means faster improvement.
They removed their way to dominance.
Tobi Lutke, the CEO of Shopify, looked at that progression and called it “today’s Picasso.”
He’s right. And the implications go far beyond rocket engines.
The First Principle: Understanding Precedes Subtraction
Here is the thing that most people miss about Picasso’s bull: he could draw a photorealistic bull at age 13. He spent decades mastering anatomy, perspective, light, and form. Only then did he start removing.
This is not minimalism. Minimalism is an aesthetic preference. This is something deeper. This is earned simplicity — the kind that only comes from understanding a system so completely that you can see which parts are load-bearing and which parts are scaffolding.
SpaceX’s engineers couldn’t simplify Raptor until they understood every thermodynamic interaction, every pressure pathway, every failure mode in the complex version. The complex version wasn’t a mistake. It was a necessary step. You have to build the detailed bull before you can draw the simple one.
As a CTO, ask yourself: which parts of your system exist because you understand them, and which exist because you don’t understand them well enough to remove them?
That second category is where your biggest gains are hiding.
Complexity Is Not a Feature. It’s a Tax.
Every line of code you ship has a carrying cost. Not just in compute or storage — in attention. Someone has to understand it. Someone has to maintain it. Someone has to debug it at 2am when it breaks. Someone has to explain it to the new hire. Someone has to work around it when building the next feature.
Every process in your organization has the same cost. Every meeting. Every approval chain. Every “we’ve always done it this way.”
Complexity compounds. One unnecessary abstraction doesn’t kill you. But a hundred of them — layered over years, each one “justified” at the time — creates a system where everyone is moving through molasses and nobody can explain why things feel so slow.
The physics of this are simple: complexity is debt you pay with attention, and attention is your scarcest resource.
A Raptor 1 engine with 1,000 parts requires 1,000 things to go right on every firing. A Raptor 3 with 500 parts cuts your failure surface in half. The math works the same way in codebases, in team structures, and in your own daily workflow.
The Trap of the 7/10 Copy
Tobi Lutke said something on a podcast recently that I can’t stop thinking about:
“A 6/10 built from your own axioms gives you total control and the ability to take it past 7. A 7/10 copy gives you no mastery and no ability to iterate.”
This cuts against every instinct we have. We’re trained to benchmark. Find the best practice. Copy the architecture that worked for Stripe, or the team structure that worked for Spotify, or the deployment pipeline that worked for Netflix.
And it works — up to a point. You get to 7/10 fast. But then you’re stuck. Because you don’t understand why it’s a 7. You don’t know which parts are essential and which are artifacts of a different company’s context. You can’t subtract because you don’t know what’s load-bearing.
The team that built their own 6/10 from first principles? They know every piece intimately. They know what to remove next. They’ll be at 8 while you’re still stuck at 7, wondering why the Spotify model doesn’t work at your 40-person company.
Benchmarking creates a ceiling, not a floor.
This doesn’t mean ignore the world. Learn from everyone. Study every approach. But when you build, build from understanding, not from imitation. Picasso studied every master that came before him. Then he drew his own bull.
The Conductor, Not the Player
Here’s where this gets personal.
Tobi Lutke runs six AI agents simultaneously. He described it as playing StarCraft — zooming in to micromanage a critical unit, then pulling back to manage the macro. He coordinates between agents like a real-time strategy player manages an army.
The lesson from StarCraft that he carried into business: attacking someone’s attention is more profitable than attacking their base. The meta-skill isn’t execution. It’s attention allocation.
This is the CTO’s job now. Not writing the best code. Not designing the best architecture. Not even making the best technical decisions. The job is knowing where to point attention — yours, your team’s, your AI tools’ — at any given moment.
The person who can orchestrate six agents toward a coherent goal will outperform the person who can write code twice as fast. Because the orchestrator is operating at a different level of abstraction. They’re not drawing the bull. They’re deciding which lines matter.
This is uncomfortable if your identity is built on being the best engineer in the room. It was probably uncomfortable for Picasso to stop rendering shadows. But the shadows weren’t the point. They never were.
The Question That Changes Everything
Here is what I want to leave you with. Not a framework. Not a methodology. Just a question.
Shopify went from 11,600 employees to 8,100 while growing revenue 21% per year. SpaceX removed half the parts from their engine and got more thrust. Picasso removed everything from the bull except a few lines and got more bull.
The question is:
What is one thing in your world — one dependency, one process, one feature, one meeting, one assumption — that, if you removed it, would make the whole system more powerful?
Not “what can I add to make things better?” We’re all addicted to addition. Every instinct says: add a feature, add a tool, add a person, add a process, add a layer.
The question is about removal. What is the one piece of plumbing on your Raptor 1 that doesn’t need to be there? What is the shadow on your bull that’s hiding the essential line underneath?
You probably already know the answer. You’ve probably known for a while. The thing that makes you wince slightly every time you look at it. The thing you keep working around instead of through. The thing that was necessary once but isn’t anymore.
That’s your Raptor 2 waiting to happen.
The Paradox at the Heart of Mastery
Beginners simplify because they don’t know enough to add complexity.
Experts add complexity because they know enough to see all the edge cases.
Masters simplify because they know enough to see through the edge cases to what actually matters.
The trajectory of mastery in any domain — art, engineering, leadership, code — is an arc that returns to simplicity. But it’s a different simplicity than where you started. It’s simplicity that has been through complexity and come out the other side.
You can’t skip the middle. You can’t jump from beginner simplicity to master simplicity. The understanding has to be earned. The realistic bull has to be drawn before the abstract one.
But if you’ve been in this game long enough — if you’ve built the complex systems, fought the fires, shipped the things — you might be ready for the next phase. The phase where you start asking not “what should I build?” but “what should I stop building?”
The phase where the art is in the removal.
The Raptor 3 engine sits on a factory floor in Hawthorne, California. It’s almost silent in its simplicity. No tangle of wires. No spaghetti of tubes. Just clean metal, a few essential curves, and 280 tons of thrust waiting to happen.
Picasso’s eleventh bull hangs in a museum. A few lines on white paper. Sixty seconds of looking and you understand: that’s a bull. That’s the only bull that matters.
Same principle. Same earned simplicity. Same quiet confidence that comes from knowing exactly what to keep and what to let go.
The question isn’t whether you’re capable of building something complex. You’ve already proven that. The question is whether you’re ready to make it simple.