In DevOps, a recurring manual step is often treated as a defect. Teams can move straight to discussing an implementation because “automate everything” has been repeated as good practice for years.
I do not consider “automate everything” a sign of mature engineering. Each proposed automation needs a business case that accounts for the work before implementation and the ownership after launch.
The examples below show how I make that choice in practice.
Automating Instead Of Understanding Total Cost Of Ownership
Total cost of ownership (TCO) covers the period from the first discussion about a solution until the resulting code is retired. An implementation ticket records only a part of that period.
On one project, we rotated credentials used for AWS SES. Generating a replacement in AWS was straightforward. The new value then had to be entered into a third-party tool through its admin dashboard because the tool provided no API for the change.
End-to-end automation would have required a browser job with access to an admin account. That job would depend on a user interface we did not control. A dashboard update could break the rotation and leave an engineer repairing browser code before the credential could be changed.
Several people still pushed for it. The words “credentials” and “security” made a manual step feel unacceptable, while the days needed for browser automation attracted less concern.
I pushed back and put the process in a runbook triggered by a monthly calendar event. The rotation took about ten minutes and was one of fewer than ten items in our monthly operational review. I used the 80:20 rule to decide which recurring work deserved automation, and this task stayed manual.
A full year of rotations would have taken roughly two hours. The project was not mature and died after six rotations, so the manual process consumed about one hour in total. Several days of browser automation would have been discarded with it.
Had the browser job failed during those six months, someone would have opened unfamiliar automation before completing a ten-minute task. Repairing it once could have cost more time than every manual rotation the project needed.
In my experience, less experienced engineers are often the most confident advocates of “automate everything.” Engineers who have inherited scheduled jobs after their authors left tend to include that repair work in the original estimate.
A senior engineer should be able to explain why a manual process is the better decision even when automation is technically possible.
Automating Instead Of Expecting Ownership
On another project, someone proposed automated reminders that would nudge employees to complete routine actions. The idea became much larger once we discussed how the system would know that someone had finished.
To stop reminders after completion, we would have needed a reliable status for each action and a way to correct it. That would have made the proposal an internal workflow tool rather than a notification.
I preferred to abandon the idea. Following through on assigned work is something we start learning in primary school, and adults at work can use calendar reminders without a second system from DevOps.
Automated reminders can earn their cost when a missed compliance deadline has a financial consequence and the organisation needs evidence of completion. This proposal addressed no comparable risk and used notifications to solve an ownership problem.
Automating Before The Process Is Stable
A representative case is the first few customer environments provisioned by a startup. After the first environment works, turning its commands into a self-service pipeline can look like an obvious next step.
The next customer may require its data in a different region. A pipeline modelled on the first setup now needs a branch, while the team still does not know how much of the original process will survive another onboarding.
I would keep those early runs in a runbook and update it after each one. When the same inputs and sequence survive several customers, the team has a process worth putting behind a pipeline.
There may still be one dangerous step worth automating immediately. A small check that confirms the target account and region before Terraform runs can prevent a costly mistake without encoding the rest of an onboarding process that is still changing.
Choosing What Not To Automate
Before opening a repository, I check how often the task actually occurred and how long each run took. I put the manual work on a one-year basis:
annual manual TCO = cost per run x expected runs per year
The automation estimate should come from someone willing to own the result after launch:
automation TCO = discussion and design + implementation + ownership until retirement
I compare the figures over a realistic project lifetime rather than giving an immature product a five-year horizon because the automation needs one to pay back. I also account for a real failure risk in the manual process; discomfort with a word such as “credentials” is not itself such a risk.
Making an internal process look shiny is not enough reason to build it. In the SES example, a browser bot would have produced the same credential change as a ten-minute calendar event without making better use of the team’s time.
Being senior sometimes means setting aside a preached good practice when it does not make business sense.