Successful automation is all about trust
What if you had a single place where you could manage data, and the tool you used would automatically take care of all the translation in the background?
June 15, 2015
Believe it or not some people don’t trust automation. Shocking, I know. They’re afraid of the unknown -- or worse, that robots will take all our jobs and we will all end up subservient to the will of the supreme robot. Putting robot world domination aside, the most realistic pushback to automation is some folks simply don’t trust something that they can’t see. We’ve all probably seen that co-worker that blankly stares at the screen “just to make sure nothing bad happens,” minutes of his life ticking away as the installation progress bar creeps by.
We’ve all been there at some point but it’s important to realize just how much time we’re wasting by hovering over an automated process. Automation is here to save time, not to make us all zombies just staring at our screens while the automation does all the work. Automation exists to handle all that mundane stuff to allow us to do more important things with our time, things we actually have to use our brains for. Automation was not meant for you to milk the clock while acting like you’re doing actual work, then taking all the credit for that cool script you found online. We must learn to trust that automation is doing what we expect.
How do we show people that automation can be trusted? Through consistent, predictable and error-free results.
If done properly, this is what automation does and what makes it such a strategic advantage for not only engineers in the trenches but to managers, directors, executives and ultimately the business as a whole. For an automation project to be successful and loved by all requires a team of people that “get” automation. Organizations need people who understand that manual processes are not only laborious time-drains, but also introduce potential human error. To be successful, automation projects must be properly designed else the project will be introduced, have multiple issues and will be marked as a failure even once all the bugs have been fixed.
The design of an automation project is of utmost importance. The general rule of automating just about anything is that time will be sacrificed up front so it can be recouped later on. It is this upfront time that is crucial to fully understanding the entire process from soup to nuts, setting standards and designing the entire orchestration of events that must happen. If you want your organization to permanently have a bad taste in its mouth for automation, the best thing can do is to haphazardly throw together some automated solution. The entire process must be intimately understood and all of those minor details that you might have been able to skip over when manually doing things are important now.
Have you ever been somewhere where some major piece of automation destroyed something crucial to the organization? How did the organization handle it? Did they get out the pitchforks and demand that this evil automation be burned at the stake? Or did they understand that mistakes happen and it’s not the actual automation that caused the problem but perhaps poor design, a lack of planning, or a human mistake? This is what separates the truly progressive companies from those stuck in the past. They seem to inherently know that automation is an important part of business and without it the business could lose its competitive advantage in the marketplace. These are the companies that “get” automation and the kind of companies we should all strive to be a part of.
These kinds of companies trust automation. They trust the results that automation can deliver and aren’t swayed by small setbacks. I once heard a saying that automation is the best way to fail at scale. This can’t be more true. When using automation, it’s either all right or all so very wrong. But successful organizations don’t see a large scale failure as the fault of the automation itself. The failure was the spark that lit the automation fire. Automation was simply the gas that turned the spark into a raging inferno. Gas, in of itself, doesn’t cause a fire. It’s the spark that’s the ignition point. The spark is the root issue and is one that all organizations must strive to tamp out before the fire goes out of control.
Remember the next time you’re at home sipping a mimosa as your co-worker monologues against the evils of automation while manually setting up a server and watching the pretty progress bars goes by. It is at that moment you will appreciate what automation has done for you and your organization.
About the Author
You May Also Like