“This is so tedious. I should automate it!” has been a recurring thought for me these past couple of weeks.
And if you’re a software-engineer-turned-leader, or even just one who works adjacent to software engineers, you’ve certainly faced the same pull.
But even the most repetitive, brain-numbing tasks aren’t always good candidates for automation.
Here are a few indicators it might not be a good time to automate:
⛔ When the process is rarely performed. (See https://xkcd.com/1205/)
⛔ When the process is unclear, uncertain, or full of exceptions. (See https://xkcd.com/1319/)
⛔ When the value of the process or output is in question. If you’re not sure it’s valuable, you’re likely to change it dramatically or stop doing it altogether before there’s any return on your investment.
⛔ When the output must be more reliable than the input currently is. If you have to manually fill in gaps or correct missing or incorrect data so that you can have the output you need, automating will just make it faster and more convenient to get the wrong answer.
What other indicators can you think of?
What might be some good reasons to override these indicators and automate anyway?
Leave a Reply