Automation saves time and toil when performing a task, and we all appreciate that. This is only one frame for justifying automation but it limits view of other opportunities.
I love how automation transforms the tedium of work into puzzle-solving. Early in my career, I learned that management would value puzzle time (automation work) by pointing out a greater benefit for the effort than the time spent. (Aim for minimal time investment without sacrificing opportunities or incurring hidden costs like a high maintenance burden.)
Folks enjoy citing XKCD 1205 in automation discussions because it does a great job illustrating the opportunity time cost of automation. The time spent to code a new solution for an already solved problem doesn't help solve business goals until after the investment pays off.
What's automation anyway? I'd call it "software that reduces the amount of effort humans need to put in to get a job done". It replaces people work with CPU work.
As I continued my journey as a developer, I found that the cost/benefit time ratio around automation didn't line up with my thinking. Time trade-offs are essential, but there are more variables in the trade-off equation than time--other ways of recouping effort. A particular automation may have other goals than time-savings.
Planning for a big push
Perhaps the usual routine doesn't deserve automation. What if your team plans a sprint next month, focusing everyone's effort on a big change? The trade-offs are different: Increasing the frequency of a task and the number of people to onboard to a task both change the math, raising the value of automation. A bit of scripting here also improves the chances the team meets a time-bound goal.
This kind of automation makes the most sense when swarming on a specific task, such as updating code to use a new logging library or migrating data between systems. This may represent a one-time need, so build with minimal flexibility and worry more about good error messages than over-all maintainability. (This is a good use for a shell script shared, maybe not even committed to source control.)
Hiding complexity
Folks need to do perform complex tasks but workflow automation can simplify the details. You don't need to ask everyone to carry the full cognitive load when tools can do more of the lifting. It also provides paths to onboard folks to the team in stages. How fast can folks be productive in your environment? For "new person job satisfaction", it is best to measure this in hours or days instead of weeks.
More persistent automation like this is an abstraction layer to hide a mess.
Reducing cognitive load helps makes a complex system more approachable. More than a simplification in performing the task, it provides the vocabulary for non-experts to discuss the process. When folks have the ability to communicate about a task, new opportunities for collaboration open.
What do you do every day?
In the last month, I've given thought to the developer superpower of "defining the job you want". Automation is often thought of as a way to create more space to do the job you already have, but it is also a way to redefine the job. You can reinvest the time gained from automation on improving the automation, perhaps even expanding the scope of what the task achieves for your team. As a software developer, maintaining evolving software is more satisfying than turning a crank every 5 minutes!
The Checklist
When I think of automation now, I consider these factors:
- Will it save time? When will the up-front investment pay off?
- Will it help others contribute in a complex process?
- Will it make discussing a big, complex system easier, leading to better high-level decisions?
- Will it create space for more interesting activities?
- Will it replace existing activities with a style of work I prefer?
Don't limit your thinking about the time payoff of automating something, but do consider all the relevant trade-offs.
Do you have a favorite XKCD comic that helps you think about automation? Let's talk about it!.
Author's Context: I’ve worked on products that can be used to help automation projects, such as Google Cloud Run, Scheduler, and Workflows. Within my organization, I’m currently arguing for the need to use more automation to scale our code review and policy enforcement practices.
Additional Credits
Photo by British Library on Unsplash
Thanks to explain xkcd for XKCD alt text (not to be confused with XKCD hover text, which you get by visiting xkcd.com).
Top comments (2)
Great article! I'd also consider personal development as a factor. I realise there are pros and cons, but at a very simplistic level if learning X is a good thing (for you, your role, your team, ...) then learning X by automating Y is literally killing two birds with one stone, modulo the things you've already mentioned, of course :)
Hi Paul, thank you!
That's a great point. It also goes to the question of "how to automate" once you've got your "Why automate?" answered.
In an engineering team context, this can be more than personal development: a series of small, fast, successful automation projects is a great way to influence more broader adoption of a technology you value.