Automation as Time Travel

Time is the resource we have the least of, that we can never get back, and that is most equitably distributed - we all have 24 hours in a day. Technology can return time to us. If we organize it correctly, it can even dilate time - go slower so we can go faster. To understand this, we must see time as children do. We can describe their impression of time with two questions, best imagined in a somewhat high-pitched, cranky voice.

The first question is, "are we there yet?" This question, familiar to any road-tripping parent, asks how long until the destination is reached. What is the gap between our current state and the future reward of an accomplished goal? 

The other question, expected from a tot who just got a talking-to, is, "can I go now?" The tot wants to move away from the current location, perhaps to play outside. In the adult context, I am rooted to the spot waiting for a machine to request the next bit of input. The software can be doing all sorts of things "for me," but if I have to remain local to press the "y" or trigger the next set of commands, my opportunity to reclaim time is limited. 

In my experience, the second question is more important than the first. Even in the road trip example, the child's complaint is sitting in their seat rather than distance to destination. If they could run around and play for three hours and then discover they are at the destination, they would be happier. The issue is less about time than it is about attention. To borrow a phrase from childcare, we "babysit" our machines, which is neither productive nor fun. 

This difference is what I call "perceived slowness" - when you ask me to "please wait," all that time is annoying and keeping me from my next task. Perceived slowness is the worst of both worlds: I am not contributing to the first task, and my others gather dust while I am on standby. 

What is the solution? Let it run on its own. Disconnect the issue of how long the process takes from how long I need to work on it. Phrasing it a different way: make it not my problem. 

One way to do this is to move my required inputs to the front of the process. Collect what you are likely to need in advance and release me with a promise of future communications. For example, if I am ordering goods on Amazon, I select products, add them to my cart, and confirm the order. I am not asked to "please wait" while the warehouse finds and packs the goods or UPS ships them across the continent. That latter part is in parallel with my doing other things. 

Another solution is releasing customers to communicate asynchronously with the next step without feeling they are bottling up the process. For example, about 20 years ago, Sears studied answering customer service inquiries using AOL Instant Messenger (did I mention this was 20 years ago?) and compared it with live telephonic support. There were two findings. First, customer service representatives could handle about eight times as many customers in a day when using IM vs. those on the phone. But the other result was a much higher satisfaction rating among customers using IM. 

Unlike some more recent messaging-based customer service experiences, there was a very forgiving timeout for the customer to remain present. Because the medium was asynchronous, people did not feel they were on standby while the rep would look up an account or other such things. As a result, one did not get the dreaded timeout message of the agent abandoning you because of nonresponse. 

This freedom to "leave the car" permitted people to engage in other activities. The asynchronicity allowed them to have fun or find peace during their service experience, rather than growing even more frustrated (you usually don't call customer service when having a good day.)  

I've been surprised by how many automatic processes are slower - in elapsed time - than a human would be. Multiple phenomena drive their slowness. One is that automation scripts are almost always single-threaded: they do one thing at a time. Most of the individual steps are usually not dependent on the immediately previous. Their step-by-step construction is to keep things simple, like a checklist. 

Another phenomenon is that the automated process will almost always do every step without fail, even if some are not strictly necessary. For example, in many continuous deployment environments, all the tests run - and must pass - before code goes into production. In contrast, experts will use their judgment to determine whether a particular step could be done differently or skipped altogether. 

Other reasons exist, but they boil down to the same consideration: we want to depend on this automation to generate the result consistently, so we don't have to worry about it anymore. We must trust in the reliability of the result. The issue isn't about technology per se: we would need confidence in any human to whom we delegate a task. In this way, trust is the essential job of a good robot. 

The disconnect between perceived and elapsed time means the user can go faster even when the machine runs slower. Once the task no longer requires my attention, I am less sensitive to how long it takes. 

The remarkable result is that a machine that does a task more slowly than a human saves time - as long as it is reliable. Five hours for a computer is a good trade if it takes away one hour for me. And as we add more robots, this leverage goes up. 

In this way, people creating automatic processes can offer time travel as a service. By introducing reliable mechanical methods, they develop trust, returning time to human customers. By not having to "babysit" the process, one can focus elsewhere. 

As a practical matter, that means the first job of a time-traveling robot is to be predictably reliable. The machine must offer trustworthiness at the front end and deliver it on the back end. Before the automated process begins, the customer profits: they control what the result will be and how the machine gets there. Even if they choose not to exercise change authority, greater transparency lowers the barrier to the customer's trust. 

The system should make sure it cannot error out in unexpected ways on the back end. Being able to roll back a half-committed transaction, having reasonable "try again" fallbacks and communicating issues promptly are all part of fulfilling this trust contract. 

This predictability is an area where no-code tools can shine. Their human-accessible interfaces mean that even when a delegated expert builds the process, the business customer has an opportunity to understand the inner workings. When done right, the customer perceives these workings to be evident because it reflects their process and expertise. 

And we can add speed later as the product earns trust through producing reliably. Once we walk, we can start to run. I've found, however, that many processes that operate slowly but autonomously are "good enough." Most of the time, we return more time to people by expanding the range of methods we move to automatic operation. 

Proceed slowly - reliably - to go fast. Such is the first law of the time-traveling robot. 

Are we there yet? Perhaps not, but thanks to the automation, I can go now. 

Photo by Djim Loic on Unsplash