In Ops, when should you build automation?

Today, it’s easier than ever to build automation whenever you need one (or before you actually need one). So when do you build automation and when do you wait?

The thought process here was triggered by this excellent XKCD post about the promise of building automation versus the reality of the work required to build a minimum viable automation.

It takes some amount of work (at the beginning, often an unknown amount of work until the scope is established) to design and build an automation, so the first step here is to build a solution to a valuable problem.

What’s a valuable ops problem?

This sounds like a philosophical question rather than a hard and fast rule and the solution varies by organization.

My take on it goes this way:

• if your team makes decisions that depend on knowing an answer to a question,
• and that question can be answered more quickly and accurately using automation,
• and the algorithm for the automation is easily understood by people on the team (even those who do not build automation)
• and the automation removes other potential problems

It’s a great candidate for a valuable ops problem to be solved. It also bolsters the argument for this problem if the team wanting to solve it assigns a high value to resolving the issue.

One such example is a “round-robin” lead distribution among sales teams.

1. It’s important to the sales process that salespeople understand who owns an account and that this ownership is set quickly
2. If the goal is to distribute accounts evenly, the automation can select from a list of salespeople and deliver the next account to the next person
3. The algorithm is easy to quality check because if the person before me got a lead, I know as a sales rep that I get the next lead
4. If I trust that the leads are delivered evenly, I’m going to worry less about the lead flow I’m getting as a rep

What’s a less valuable Ops Problem?

It’s easy to confuse valuable ops problems with less valuable problems that you also hear about frequently. At first glance, these outcomes look similar.

Compare the previous example of sales account assignment with a hypothetical automation that sets a default on an account field that we expect account executives to complete.

This is not a good process to automate because the purpose of the activity is to get sales reps to review the account and set a value.

If we automate the action, we resolve one problem (accounts without mandatory fields set) but remove the pressure on the sales team to complete an action in the sales process in a required period of time.

So, even though:

1. The team makes decisions based on this process
2. The question can be answered based on the answer
3. The algorithm is easily understood by the team

This is an ops problem you would choose to leave unsolved.

Principles for selecting valuable problems

The Eisenhower Decision Matrix, named for the former president, helps to evaluate the kind of ops problems you might want to automate.

Contrary to what you might think, the most important and urgent items are not the best candidates for automation if they need to get done immediately unless the important and urgent items have already overwhelmed the team.

Automation can make these things more effective:

• deciding the order in which to do things
• for delegation, making that action automatic
• for elimination, automatically completing lower-value tasks so that they don’t need to be done

Automation to complete the most urgent and important items needs to be a combination of targeted and specific items so that you can find the right problems to solve, balancing that with the time it takes to get them done.

What’s the takeaway? Automation is a valuable tool for any ops pro, and it’s more effective when that automation also solves a critical problem for the organization. When you automate, check that solving this problem will deliver results.