← Back to Essays

Why Your Life Won't Run Smoothly Until You Stop Trying

8 min read

A Soyuz spacecraft approaching the International Space Station, photographed against the deserts and coastline of Earth far below
A Soyuz spacecraft approaching the International Space Station. A small, simple capsule, flying in essentially this form since the 1960s. Unglamorous, and exactly the right shape for the job. Photo: NASA, public domain.

The third step of the engineering framework for a life is simplification. It is the most misunderstood, because it sounds like the thing we are all already doing.

By Peter Plötner. Aerospace engineer and Wayfinder Life Coach. More about Peter →

There is a moment, somewhere in every engineer's career, when you realize that the thing you built doesn't work because there is too much of it.

You added a module to handle the edge case. Then another module to handle the edge case the first module created. Then a config layer to manage the modules. Then a logging system to debug the config layer. Then a backup system because the logging system kept failing. Each piece, by itself, made sense at the time. Together, they make a system that is almost impossible to maintain.

I had this moment with a piece of software called Virtual Habitat. It was a simulation of the life support systems on spacecraft, the Environmental Control and Life Support System (ECLSS, in the trade). I inherited a version of it that had grown, organically, into something that worked but that nobody fully understood anymore.

I did not add features. I did the opposite. I simplified the core. I cleaned up the interfaces between modules so they were independent of each other. I made the seams cleaner. I removed nothing the system actually needed. I just untangled what was already there.

The simulation ran a lot faster afterward. It also became much easier to extend, because you could change one module without breaking the others. Less code did more work.

This is the third step of the framework I have been writing about for the past several essays. It is also the most misunderstood, because it sounds like the thing most of us are already doing. We are always trying to make our lives more efficient. That is exactly the problem.

The order of operations matters

The framework, briefly. Question your requirements. Delete the parts you can. Then, and only then, simplify and optimize. Then accelerate. Then automate.

Most of us start at step three, simplification, and wonder why our lives keep getting more complicated. The reason is simple. You cannot simplify a system whose requirements you haven't questioned and whose unnecessary parts you haven't deleted. All you can do is rearrange the mess into a cleaner-looking pile.

This is so common in engineering that there is a phrase for it. The most common error of a smart engineer is to optimize a thing that should not exist. You build the wrong feature really well. You polish the report nobody needs. You write elegant code for a function that should be deleted entirely.

In life it looks like a beautifully color-coded calendar full of meetings nobody should be in. A meal-prep system for a diet you don't believe in. A morning routine optimizing your commute to a job you should leave. A productivity stack of seventeen apps managing a workload that should be cut in half.

You can spend years getting very good at this. I have. Most of us have.

The honest move is to do steps one and two first, even though they are scarier. Then step three becomes one of the most satisfying experiences in a human life.

What real simplification looks like

Here is the trap to avoid. Simplification is not the same as minimalism. It is not about owning less stuff or having a cleaner desk. It is about reducing the number of moving parts in your life that interact with each other and create complexity you weren't planning for.

In engineering, every interface between two components is a potential failure point. The wire between two boxes can break. The data passed between two modules can be misinterpreted. The handoff between two teams can drop information. So good engineers, when they simplify, look first at the interfaces. Can you remove a handoff? Can you combine two systems that were trying to do the same thing? Can you eliminate a translation layer?

In life, the same logic applies. The interfaces in your life are the moments where two things have to coordinate. The school dropoff that has to happen between the morning workout and the start of work. The dinner that has to fit between the kid's bedtime routine and the calls with people in another time zone. The hobby that needs three separate apps to schedule, log, and share.

Each interface costs you. Not necessarily a lot. But the cost compounds.

A few simple ones from my own life:

I used to think about my fitness as a separate thing I needed to fit in. Now I just carry my kids whenever they want to be carried, for as long as I can. They are growing, they are heavy, they are getting heavier every year. It is a slow, patient, daily strength workout that I never have to schedule. The interface between “fitness” and “being a present dad” disappeared.

I eat the same thing for breakfast almost every morning. Frozen peas with peanuts. It takes one minute to prepare. It is healthy enough that I don't have to think about it. It is boring enough that I don't develop strong opinions about it. The interface between “breakfast” and “the rest of my life” is essentially zero.

I stopped treating better communication, a closer marriage, and real presence with my kids as three separate projects. They are one practice now: getting better as a coach. Coaching is a daily workout for a complex set of muscles I happen to love using, and the same muscles that make me a better coach make me a better colleague, a better husband, and a more present father. I would never run those exercises on their own. I run them every day in service of one simple, not easy goal: becoming a better coach.

None of these are heroic. None of them required willpower. They are not lifestyle hacks. They are the result of asking, quietly, of each small repeating piece of my life: can this fit inside something else that's already there?

What an engineer notices about their own habits

The thing I notice about my own pattern, and please tell me if you recognize this in yourself, is that I love building and I am much worse at what comes after building: the showing, the shipping, the listening to what comes back. I will build a coaching workbook before I have ten clients. I will build a website before I know what it should say. I will build elaborate frameworks before I have tested the basics.

It is the build-everything-first instinct. Spec the whole thing on paper, construct it in one go, and only discover what is actually wrong once it finally meets the real world. The version you ship simple and early, and then learn from, almost always beats the one you spend years perfecting in private.

I have lost so many years to this pattern in my own work. I built financial visualizations before users wanted them. I built a search engine for non-profit funding before I had talked to enough non-profits. I built the elaborate version of half a dozen ideas before I had tested whether the simple version mattered to anyone.

The fix, when I finally see it in myself, is uncomfortable. I have to stop building and start showing. I have to give the simple version to someone real, watch them use it, and let their reaction tell me what to do next. Most engineers I know hate this. It feels like exposing unfinished work. It is exposing unfinished work. The exposing is the whole point.

If you find yourself adding more features to something you have never shown to anyone, that's the tell. You are optimizing a part that should not exist yet, because the part it was supposed to support never existed in the first place.

Cave divers and tourist divers

There is a useful image for this principle from a completely different field.

Recreational divers, the ones who do a week of vacation diving in warm water, tend to accumulate gear. A new dive computer. A bright-colored mask. A snorkel they don't really need. Above all, an expensive camera, with the pouches and clips and lights that come with it. It looks impressive on the surface, in both senses. And at their level, the camera is mostly a distraction, pulling attention away from the basic safety habits they should still be building.

Technical divers, the ones who go into overhead environments where you cannot swim straight up to the surface, do the opposite. They carry exactly what they need. Every additional piece of gear is a potential entanglement, a potential failure point, one more thing to manage at the exact moment you can least afford a distraction. Because the thing that actually kills people in caves is rarely a dramatic equipment explosion. It is far more ordinary. A diver kicks up the fine sediment on the floor, the water turns to an instant white-out, they lose the guideline back to the entrance, and they run out of gas searching for a way out they can no longer see. The whole culture of technical diving is built around the question: do I actually need this, and what does it cost me if it fails?

The tourist diver's life is forgiving. If your snorkel falls off, you swim to the boat. If your light dies, you surface. The cost of complexity is low.

The technical diver's life is not forgiving. The cost of complexity is sometimes your life. So they simplify ruthlessly.

Most of us live our lives more like tourist divers than we should. Our environment is forgiving enough that we don't feel the cost of complexity directly. The extra meeting doesn't kill us. The extra commitment doesn't kill us. The extra app doesn't kill us. The complexity just slowly drains the life out of our weeks. It pulls us out of the moment we are actually in, and we wonder why we feel tired all the time and strangely absent from our own days.

Asking the cave diver's question, of every part of your week, would change a lot. Do I actually need this? What does it cost me if it fails? And the harder one: what does it cost me even when it works?

Soyuz, the shuttle, and the wrong tool for the job

I want to make one last comparison, and then I'll stop, because this is the cleanest example I know of the cost of building the wrong tool.

The Space Shuttle was an extraordinary machine. To assemble the International Space Station in orbit, you needed exactly that capability. A pressurized cargo bay big enough to carry station modules. A robotic arm. Astronauts who could spacewalk to bolt the pieces together. The shuttle did things no other vehicle could do.

But the shuttle also flew people who just needed to go to the station and come back. People who didn't need a cargo bay or a robotic arm. People who needed a ride.

The Soyuz capsule was, for a long time, the alternative. A small, simple capsule that has been flying since the 1960s. Less impressive on paper. Less capable. Less photogenic. But for the specific job of getting humans to and from low Earth orbit, the Soyuz had a much better safety record per flight than the shuttle, used a fraction of the resources, and almost never grounded the program for a year while everyone investigated.

The shuttle was beautiful, and tragically over-specced for most of what it did. The Soyuz was unglamorous, and exactly the right shape for what was actually needed.

I am not interested in piling on the shuttle. The shuttle did things that mattered, and it did them under real constraints. The point isn't that the shuttle was wrong. The point is that if all you needed to do was get a few people to the station and back, the shuttle was the wrong tool. The simpler vehicle would have served you better, more often, at a fraction of the cost.

Almost every part of life has a shuttle version and a Soyuz version. The shuttle version handles every conceivable case. The Soyuz version does the actual job. Most of the time, what you need is the Soyuz.

Try this week

Pick one area of your life that feels slightly more complicated than it should be.

Don't try to delete from it yet. You may have done that work already. Just look at the interfaces. The places where two things have to coordinate, and the coordination is what's eating your time and energy.

Then ask one question. Can two things become one thing?

The workout and the kid-carrying. The journal and the planning session. The three diet apps and the one boring breakfast. The two project management tools doing slightly overlapping things.

You are looking for a fold, not a cut. The cut was last week's work.

If you find one, try it for a week. Don't tell anyone. Just collapse the two things into one and see what happens. Most of the time, what happens is that you have more energy, fewer micro-decisions, and a slightly quieter mind.

You will probably also find, after a few rounds of this, that your life starts to run in a way it didn't before. The friction is gone. The handoffs are smoother. There is space.

This is what step three is for. Not to make a complicated life slightly more efficient. To make a life simple enough that it can finally fly.

Frequently asked questions

Isn't this just minimalism?

No. Minimalism is about owning less. Simplification here is about reducing the interfaces, the points where two parts of your life have to coordinate with each other. You can be a committed minimalist and still have a brutally complex week. The target is moving parts that interact, not stuff.

How is this different from your essay on Musk's five-step algorithm?

That essay walks the whole algorithm. This one is step three, simplification, in isolation. It is the step most people wrongly start with. You question your requirements and delete the unnecessary parts first. Only then does simplification do anything but rearrange the mess into a cleaner-looking pile.

What is the difference between simplifying and deleting?

Deleting, step two, removes a part of your life entirely. Simplifying, step three, keeps the parts you need but collapses the coordination between them. A cut removes. A fold combines. If you are still deciding what to remove, you are doing step two, not step three.

Isn't folding two things into one just multitasking?

No. Multitasking splits your attention across two things at the same time. Folding turns two things into one thing, so there is only one thing to attend to. Carrying your kids is not exercising while parenting. It is a single activity that happens to do both, with no interface between them.

Where do I start?

Pick one area that feels more complicated than it should. Do not look for things to cut. Look at the interfaces, the handoffs where two things have to coordinate. Ask whether two of them can become one. Try a single fold for a week, quietly, and see what it does to your energy.


This essay is the third step of an engineering framework for redesigning a life. The whole algorithm, from questioning your requirements to automating what is left, is in Stop Optimizing Your Life. Start Specifying It. The deletion step, the cut that has to come before this fold, is in The Best Part Is No Part. If you want a place to start, the Essential Self Diagnostic is fifteen questions that take about sixty seconds, a quick read on which parts of your life are still carrying their weight.

Continue exploring

Take the DiagnosticGet in Touch