One of the first factors that emerge when you discuss building automations to make a team’s life easier is the potential time saved. You get there by multiplying the time saved by doing the task today multiplied by how often you do the task. This gives you a rough order of magnitude to estimate how much effort the solution might take to build before it’s not efficient.
When I fall into this line of thinking, two resources come immediately to mind. The first is this XKCD comic, which gives you a handy table to estimate time and effort:
The second is the Mythical Man Month by Fred Brooks – a classic example that adding more resources to a problem does not necessarily make it faster to complete.
Designing automation too often focuses on the time saved instead of other benefits. It assumes that resources (and compliant behavior and design) will be available to solve the problem in a way that makes sense.
Resource consumption and time saved miss this point: what’s the overall outcome of solving the problem?
When you need automation, ask these questions
Here are two ways to quantify the benefit of automation:
-
Is the value delivered by this solution significant? If we can’t quantify the benefit or if the value is uncertain, it’s hard to prioritize this solution even if it saves time or makes things easier.
-
Given what we know right now, how difficult is this to complete? The harder the effort to solve for this problem, the more benefit is required. And don’t forget that we might be missing some difficulty in the initial assessment.
-
A bonus question: don’t forget to ask why they want to do this.
With this in mind, many potential automations fall into a few buckets:
-
Yes, we should do that, and it’s hard to justify the effort
-
Yes, we want to do that, it makes sense from a value perspective, and we know how to do it
-
Maybe do it, if we can figure out how
-
Nope, not doing it, doesn’t make sense from value or cost standpoint
Applying this framework in practice
Using the 2×2 of difficulty (how hard is it to do) and utility (how much benefit does it deliver), we end up with a quick way to think about automations.
These are the most common buckets that show up.
Nope.
These items are high difficulty and low value delivered. When the team asks you to automate something they do in the browser that is difficult to script but relatively easy to do by following a few steps, it might fall into this bucket.
“Help me assess whether this prospect’s website has a staff page.”
Try not to do these things.
Why?
These items are low difficulty and low value delivered. However, there is often a hidden benefit in the proposal that needs to be uncovered to assess whether there is enough benefit or a low enough difficulty bar to approach this automation.
“I know this needs to be easier in Salesforce, because I do it a lot and it feels hard.”
Discovering the real story and diagnosing what needs to be done is important.
Possible.
These items are high difficulty and high value delivered. It’s usually easy to see that they will generate success if you can get them done in a reasonable amount of effort and time. I call these “possible” because they do not always make sense to complete even if they deliver value.
“I’d like to save time on this multiple-times-daily task because it will help me sell better and close more deals.”
One way to hedge your bets here is to find non-automated ways to improve this process and then automate it if the other benefits work (think of it as a prototype).
Yes!
These items are low difficulty and high value delivered. It would be great if everything fell into this bucket. They’re easy to do, so they get solved pretty quickly.
“When [an important thing happens], I’d like to get a message in Slack.”
One really good way to find new automation examples of this type? Ask yourself: is there a key event that’s easy to catch and has clear logic to follow when we find it? It might be simple to complete, but very high value to complete consistently.
What’s the takeaway? Ops teams can unlock significant value by pursuing automation. Your automation needs to solve important problems with the right amount of resources. By focusing on discovery, you’ll be able to identify the organizational benefits faster. (And hopefully, avoid building in the Why? and Nope. quadrants.)
