Don't Automate a Life That Shouldn't Exist

The fifth and last step of the engineering framework for a life is automation. It is the most dangerous step, and the one most people reach for first.

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

This is the last step. After you question your requirements, delete what you can, simplify what remains, and speed up the cycle, you automate. You hand the repeatable work to a machine so your attention is free for what only you can do.

It is also the most dangerous step, and the one most people reach for first.

Here is the trap. The moment you automate something, you marry it. You do not just build the thing. You commit to maintaining it, updating it, fixing it every time the world shifts underneath it. Automation does not make a task disappear. It changes the task from doing the work to keeping the machine that does the work alive. And if the thing you automated should never have existed in the first place, you have just built a permanent home for it.

Automating a bad process does not fix it. It cements it.

Automation pays at volume, and almost nowhere else

Look at how two different engines get built. Aerojet Rocketdyne, now part of L3Harris, builds the RS-25, the old Space Shuttle main engine, at a rate of about four engines per year, each one essentially hand-crafted and costing north of a hundred million dollars. That is a workshop. At four a year, you do not build a sprawling automated production line, because you would never run it enough to justify it, and careful manual work is exactly right at that volume.

SpaceX builds its Raptor engine on something close to a daily cadence, on the order of hundreds per year. That is a factory. At that volume, automation is not optional. The throughput both justifies the machines and demands them, because you cannot hand-build hundreds of engines a year, and a high-throughput line cannot tolerate a sloppy process, so the automation forces the quality up too.

Neither approach is wrong. They are matched to completely different volumes. High volume earns its machines. A workshop building a handful of custom pieces a year does not.

Most of your life is the workshop, not the factory.

Alex Hormozi tells a story that should be taped to every engineer's monitor. An accounting team at one of his companies wanted to automate a task that took them about four hours a week. The developers quoted two weeks of work at five thousand dollars a day. Seventy thousand dollars. The team's salary was about seventy thousand a year, and this task was roughly ten percent of their time. So he ran the math out loud. Spending a full year's salary to save ten percent of that same salary means the automation takes ten years to pay for itself. And that is assuming nothing ever changes, that the process never needs a single update or fix. Ten years, in the best imaginable case. That is a terrible return, and the team had not seen it because automating felt productive.

The lesson is not that automation is bad. It is that automating feels like progress even when the arithmetic says it is a loss. The feeling is the trap.

When automation is really avoidance

There is a quieter version of this trap, and I have walked straight into it.

For a long time I wanted to automate my paperwork. I dislike paperwork. It drains me. And building an automation to handle it would probably have worked. But here is what I missed: the energy behind the project was not “this is high-value work worth scaling.” It was “I hate this and want to never feel it again.” Those are completely different motivations, and the second one is a warning light, not a green light.

When you find yourself desperate to automate something, the honest question is not how to build it, but what is really going on. What is this task actually for? How did it end up on your plate? What is it about this particular task that drains you? Sometimes the answer is that the task is genuinely necessary and you should automate it. But often the answer is that the thing should be deleted, handed to someone else, or that the resistance itself is worth sitting with. If the urge to automate is really an urge to avoid, the build is just a very expensive way of not looking at the real problem.

When automation starts to feel like avoidance, go back to step one and question the requirement. And if questioning it changes the requirement, that is not wasted time. That is the whole win.

The maintenance nobody counts

The cost everyone underestimates is not building the automation. It is keeping it alive.

I have watched capable people automate their way into a strange kind of prison. They build one system, then another, then ten, each one ninety-nine percent done. And then they spend all their time chasing the last one percent of each. A broken integration here, an edge case there, a process that changed and broke the script. They are so busy maintaining their machines that they have no time left for new work, or for rest. They optimized themselves into full-time mechanics for systems they built to free themselves.

I will admit my own version. I spent real time building automations into MindGym, the sensor app I am developing to support my coaching, a kind of biometric mirror that tracks heart rate variability, breathing, and check-ins so people can see what is already happening in their body. That time would almost certainly have been better spent on coaching hours and on my writing, the things that actually move my work forward right now. I am not abandoning the app. I will come back to those features when the timing is right and the volume justifies them. But I built them too early, because building felt like progress, and progress is seductive even when it is pointed at the wrong thing.

This is the same instinct engineers know as gold-plating. The term was coined decades ago by an engineer who noticed his colleagues polishing switches to look better than the competition's, well past anything the job actually required. You can pour effort into perfecting a part that was never on the critical path while the thing that actually drives the outcome sits untouched. Optimizing everything equally is how you stay busy without moving the result. The discipline is to find the one or two levers that actually matter right now and leave the rest rough.

The automation that actually serves me

So that you do not think I am against all of it, here is one I would build again in a heartbeat.

My website used to be a chore. It started as a WordPress site I cobbled together, heavy to change, slow to update. Publishing one essay meant writing it, checking it, hunting for an image, formatting it, publishing it, and then repeating the whole thing in German and French. Hours, every time. And the website is not my core work. Coaching is. So a process that ate hours of my attention was stealing from the thing that actually matters.

I rebuilt it from the ground up with Claude Code. Now I can change anything on the site by chat, from my phone. Writing an essay is a guided conversation, a strong draft after a handful of questions, a few rounds of my corrections, and then it publishes itself with the image and a question-and-answer section, in all three languages. It still takes me an hour or two per essay, sometimes a bit more. The win was not really speed. The old way took longer and produced noticeably worse writing. Now the same hour or two buys far better essays, and the time goes into the writing itself instead of the plumbing around it.

That is what good automation looks like. It was high enough value, repeated often enough, on a process stable enough to be worth committing to. It freed my attention for the core instead of burying it deeper in the periphery. The test it passed was not “can this be automated.” Almost anything can. The test was “should it.”

A rough test, not a formula

I use a back-of-the-envelope check before I automate anything. I want to be honest that these numbers are my own rough rules of thumb, not researched standards. Take the exact figures with a large grain of salt. They are meant to make you pause, not to be obeyed.

Roughly: the cost to build the automation should be less than about six to twelve months of what you would spend doing the task by hand. And the ongoing upkeep should stay under something like ten percent of your current workload. If the process is not stable yet, if it keeps changing, do it manually a while longer, because you will spend more fixing a premature automation than you ever saved.

But underneath the numbers is a simpler question, and it is the real one. Does this task actually cost me significant time or money? Or do I just dislike it, or enjoy the act of automating for its own sake? If it is the cost, automation might be right. If it is the dislike, look at the dislike. If it is the fun of building, be honest that you are building for fun, which is fine, as long as you do not pretend it is strategy.

Rick Rubin warns against assuming the way you work is the best way simply because it is the way you have always worked. Automation can quietly enshrine your current way and make it permanent. Before you do that, make sure the way is actually worth keeping.

The last step points back to the first

Here is why automation is the last step and not the first.

You can only safely automate what has already survived the earlier questions. Did you question whether this requirement is even yours? Did you delete what should not exist? Did you simplify what remained? Only what is left after all of that has earned the right to be automated. Run the steps in the wrong order and you build a beautiful, self-maintaining machine around a task that should have been deleted in step two.

The five steps form a loop. When you reach automation and something feels off, when the build feels more like escape than leverage, that is not a signal to push harder. It is a signal to go back to the beginning and ask the first question again. Is this thing supposed to exist at all?

Try this week

Pick one thing in your life you have been meaning to automate, optimize, or systematize. A spreadsheet, an app, a routine, a tool you keep telling yourself you will set up.

Before you build anything, ask three questions. How often do I actually do this, honestly counted? Do I want to automate it because it costs me a lot, or because I dislike it or enjoy tinkering? And if I ask what this task is really for, does it survive?

If it survives all three and the volume is real, build it, and enjoy the freedom it buys. If it does not, you just saved yourself from building a permanent home for something that should have been gone. Either answer is a win. The only loss is automating a life that should not exist.

Frequently asked questions

Why is automation the last step instead of the first?

Because you can only safely automate what has already survived the earlier questions. If you automate first, you risk building a beautiful, self-maintaining machine around a task that should have been deleted in step two. Question the requirement, delete, and simplify first. Only what is left has earned the right to be automated.

How do I know if something is actually worth automating?

A rough check, not a formula. The cost to build it should be less than roughly six to twelve months of doing the task by hand, and ongoing upkeep should stay under about ten percent of your workload. If the process keeps changing, wait. But the real question underneath is simpler: does this cost me real time or money, or do I just dislike it or enjoy tinkering?

What is the difference between automating and avoiding?

Automating comes from “this is valuable and repeated, worth scaling.” Avoiding comes from “I hate this and want to never feel it again.” The second is a warning light, not a green light. When the urge to automate is really an urge to avoid, the build is just an expensive way of not looking at the real problem. Look at the dislike instead.

Isn't automation supposed to save time?

Sometimes, at volume. But the cost everyone underestimates is not building it, it is keeping it alive. Every automation has to be maintained, updated, and fixed when the world shifts. People build ten systems each ninety-nine percent done and become full-time mechanics for machines they built to free themselves. Automation changes the task from doing the work to keeping the machine alive.

What does good automation look like, then?

High enough value, repeated often enough, on a process stable enough to be worth committing to. Rebuilding my website so I can publish an essay by guided conversation in three languages passed that test. The win was not speed, it was that my attention went into the writing instead of the plumbing. The test was never “can this be automated.” Almost anything can. The test is “should it.”

This is the fifth and final step of an engineering framework for redesigning a life. The loop starts again in Stop Optimizing Your Life. Start Specifying It. with deletion in The Best Part Is No Part, simplification in Why Your Life Won't Run Smoothly Until You Stop Trying, and speeding up the cycle in The Weekly Retrospective. If you want a place to start, the Essential Self Diagnostic is fifteen questions that take about sixty seconds.