The 42 Principles · Principle XXIV
Automate to Remove Toil
Using automation to eliminate repetition while preserving judgment, responsibility, and understandable systems.
Foundational Truth
Automation is not about replacing people.
It is about protecting human attention from work that does not deserve it.
The most valuable resource an engineer possesses is not time.
It is attention.
Time can be scheduled.
Attention can be exhausted.
Every repetitive task consumes a little of it.
Every identical sequence of clicks, commands, copy operations, validations, and confirmations creates another opportunity for fatigue to replace judgment.
That is where toil begins.
Toil is work that is manual, repetitive, predictable, and necessary, but does not become more valuable simply because a person performs it again.
Copying the same files into the same container.
Applying the same update to one hundred laptops.
Running the same report every morning.
Restarting the same service after the same failure.
Provisioning the same environment by following the same checklist.
None of those tasks is meaningless.
But when they are repeated by hand, they consume human capacity without requiring human creativity.
Never automate because people are replaceable. Automate because their attention is not.
Thought Rot
Repetition changes the way people think.
At first, the task feels manageable.
Then it becomes familiar.
Then it becomes automatic.
Eventually, the brain begins to drift.
You stop reading each prompt because you already know what it should say.
You stop checking every path because the last fifty were correct.
You begin thinking about dinner.
The next meeting.
The unresolved project.
The weekend.
Anything except the task in front of you.
I call this Thought Rot.
Not because the person has become careless.
Because the task has stopped demanding enough thought to hold the mind.
That is when errors begin.
A skipped checkbox.
The wrong destination folder.
A driver update selected instead of a service pack.
A production target chosen instead of staging.
A reboot postponed when it was required.
Most mistakes are not catastrophic.
They are small.
But small mistakes interrupt rhythm.
They create rework.
They add uncertainty.
They force the person to stop, recover context, verify what happened, and begin again.
The mistake may take only seconds.
Recovering focus may take much longer.
Automation Preserves Judgment
Computers are remarkably good at repetition.
They do not become bored.
They do not rush because it is late.
They do not skip a step because the previous ninety-nine succeeded.
They perform the instructions they were given.
Exactly.
Consistently.
Repeatedly.
That is their strength.
Human beings are valuable for different reasons.
We recognize ambiguity.
We interpret context.
We adapt to unexpected conditions.
We ask whether the task should exist at all.
We decide when the documented path no longer fits reality.
Automation should remove the work computers do well so people can concentrate on the work only people can do well.
Automation turns repetition into capacity.
Duplicate Your Best Work
Every automation is a copy of your best-known process.
A manual task can be performed by one person at one moment.
An automated task can run repeatedly, consistently, and in parallel.
While the automation performs the work, the engineer is free to design, investigate, improve, teach, or solve the next problem.
This is how engineers multiply themselves.
Not by working longer hours.
Not by moving faster.
By capturing their knowledge in a form that can continue working without their constant presence.
A script becomes another pair of hands.
A workflow becomes another operator.
A scheduled process becomes another dependable teammate.
The automation does not replace the engineer.
It extends the engineer.
The Automation Question
Not every task should be automated.
Some work occurs too rarely.
Some changes too often.
Some depends on human judgment at every step.
Automation also has a cost.
It must be designed.
Tested.
Documented.
Monitored.
Maintained.
The right question is not:
"Can this be automated?"
Almost anything can.
The better question is:
"Should this be automated, and will the value exceed the cost?"
A practical rule is:
If I must perform the same task twice, I should at least ask whether it deserves automation.
The answer may still be no.
But repetition should always trigger the question.
Closing Thought
Manual work scales by consuming more people.
Automation scales by preserving their attention.
The purpose is not to remove humans from the system.
It is to place them where their judgment matters most.
Automate the repetition. Preserve the thinking.
The Work That Should Have Taught the Machine
I have been the person who copied files into a Docker container one at a time.
Month after month.
I have been the person who manually applied Windows updates across a fleet of more than one hundred laptops.
I have walked through the same installer repeatedly.
I have watched the same progress bars.
I have answered the same prompts.
I have verified the same settings.
None of that work was beneath me.
But much of it should not have continued requiring me.
Every repeated action was evidence that the process had become predictable enough to capture.
The real failure was not that the task existed.
The failure was allowing the task to remain manual after its pattern was understood.
Speed Is Not the Primary Benefit
Automation is often justified with time savings.
That is useful, but incomplete.
The greater benefits are:
- Consistency
- Repeatability
- Reliability
- Auditability
- Scalability
- Reduced fatigue
- Fewer preventable errors
A person may complete the task faster once they become experienced.
But experience also creates overconfidence.
The person begins to anticipate the next step.
That anticipation can increase speed.
It can also reduce attention.
Automation performs the same validated process every time.
That makes the result easier to trust, compare, and support.
Runbooks Become Scripts
A mature workflow often begins as documentation.
First, someone discovers the steps.
Then they write them down.
Then others repeat them.
Once the process becomes stable, the runbook becomes a candidate for automation.
The progression is natural:
Observation.
Documentation.
Standardization.
Automation.
Monitoring.
Improvement.
A script should not be a collection of mysterious commands.
It should be an executable form of a process the organization already understands.
That is why documentation and automation belong together.
A script without explanation becomes another dependency.
A documented automation becomes institutional knowledge.
Infrastructure as Knowledge
Automation is not limited to scripts.
Terraform captures architecture.
Configuration management captures operational standards.
CI/CD captures deployment practice.
Scheduled tasks capture timing and repetition.
Lambda and EventBridge capture event-driven behavior.
Container definitions capture runtime expectations.
Each one converts human memory into repeatable execution.
That matters because memory is fragile.
People forget.
Teams change.
Engineers move on.
Automation preserves the process in a form the organization can inspect, version, test, and improve.
The best automation does not merely execute work. It preserves how the organization learned to do the work well.
Errors Move Upstream
Manual processes discover errors during execution.
Automation gives us the opportunity to discover them before execution.
A good automated process validates prerequisites.
Checks permissions.
Confirms destinations.
Detects missing files.
Rejects invalid inputs.
Stops before causing damage.
Records what happened.
Reports failure clearly.
That shifts error handling from improvisation to design.
The mistake is no longer discovered after the wrong driver has been installed on thirty laptops.
It is prevented because the workflow checked the package before deployment began.
The engineer spends effort once to protect every future run.
Automation Must Remain Understandable
Automation can remove toil.
It can also hide complexity.
A process that no one understands is not truly reliable simply because it runs automatically.
Every automation should answer:
- What does it do?
- Why does it exist?
- What inputs does it require?
- What systems does it affect?
- What happens when it fails?
- How is it stopped?
- How is it rolled back?
- Who owns it?
- How is success verified?
Automation without observability creates silent risk.
Automation without documentation creates dependency.
Automation without ownership becomes abandonment.
Human Judgment Still Matters
Some steps should remain human.
Approval of destructive actions.
Interpretation of unusual results.
Decisions involving ethics, risk, or incomplete context.
Communication during major incidents.
Automation should create guardrails around judgment, not eliminate judgment where it is still required.
The strongest systems combine both.
Machines handle repetition.
People handle meaning.
Closing Thought
The goal is not to automate everything.
The goal is to ensure that people are not spending their best attention on work that no longer requires it.
A mature engineer does not ask how much work can be automated. They ask how much human judgment can be protected.
Automation Exists Everywhere
Automation is not unique to software.
Pilots use checklists to standardize critical decisions.
Surgeons use protocols to reduce preventable variation.
Restaurants use recipes to reproduce quality.
Factories use jigs to guide precision.
Parents create routines because predictable structure reduces friction.
Organizations create templates because starting from a proven foundation is safer than rebuilding from memory.
In each case, knowledge has been captured so the result does not depend entirely on someone remembering every detail at the right moment.
That is automation in its broadest form.
Automation is captured knowledge executed consistently.
Checklists Are Human Automation
Not every automation requires code.
A checklist automates memory.
A template automates structure.
A standard operating procedure automates sequence.
A calendar reminder automates timing.
A naming convention automates interpretation.
These tools reduce cognitive load even when a person still performs the work.
The principle is the same.
Remove unnecessary decisions so attention remains available for the decisions that matter.
Automation Protects Creativity
Some people fear automation because they believe routine creates familiarity and familiarity creates expertise.
That is partly true.
Repetition can teach.
But once the lesson has been learned, continued repetition may stop adding value.
At that point, the task begins consuming the same attention that could be used for exploration, design, and discovery.
Automation does not reduce creativity.
It protects creativity from being buried beneath routine.
The person no longer spends the morning generating the report.
They spend the morning interpreting it.
They no longer copy the files.
They improve the pipeline.
They no longer patch one machine at a time.
They investigate why the environment remains difficult to maintain.
Automation gives people room to ask better questions.
Consistency Is a Form of Care
A consistent process respects the people who depend upon it.
Customers receive the same quality.
Engineers receive the same signals.
Auditors receive the same records.
Support teams receive predictable behavior.
Consistency reduces surprise.
That makes systems easier to trust.
Automation therefore connects directly to reliability.
Not because automated systems never fail.
Because they fail in ways that are easier to observe, reproduce, and improve.
Automation Should Remove Burden, Not Responsibility
A dangerous automation allows people to stop understanding the outcome.
A healthy automation reduces manual effort while preserving accountability.
The engineer still owns the result.
The organization still owns the risk.
The human still decides whether the automated action remains appropriate.
Automation should eliminate repetition.
It should not eliminate responsibility.
The Human Test
Before automating a process, ask:
- What burden will this remove?
- What errors will it prevent?
- What attention will it return?
- What new risks will it introduce?
- Can a person understand and override it?
- Does it preserve the right human decision points?
- Will the people affected by it be better off?
That final question matters.
Efficiency alone is not enough.
The automation should improve the lives of the people who use, support, and depend upon it.
In Practice
- Identify repetitive work that follows stable rules.
- Document the current process before automating it.
- Remove unnecessary steps before encoding them.
- Add validation before action.
- Log every significant result.
- Make failures visible.
- Preserve approval where judgment is required.
- Test rollback and recovery.
- Assign ownership.
- Review the automation as the environment changes.
Do not automate a broken process merely because it is repetitive.
You will only make the failure happen faster.
Questions to Ask Yourself
- Am I repeating work that has already taught me everything it can?
- What mistakes occur because this process depends on attention?
- Can the process be simplified before it is automated?
- What knowledge should be captured?
- What judgment must remain human?
- Who benefits from the time and attention returned?
- Will this automation still be understandable after I leave?
Closing Thought
The highest purpose of automation is not to save time.
It is to preserve human attention for problems worthy of human thought.
Automate what repeats so people can improve what changes.
Founder's Commentary
People Were Never the Problem
People often assume that engineers automate because they dislike repetitive work.
That was never my motivation.
I automate because I hate watching intelligent people spend their lives doing work that a computer should have been doing all along.
Over more than twenty years in IT, I have copied thousands of files by hand.
I've updated fleets of laptops one machine at a time.
I've walked through endless installation wizards, clicked the same buttons hundreds of times, and waited for progress bars to crawl across a screen while knowing there had to be a better way.
At first, repetition feels harmless.
Then something begins to happen.
Your brain gets ahead of your hands.
You stop reading the screens because you've already seen them a hundred times.
Your thoughts drift toward dinner, tomorrow's meeting, your kids' soccer game, or the project waiting for you after this one.
I call this Thought Rot.
Not because you've become careless.
Because you've become human.
The brain is remarkably good at recognizing patterns.
Unfortunately, it is equally good at assuming the next step will always be the same as the last.
That is where mistakes are born.
A skipped checkbox.
The wrong driver.
A forgotten reboot.
A file copied into the wrong directory.
Most mistakes aren't catastrophic.
They're interruptions.
And interruptions destroy momentum.
Once you've broken your rhythm, it takes real effort to find it again.
Automation isn't about replacing people.
It's about protecting people from work that doesn't deserve their attention.
A computer never gets bored.
It never wonders what it wants for lunch.
It never rushes because it's Friday afternoon.
It simply performs exactly what it was instructed to perform.
Every.
Single.
Time.
That consistency allows people to do something computers still struggle to do well.
Think.
Solve new problems.
Design better systems.
Ask better questions.
When I automate a task, I'm not trying to eliminate a job.
I'm trying to give someone their mind back.
Every script I write captures a little piece of experience.
Every workflow removes another opportunity for fatigue to create an error.
Every automation becomes another engineer working beside me while I move on to something that actually requires judgment.
That's the part people often miss.
Automation isn't about making people less valuable.
It's about making human attention more valuable by spending it where it matters most.
If a computer can perform the task reliably, let it.
Save your best thinking for the problems only people can solve.
Looking back over my career, I do not remember every script I wrote, every workflow I automated, or every deployment I simplified.
What I remember are the people who no longer had to spend their weekends babysitting servers, manually copying files, or repeating the same mistakes because a computer could do the work instead.
If the best automation is invisible, then perhaps the best compliment an engineer can receive is that nobody noticed the work anymore.
They simply noticed that life became a little easier.
When I automate a task, I'm not trying to eliminate a job. I'm trying to give someone their mind back.
Related Principles
Continue the idea.
These Principles share themes with Principle XXIV.
Principle VIII
Practical Beats Clever
Clarity, maintainability, service, and choosing solutions people can understand and sustain.
Read Principle VIII →Principle XII
Build for Tomorrow
Long-term thinking, adaptability, extensibility, and decisions that future people can live with.
Read Principle XII →Principle XIII
Quality Compounds
Small improvements and small compromises both accumulate; quality is the result of repeated choices.
Read Principle XIII →Principle III
Understand Before Optimizing
Root-cause thinking, measurement, troubleshooting, constraints, and separating symptoms from causes.
Read Principle III →