Automation saves time and toil when performing a task, and we all appreciate that. This is 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.

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!.

Additional Credits: Thanks to explain xkcd for XKCD alt text (not to be confused with XKCD hover text, which you get by visiting xkcd.com).