Deciding what to automate is a scoring problem. Deciding how far to take it is a reversibility problem. Most failed automation gets the second one wrong.
Highlights
- Deciding what to automate is a scoring problem with five inputs, and frequency multiplied by time saved is only the first of them.
- Automation carries its own running cost, so a script that breaks quarterly and takes a day to diagnose has already consumed most of what it saved.
- Four rungs run from documented to scripted to triggered to self healing, and each rung is the test for the next rather than a stage to hurry through.
- Reversibility decides your ceiling on that ladder, which means a high scoring task can still be one that must never run unattended.
- A cloud engineer's resource cleanup and a platform engineer's provisioning flow can score identically and belong at completely different rungs.
- Work that gates other people carries a cost your own time tracking never sees, which is why platform tasks are consistently underrated by naive scoring.
- Scoring three candidates takes ten minutes and reliably disagrees with instinct at least once, which is the entire reason to do it on paper.
A team automated their certificate renewal. The script worked, saved roughly forty minutes a quarter, then broke four times in eighteen months as the upstream API shifted, each break costing most of a day because nobody remembered how the thing worked. Net effect was negative, and the renewals still happened by hand twice while somebody repaired the automation.
That is not a skill failure. It is a scoring failure, and it comes from asking only whether the task was worth the time. This post covers the five inputs that actually decide, the ladder that decides how far to take it, and then works three real candidates end to end, one each from a DevOps engineer, a cloud engineer, and a platform engineer. The three score similarly and belong in three different places, which is the point.
The decision rule
Automate a task when the cost of continuing manually, counting time, error rate, and growth, exceeds the total cost of the automation, counting build effort plus expected maintenance, then climb only as far up the ladder as the task's reversibility allows.
Two halves. The first decides whether. The second decides how far, and it is the half that gets skipped.
Why time saved is not enough
The familiar calculation says count how often you do the task, multiply by how long it takes, compare against the build cost, and automate if the numbers favour it. Reasonable, and it omits three things that determine real outcomes.
Error cost. A two minute task that goes wrong once a year in a way that pages someone is worth automating on those grounds alone. Consistency is frequently worth more than speed.
Growth. Anything performed once per server, per account, or per service scales with something you do not control. Ten minutes across five accounts is an hour; across two hundred it is a working week, and the naive calculation treats today's number as fixed.
Maintenance. The one that sank the certificate script. Automation is software, software rots, and anything depending on an interface you do not own will break when that interface moves.
In the wild
The maintenance term is the one people resist estimating, because putting a number on it feels like pessimism about your own work. It is arithmetic rather than mood. A script that breaks twice a year and costs three hours to diagnose is spending six hours annually before it has saved anything, so it needs to clear six hours just to break even. Ask what the automation depends on that you do not control. If the answer is a vendor API, a scraped output format, or an undocumented behaviour, weight the estimate up rather than down.
The five inputs that decide what to automate
Reversibility behaves differently from the other four. It does not change whether to automate, only how much autonomy the result may have, and that distinction is what the three worked examples below are built to show.
Watch out
Do not let the interesting candidate beat the expensive one. Technically enjoyable automation is rarely the work costing you most, and the correlation often runs backwards, since the tedious repetitive tasks are tedious precisely because they repeat, which is what makes them expensive. If your automation backlog is ordered by how appealing each item sounds, it is ordered wrong. The scoring sheet exists mostly to defend against that.
The ladder
Four rungs sit between a task somebody knows how to do and a system that handles it alone. Each is a real deliverable, and each is the test for the next.
Documented. The steps are written clearly enough that a colleague follows them without asking you. Nothing is automated and the value is already substantial, because the knowledge has left one person's head.
Scripted. One command a human runs deliberately, taking arguments, validating them, failing loudly. Most of the total value lands here.
Triggered. A schedule, event, or pipeline stage starts it. The code barely changes and the operational demands do, because now it runs unwatched.
Self healing. The system detects a condition and acts unprompted. This is where the marketing lives and where a minority of tasks belong.
./cleanup-orphaned-volumes.sh --account 1234 --older-than 30d
./cleanup-orphaned-volumes.sh --account 1234 --older-than 30d --applyThose two invocations are a rung two script in its entirety, and the shape matters more than the contents. The first reports what it would do and changes nothing, the second requires an explicit flag before anything happens, and a person chose the moment. Getting that shape right is what makes rung three safe later, because scheduling a script with no dry run and no argument validation is an incident waiting for a cron entry.
Watch out
Never skip a rung, and treat any plan starting at rung four as a warning. Each rung tests the one above it. If you cannot write the procedure down, you do not understand it well enough to script it and the script will encode your misunderstanding. If the script is not reliable when an attentive human runs it, a schedule does not improve it, it removes the attentive human. A self healing system that heals the wrong thing at three in the morning is almost always a rung two problem nobody solved.
Get the scripting rung solid first
Rung two carries most of the value and most of the eventual risk, which makes shell fluency the highest return investment in this whole framework. The Shell Scripts for Beginners course on KodeKloud covers arguments, conditionals, loops, functions, and file operations with hands on labs, which is exactly what a safe rung two script needs.
Three candidates, three roles, three answers
Now the part worth the reading time. Here are three real tasks, one per role, scored on the same five inputs. They land in noticeably different places.
The DevOps engineer, promoting a build artifact
The task is moving a container image from staging to production: verify the digest, retag it, push it to the production registry, update the manifest, open the pull request. It happens three or four times a week, takes about fifteen minutes, and is currently a wiki page.
Verdict. Strong, straightforward, and it can go all the way to rung three. Script it with the digest verification built in, then trigger it from a green pipeline rather than a schedule, so the event is a passing test suite rather than a clock. This is the uncomplicated case, and it is worth having one on the sheet so the other two stand out.
The cloud engineer, cleaning up orphaned resources
Unattached volumes, unassociated elastic IPs, snapshots past their retention window. Perhaps a couple of hours monthly across several accounts, and rising as the account count grows.
Verdict. The total is high and the ceiling is low. Everything about the first four inputs says automate this, and the reversibility score of one says it stops at rung three with a human approving the deletion list, permanently rather than temporarily. The right shape is a scheduled job that produces a candidate list and a report, and a separate deliberate action that acts on it.
That is not a compromise or an unfinished state. It is the correct final design for a task whose mistakes cannot be reversed, and recognising that early saves you from building a self healing cleaner that one day reclaims a volume somebody had detached for ten minutes during a migration.
The platform engineer, provisioning a new service environment
Namespace, RBAC bindings, image pull secrets, ingress, monitoring scrape config, alert routing, repository scaffolding. Perhaps three times a week, twenty minutes of hands on work, and it currently arrives as a ticket.
Verdict. The highest total of the three, and the naive calculation would have ranked it last, because an hour a week of your time looks unremarkable next to the DevOps candidate. What the scoring surfaces is growth, and what it still misses is the queue. Each of those tickets sits in your backlog for a day or more, so the real cost is engineer days of somebody else's blocked work per month rather than an hour of yours.
In the wild
A platform team scored their backlog carefully and put self service provisioning near the bottom, because it took twenty minutes and happened three times a week. What the score missed was that each request waited a day and a half in their queue, so the true cost was several engineer days of blocked work monthly rather than an hour of theirs. They built it anyway and the visible saving to their own team was small. The invisible saving to everyone else was the largest return of anything they shipped that year. If a task has other people waiting on it, weight frequency up, because the real cost is being paid by somebody whose time you are not measuring.
What changes at rung three
Promoting a script from something a human runs to something a system runs looks minor and changes four requirements.
Idempotency becomes mandatory. A scheduled job eventually runs twice, from a retry, an overlap, or a manual invocation during an incident. Running twice must be safe, which usually means checking desired state before acting rather than blindly applying.
Failure has to be loud. A script a human runs reports failure to a human watching. A scheduled script reports to nobody unless you built that. Silent failure is worse than no automation, because you now believe the task is handled.
Locking matters. Two overlapping runs against the same resource is a class of bug that appears under load, at the worst moment, and resists reproduction afterwards.
Credentials change shape. Your interactive session carried your permissions. A scheduled job needs its own identity, scoped to exactly what it touches.
Quick tip
Before promoting anything from rung two to rung three, run it manually twenty times over a fortnight and count the failures. If it failed twice because of a transient condition you shrugged at, that is a ten percent failure rate about to occur unattended, and nobody will be shrugging. The manual period is not ceremony, it is the only cheap way to learn what the script does on a bad day.
Move up the ladder with the right tool
Rung two in shell gets you far, and past a point you want something that describes desired state rather than steps, because that is where idempotency stops being your problem to solve. The Ansible Basics course on KodeKloud covers inventory, playbooks, modules, variables, conditionals, handlers, roles, and templates with browser labs.
Where automation reliably goes wrong
That last row deserves weight. Automation only one person understands has not removed a dependency on that person, it has moved it somewhere harder to see, and it surfaces while they are on holiday.
The scoring sheet
Copy this. Score one to five, apply the weighting, compare candidates against each other rather than against a threshold.
Score maintenance inverted, so five means almost nothing will break it and one means it rests on something volatile. Two rules travel with the sheet. Anything scoring one or two on reversibility stops at rung three with human approval regardless of its total. And anything scoring one or two on maintenance needs a named owner in writing before you build it, because unowned fragile automation is precisely the certificate script.
Applied to the three candidates above, the ranking is instructive.
Two of them tie on total and differ entirely on what you should build, which is the whole argument for scoring reversibility separately rather than folding it into one number.
Automate the trigger properly
Rung three is where automation meets your delivery pipeline, and doing it well means reusable workflows, scoped runners, and secrets that are not long lived. The GitHub Actions course on KodeKloud covers core concepts, reusable workflows, custom actions, self hosted runners, Kubernetes deployments, and security hardening.
Run it on your own backlog
Twenty minutes, and do it on paper before you open an editor.
Write down every recurring manual task your team performed last month without judging any of them, because the list is always longer than people expect and the filtering happens later. Then pick three that feel different from each other, ideally one that is obviously worth automating, one you have been avoiding, and one somebody else keeps asking for.
Score all three. Then, before looking at the totals, write down which one you expected to win. The disagreement is the useful output, and there is usually one, most often because growth or the queue behind a task was invisible to your instinct.
Now take the winner and ask which rung it currently sits on. If the answer is rung zero, meaning one person knows how, your next action is an hour of writing rather than a day of scripting, and that will feel like a step backwards while being the fastest available progress.
Finally, look at your lowest maintenance score and ask whether that candidate has an owner. If it does not, either name one or take it off the list, because building it is choosing to create a liability nobody is responsible for.
What you should be able to answer now
If the framework landed, four questions should have answers you can say out loud.
Which task on your backlog scores highest, and does that surprise you? If nothing surprised you, either your instincts are unusually well calibrated or the scoring was done to confirm a decision you had already taken.
Which of your existing automations would fail the maintenance test today? Most teams have at least one, and knowing which is the difference between choosing to keep it and being surprised by it.
Where is the highest thing you run on the ladder, and did it earn that position? Anything at rung four should have passed through rungs one to three deliberately rather than arriving there because it seemed impressive.
What are you running unattended that cannot be undone? This is the one worth checking this week. A scheduled job that deletes, scales down, or modifies data without a human in the path is a decision somebody made, possibly without framing it as one.
The certificate script from the opening failed none of the technical tests. It failed the maintenance question, and nobody asked it. Ten minutes with a scoring sheet would not have made the script better. It would have made somebody notice, before building, that it rested on an API they did not control and had no owner named to watch it.
Ready to Build the Skills This Framework Assumes?
Scoring tells you what to automate, and shell, configuration management, and pipeline automation are how each rung actually gets built. The Shell Scripts for Beginners course on KodeKloud covers the scripting rung where most value sits, the Ansible Basics course covers the declarative approach that makes rung three safe, and the GitHub Actions course covers triggering it all properly. Pick the rung you are weakest at.
FAQs
Q1: How do I decide what to automate first?
Score candidates on five inputs rather than one. Frequency multiplied by time is familiar and only the first. Add error cost, meaning what happens when a human gets it wrong, because a two minute task that pages somebody once a year justifies automation on that basis alone. Add growth, meaning whether the cost scales with accounts, services, or fleet size, because anything performed once per unit understates its future cost badly. Add maintenance, honestly estimated and subtracted, since automation depending on an interface you do not own will break when that interface moves. And add reversibility, which does not change whether to automate but caps how much autonomy the result gets. The practical test for maintenance is asking what the automation depends on that you do not control, and weighting your estimate up if the answer is a vendor API, a scraped format, or an undocumented behaviour. Compare candidates against each other rather than against a threshold, because the ranking is what you actually need.
Q2: What is the automation ladder, and why does skipping rungs fail?
Four rungs sit between a task somebody knows and a system that handles it alone. Documented means the steps are written clearly enough that a colleague follows them, which costs an hour and delivers more than people expect because the knowledge leaves one head. Scripted means one command a human runs deliberately, with argument validation and a dry run default, and this is where most total value lands. Triggered means a schedule, event, or pipeline starts it, which changes the operational requirements rather than the code. Self healing means the system detects and acts unprompted. Skipping fails because each rung tests the next. If you cannot write the procedure down you do not understand it well enough to script it, and the script encodes the misunderstanding. If the script is unreliable when an attentive human runs it, scheduling does not improve it, it removes the attentive human. A self healing system that heals the wrong thing overnight is almost always an unsolved rung two problem.
Q3: Can a task score highly and still not belong on a schedule?
Yes, and cloud resource cleanup is the clearest example. Unattached volumes and expired snapshots score well on frequency, extremely well on error cost, extremely well on growth as your account count rises, and reasonably on maintenance. Every one of those says automate it. Reversibility scores one, because deletion has no undo, and that single input caps the ladder rather than reducing the total. The correct design is a scheduled job producing a candidate list and a report, plus a separate deliberate action that acts on the list, with a human between them permanently. That is not an unfinished state or a compromise, it is the right final shape for a task whose mistakes cannot be reversed. Recognising it before building saves you from a self healing cleaner that eventually reclaims a volume somebody detached for ten minutes during a migration, which is exactly the kind of failure that destroys trust in automation for years.
Q4: Why do platform engineering tasks score badly on instinct and well on paper?
Because the naive calculation only counts your own time, and platform work is defined by other people waiting. Provisioning a service environment might take twenty minutes and happen three times a week, which looks unremarkable against a task consuming an hour a week. Two things are invisible in that view. First, growth, since provisioning scales with every new team and every new service while your headcount does not. Second, and larger, the queue, because each request sits in a backlog for a day or more before anyone starts it, so the actual cost is engineer days of blocked work elsewhere rather than an hour of yours. The practical adjustment is to weight frequency up for anything with people waiting on it, and to record the wait time alongside the hands on time. Any request arriving from outside your team, including access grants, environment provisioning, and anything with a ticket queue in front of it, carries this hidden cost.
Q5: What actually changes when I put a script on a schedule?
Four requirements move from optional to mandatory. Idempotency, because a scheduled job eventually runs twice from a retry, an overlap, or a manual invocation during an incident, so running twice has to be safe, which usually means checking desired state before changing anything. Loud failure, because a script a human runs reports to a human watching while a scheduled script reports to nobody unless you built that, and silent failure is worse than no automation since you now believe the task is handled. Locking, because two overlapping runs against one resource is a bug that appears only under load and resists reproduction. And a separate identity, because your interactive session carried your permissions while a scheduled job needs credentials scoped to exactly what it touches. The gate worth applying before promotion is running the script manually twenty times over a fortnight and counting failures, since a rate you tolerated while watching becomes a rate nobody is watching.
Q6: How do I stop my automation becoming the next maintenance problem?
Three habits, and the first carries the most weight. Name an owner in writing for anything depending on something you do not control, because unowned fragile automation is the exact shape that ends up costing more than the work it replaced. Second, keep the documentation rung alive after passing it, since automation only one person understands has not removed a dependency on that person, it has moved it somewhere harder to see, and it surfaces while they are away. Third, treat automation as software rather than as a solved problem, meaning it has tests where testing is feasible, it fails loudly, and it goes through whatever review process your code does. A useful annual habit is reviewing every automation you run and deleting what no longer earns its keep, because scripts accumulate and nobody removes them, and each one is a small ongoing liability whether or not it is still used.
Discussion