I love how many kinds of automation there are! One kind I rarely see is "autonomation", which is basically automating so that a failure prompts a human to fix

I love how many kinds of automation there are! One kind I rarely see is "autonomation", which is basically automating so that a failure prompts a human to fix something and then resume the automatic process. I don't see many people make these, but they are great for tasks that need to run constantly. You could (for example) make an ETL process that halts on errors, allows a developer to fix something, and then resumes right where it left off (rather than starting over from scratch, which would be like throwing out half-finished goods!) Another is the "incremental automation", where you start out with literally just a checklist of manual tasks, and you slowly automate one piece at a time over a long time. You only automate the pieces that produce the most value or have the most need, so you end up spending your time wisely. If you clock how long it takes to complete each time, you can plot the cost savings over time of your automation, justifying to the business dweebs why they should let you spend more time automating :-) Yet another is cost-benefit automation. Basically, don't automate it unless you can prove it's going to save you more money to automate it than if you hadn't. There are a lot of different kinds of costs and benefits, so this is more complicated than it seems, but it can be used to justify a costly automation effort (such as hiring an entire team just to do automation!) or reject one. Any time someone says they're going to manage some centralized service or team for a group of other teams, I ask them if they've done the cost-benefit analysis, and if they haven't, I pray for their users... In general, you should not try to automate things completely (which could be defined as "it not only runs by itself, but also fixes itself") unless there is a very clear cost-benefit. Automate small tasks and run those tasks individually, and if it's convenient, tie the small tasks together into larger automation chunks. About half of the more complicated one-liner shell commands that I run end up in my junk-drawer repo, and eventually I end up using them again. But my favorite kind is self-service automation. Bottlenecks are the worst! One person or team has to do things for everybody else? Make it self-service! Start by making the cheapest, crappiest, least-reliable, most-embarrassing solution that gives users the ability to do something themselves. Even if it stops working... you just go back to doing the original task for the users. You often hear "well we can hire button-pushers overseas for cheap!" as an excuse to avoid this, but then they're discounting the cost in time from the button-pushers not being efficient enough or misinterpreting requests, etc. Cost-benefit isn't simple! But self-service is (usually) going to give you back time, which is often worth more than money. (I think, anyway.)