Your team has a backlog of recurring manual operations tasks and limited engineering time. How do you decide which ones to automate, which to leave manual, and which to remove the need for entirely?

## Three outcomes, not two The framing that separates a strong answer from a weak one is that "automate it" is one of three options. **Eliminate.** A surprising share of recurring operational work exists because something upstream is wrong: a service that needs a weekly restart, a certificate nobody automated the renewal of, a config that must be hand-copied because two systems disagree on a default, a capacity ceiling that requires manual intervention every launch. Automating these makes them cheap and permanent. Removing the cause makes them zero. Elimination should be checked first for every item on the list, because it is the only option with no ongoing cost. **Automate.** The task must genuinely recur, the decision inside it must be expressible, and the payoff must beat the total cost of ownership. **Keep manual, but make it good.** Documented, rehearsed, and supported by tooling that does the dangerous parts — while a human retains the decision. ## The arithmetic, and its limits The naive model is: `frequency x handling time x horizon` versus `build cost + maintenance`. A task consuming two hours a week is roughly a hundred hours a year, which comfortably justifies a week of engineering. A task consuming two hours a quarter does not. Two corrections matter. First, **maintenance is not free** and is routinely omitted: every automation is a system with dependencies, credentials and assumptions that rot. Budget for it as an ongoing tax, not a one-off. Second, **risk is a multiplier**. A rare task that can cause an outage when performed badly — a failover, a schema change, a certificate rotation — may deserve tooling out of proportion to the time it consumes, because the value is consistency and blast-radius control rather than hours saved. ## Why some tasks should stay manual The senior half of this answer is knowing where to stop. - **Rare plus destructive.** Automation exercised twice a year is stale automation. Its dependencies have moved, its credentials have expired, and the person who wrote it has left. At 3am nobody trusts it and someone does it by hand anyway — badly, under pressure, having also lost the practice. Prefer a rehearsed procedure plus a tool that performs the fiddly steps under human control. - **Judgement-heavy.** If the hard part is deciding *whether* to act rather than *how*, automate the how and keep the whether. Most bad auto-remediation stories start with automating a decision that needed context. - **Irreversible.** Anything that destroys data or capacity in a way you cannot undo deserves a human confirmation for a long time, regardless of frequency. - **Not yet understood.** Automating a procedure you do not fully understand encodes the misunderstanding and makes it fast. ## Self-service is usually the best value Before reaching for a closed loop, ask who is asking. If the work arrives as requests from other teams, the highest-leverage move is not to make your execution faster but to remove yourself from it: expose the action with its safety checks built in so the requester performs it. This is far cheaper than a control loop, it scales with demand rather than with your headcount, and it forces you to build exactly the guardrails a closed loop would later need. Beware the anti-pattern of moving toil rather than removing it — automation that makes your team's work disappear by pushing manual steps onto another team is not a win, it is an accounting trick. ## Keeping rarely used automation honest If you do automate something rare, it must be exercised on a schedule; otherwise its next run is its first test, during an incident. Run it periodically against a non-production target, or fold it into a rehearsal, and treat a failed exercise with the same seriousness as a failed deploy. Automation you cannot demonstrate working this quarter should be assumed broken. ## The organisational view At scale this becomes a portfolio question. Every automation has an owner, a maintenance cost and a decommission path; unowned automation with production credentials is a liability, and periodically retiring automation whose task no longer exists is part of the job. It is also worth measuring: if the same category of task keeps producing new manual work, the answer is upstream in the platform, not in one more script. ## How to answer in an interview Give the three-column framing, do the arithmetic out loud with a concrete example, then spend the rest of the answer on where you would deliberately not automate and why. Ending on "eliminate first, self-service second, close the loop only where frequency and confidence justify it" shows you have owned this portfolio rather than read about it.