Autonomous IT

In this episode, Landon Miles discusses automation and common pitfalls to avoid. The four common pitfalls he identifies are: selecting the wrong tool, selecting the wrong problem, having bad mentalities, and not documenting anything. He shares anecdotes and insights to illustrate each pitfall and provides tips on how to avoid them.

Creators & Guests

Host
Landon Miles
Landon Miles is the host of the Hands-On IT podcast. Landon’s profound passion for technology isn't just evident in his voice, it’s apparent in how he breaks down cutting-edge tech trends, formats user-friendly tutorials, and gets into the weeds of the complexities of IT technologies. His approach makes the Hands-On IT podcast an essential resource for both seasoned IT pros and those new to the field, looking to enrich their tech experience. With a background that spans various facets of technology, Landon brings a wealth of knowledge and practical insights to each episode.

What is Autonomous IT?

Go from monotonous to autonomous IT operations with this series. Hosts from Automox, the IT automation platform for modern organizations, will cover the latest IT trends; Patch Tuesday remediations; ways to save time with Worklets (pre-built scripts); reduce risk; slash complexity; and automate OS, third-party, and configuration updates on all your Windows, macOS, and Linux endpoints. Automate confidence everywhere with Automox.

Landon Miles (00:01)
Hello and welcome back to the Hands-On IT Podcast. As always, I'm your host Landon Miles. This episode we'll be discussing automation and some of the common pitfalls and how to avoid them.

Today's podcast is part of Automox's Autonomous IT Podcast Network. Join us every Tuesday and Thursday for all things IT, automation, and cybersecurity. Let's get started. Now, in my opinion, there are four common pitfalls in the world of IT automation that I see people make and have made myself. Pitfall number one is selecting the wrong tool. One of the first things to consider when automating is leveraging the tools you already know and trust. Familiarity,

brings efficiency, but every tool has its limitations. Is it something that normal employees will interface with? It better be user friendly then. Is it something that will push along on the back end? You need to make sure it's reliable. So understanding these boundaries is key to ensuring your automated processes remain effective and don't become complex liabilities. Anecdote time. Many years ago at another company, and my team and I were trying to automate an internal forms of mission process.

do some data processing with it and send out an email to the proper people. Microsoft had just rolled out Microsoft Flow. I think they've recently changed it to Power Automate and it looked really neat. It was a no-code solution and had some drag and drop logic capabilities. At this time, Microsoft Teams was also brand new and this integrated directly into it with their Forms add-on. It would be easy for other employees to use and find this form.

I figured we'd give it a test. The design part was easy and I got everything working, looking the way I wanted it to. And it looked really nice. It was really user friendly and it integrated directly into Microsoft Teams, which we'd been starting to roll out at the time. was brand new, say what you will about it, but it was way better than Skype for Business. But however, I had overlooked a crucial step, timing. So I think it has probably gotten a lot better since then, but at the time,

It took about 5 to 10 minutes from the form being submitted to any kind of processing being done. Again, it's probably gotten a lot better, but even just sending a notification that the form was submitted was painfully long. And it was just long enough that other employees began to think that their form wasn't submitted. And they'd either try to submit it again or come to my office and ask questions. So we ended up going with a different process before we pushed it into production, but

The moral of the story is know your tools. If something doesn't work, don't be afraid to pivot. It's like using the wrong sized driver in a drill. It's going to end up probably stripping the screw and causing you a lot more work than if you just gone and grabbed the correct tool. So that's pitfall number one. Now pitfall number two is selecting the wrong problem. So when you're selecting a problem to automate, start by evaluating tasks that are repetitive and time consuming.

but also consider their impact on your overall operations. In the Automate IT podcast, my buddy David van Heerden calls this the "Boy howdy, I don't like doing this." test. If you really dislike doing something, it's often a good candidate for automation. Tasks that are unpleasant or cumbersome usually consume a lot of time and energy, which could be better spent on strategic initiatives. By automating these tasks, you can alleviate workflow bottlenecks and improve operational efficiency.

Conversely, you can spend a lot of time automating a task that wasn't a good candidate for automation in the first place. I always like to recommend keeping a notebook of what you spend time on. If you find problems you really don't like solving and doing repetitively, write it down. Now, the best test I've found to see if something is a good candidate for automation is drawing it out in a flowchart. If I can draw it out and understand the problem logically and how to solve it,

It can be automated. We'll talk about documentation later, but for sketching something out quickly, I find a pen and paper to be the best option. Now I tend to lose or throw away any paper on my desk, so these notes are largely temporary. If it's important, make a digital drawing or keep it in a note-taking app of choice. But for figuring out stuff, go to the printer, grab some blank paper out of the tray, and start drawing it out.

Pen and paper is great. Remember, automation is a journey. It's not something where you can have everything done tomorrow. The best automations are iterated upon over time. Pitfall number three is bad mentalities. When implementing automation, there are two mentalities to avoid that can lead to significant pitfalls. I like to call them the "Send It!" mentality and the "Once and Done" mentality. So the "Send It" mentality often involves deploying automation with minimal testing.

This approach might seem efficient at first, you're getting the code out, you're getting the automation working, but insufficient testing can result in unanticipated errors and inefficiencies. Make sure you fully test your automations, roll them out slowly to test groups first, and automated processes need to function seamlessly across various environments. So testing is crucial to ensure they meet the expected reliability, they do what you want them to do, they're effective. Skipping this step.

can lead to disruptions and require more time and troubleshooting and fixing issues later on.

Then on the other hand, there's the once and done mentality. This mentality assumes that once the automation is set up, it no longer really requires attention or updates. can just, you did all the work upfront, you can send it. You don't have to necessarily monitor it afterwards. This approach overlooks the necessity of regularly checking and updating automated processes. As business needs evolve, as

as best practices evolve, so do the requirements for automation. Failure to review, monitor, and adjust these processes can lead to broken automations, security risks, and even some downtime. Continuously monitoring and making timely adjustments to ensure that the automation remains an asset, providing ongoing value and adapting to any changes in your environment or strategy is key to successful automation.

Then there's pitfall number four is not documenting anything. Documentation is critically important in automation. No one really likes taking the time to do this. Still looking for ways to automate this one too, but looking at you generative AI, we'll see what happens. But proper documentation acts as a map guiding you, current and future team members through the intricacies of the automated process.

whether it's in detailed code comments or a short and quick markdown file, a Google Doc, a text document, however you want to document it, clearly outlining what the automation does and how it operates is invaluable. Now, this not only aids others stepping into the role, but also serves as a handy reference for what I like to call "Future You" Now, from my experience, Past Landon often assumed that Current Landon

would easily recall the details of whatever I was doing at the time. And speaking from experience here, without documentation, those details can quickly fade, leading to confusion and inefficiency down the line. There have been several times I have been quite confused with my own work when revisiting a past project. With each automation, you get into the intricacies of what you're doing. Those details can be lost, whether it's an API call or...

The certain way that an automation works by investing time and thorough documentation, you ensure a smoother transition for new team members and save yourself from future headaches when revisiting past projects. It's a simple yet effective practice that reinforces the stability and adaptability of your automation efforts. Now that's all we have for today. So until next time, find some problems, automate them, and have fun. Thanks for listening.

Thanks for tuning in to today's Autonomous IT podcast. Join us every Tuesday and Thursday for new episodes.