Innovation teams often see a problem and think that the most effective thing to do is to create a solution for it.
Often, this involves developing a solution that automates a task that previously had to be done manually by someone, or at least makes the activity significantly more efficient.
However, sometimes the time, effort and resources spent developing the solution to fix what in reality is a minor problem can be significant. And in many cases, developing this solution might result in new required steps and activities which now need to be performed, meaning that the time saved on not having to do the original task is more than taken up by the new activities, resulting in no overall time being saved.
For example, if you run a restaurant and someone asks for more salt on their food, you could:
- A: Realise that it takes about 10 seconds to pass someone salt, notice it happens several times a day, and begin developing a system and process to reduce this time required down to 3 seconds or less. Spend weeks developing and perfecting the solution. Then pass the customer the salt faster than ever before.
- B: Pass them the salt
Factor in the time required to not only develop the solution, but to test it, fix bugs and continue to maintain it over time, and this can end up taking more time than the original problem caused.
This can be especially true for people trying to develop a solution to their own “problems”, and people who have an engineering mindset.
One of the best visualisations I have found on the internet for this is by the web-comic xkcd, who often take challenges related to innovation and engineering, explained in funny stick-figure images.
Take for instance this representation of the time taken to save time by “automating” a recurring computer task by writing software to do it:
What makes it funny is how true it is in reality.
Not every problem makes sense to fix by investing a large amount of time into developing a solution.
Yes, if a task is done very frequently, and requires a lot of time each time to complete, then perhaps automating it might save time in the long run.
Fortunately, xkcd already worked out exactly how long it makes sense to invest in developing automation in order for it to save time overall in the long run:
Here you can see that if you have a recurring task that you need to do 5x a day, every day, and it takes 30 minutes each time it is completed, then that is 2.5 hours every day you take completing the task. If you could automate this task (with no maintenance required after completing it), then you could work on this task for 6 months and still save time in the long run….
But what impact would it have on everything else you need to do during those 6 months if you did nothing else but work on the automation?
You would get no other real work done!
And this becomes a significant problem for “problems” which are actually nothing more than annoyances. Activities that maybe take 5 or 30 seconds to complete. In most cases, investing days or weeks into creating a solution for them might not ever save any time overall.
And if you are trying to build a solution for customers, those customers might not even perceive the “problem” to be automated to be large enough to be worth the hassle and cost of paying for a new solution, let alone the disruption that comes with changing their current way of working.
Automation can make sense, when done correctly.
But it isn’t always the best solution.
Sometimes, instead of spending time making an activity as efficient as possible, it is better to just complete it. Execute, and then get on with the rest of the work.
Latest posts by Nick Skillicorn (see all)
- Self-Serving bias: Why you think nothing is your fault - August 9, 2023
- We are all sheep - August 2, 2023
- Planning fallacy: Why we are so bad at predicting how long something will take - July 27, 2023
- Pygmalion effect: The self-fulfilling prophecy - July 24, 2023