Ease Into Your Automation Journey

Episode Summary

In this episode, David van Heerden discusses the importance of safety and accessibility in automation. He emphasizes the need to understand what automation is and how it works in order to feel comfortable and confident in implementing it. He also highlights the significance of effective communication and clearly defining the purpose and outcome of automation to build trust with stakeholders. Additionally, he suggests investing in reliable tools and products to eliminate risks and ensure successful automation.

Episode Transcript

David van Heerden: Okay, I'm not wearing any Automox merch today, so I have to put the Automox mascot over here. I don't know if he gets too blown out in the window there, but hey, it's Otto. There he is. He's hanging out with us today. Welcome to the Automox podcast in this series, Automate IT. You're hanging out with me, David van Heerden, where I talk about various topics around IT automation.

I tend to lean a little bit more onto the human element of automation and talk about tools and how to be successful in implementing automation. We have a lot more of the technical deep dives with some of our other podcasts and of course our product, the product itself. But with me, I like to talk about people. People are my favorite. I love people. I love technology too, but I love people more. 

And when I'm approaching automation a lot, I come across this sentiment quite a bit on how people feel about automation, right? Our product is trying to sell you on automation. That's a big core part of our business, saving you time, right? Cutting costs in different areas, realizing a lot of value by implementing automation, not just with our product, but around your IT program and your business as a whole. 

But there's a lot of these barriers and these difficulties to implementing automation successfully. And one of those is the feeling of safety around it, and understanding what automation is so that you're more comfortable with it. And to talk about the safe and accessible side of automation, there's safety, which is the confidence in the solution where you know it's going to do what it's supposed to do.

That script is going to execute properly and it's going to execute when you need it to execute as like two important components. Like, okay, I have a script, it's super simple. It'll automate the rebooting of my servers and I don't have to go and remote in and hit the power button or anything like that with the mouse. So I've automated at least that process of rebooting my servers, but I only want those servers to be rebooted within a certain timeframe. 

So I don't feel super safe, just, putting out this script, unless I know it's going to run exactly when I need it to. Otherwise it's, it's quite a dangerous automation that I'm implementing. And so you have to be able to get comfortable with what it is and your mechanism of deploying this automation, which I think speaks to the accessibility side of understanding what it is, the, the, what it does and how it works. So what is this thing here for? What is it supposed to do?

And then how does it functionally do it? Are the two important components that then support that feeling of safety behind automation? And so how do you impact that? How do you understand and break that down so you can feel more comfortable and get your business to feel more comfortable accepting automation and trusting it? And that first part is getting onto the same page as what it's supposed to do, the outcome. There's this hilarious example I've seen floating around on the internet where,

It was like a game developer who said, I don't know why, but there's a coconut.PNG file in the game files. And whenever I delete this coconut.PNG file, the game crashes. It will not run. So I have to have coconut.PNG in here and I can't find a reference to the file name anywhere. I don't understand why it's here, but don't touch it. It has to stay in. 

And that's that kind of, uh, like uncomfortableness around software that is automation and scripting, right? In that, okay, I don't understand how it works. I don't understand why certain things are where they are. Therefore, I'm going to have trouble trusting it. And think about that for your less technical folks within the business that have to adopt and accept automation, whether it's in the form of a SaaS products, it's in the form of a new software to install on their computer.

Or it's a service that IT has automated, security is automated to make something easier. Like a chat bot, right? That's somewhat AI automated and implemented in there. You have to establish that what is this? Why is it here? What is it trying to do first? So that you can sort of ease into that automation journey to fully automate that. 

So again, we're talking about that identifying side of things and really clearly defining what it is that we're automating and why, and then the how we're going to approach that thing. So for example, let's just talk about the rebooting of the servers, right? If you say that you've implemented automation to reboot the servers, your business is going to be like, okay, servers should only reboot on the weekends during the maintenance window, like the IT team said, but then if a random reboot happens during the week, what's the first thing that they're going to blame?

Right. They're going to blame, they're going to say, Oh, IT put that automation out there, that automation messed up. They're going to blame that. You're going to run around, try to, you know, and then now you're on like this defensive battle the whole time with the business trying to convince them that the automation can be trusted, that there's a, that there's this, uh, all these layers behind it of why it can be trusted. Now that trust is severed and broken because of how it was communicated, launched and their experience in the, in the, you know, delivery side of your automation. 

And so how do we address that? How do we build a more positive relationship with automation? And it starts with laying that groundwork of, okay, computers will reboot, right? For random reasons, one or another, but we want to bring more stability and control into our environment, which they would absolutely agree to. And so you say, all right, so the way that we have to tackle it is to go and reboot it manually.

What we're going to do instead is apply this little bit of code that's going to run it, right? You can talk them through a little bit of what the outcome is supposed to be. That outcome is stability within the environment throughout the week, right? It's no longer, oh, we're implementing automation that's going to reboot the servers on the weekend. Watch out. Because now every time they see a reboot, they blame the automation. Now it's, hey, we're trying to accomplish the same thing that you want, which is stability within the environment throughout the weekdays.

And so then on the weekends is where you should expect reboots to happen. And if reboots happen within the work week, absolutely let us know. And we'll find something that is causing it because our automation does not do that. Our automation is only going to execute on the weekends. And it's that slight shift in the communication towards the business outcome that helps that understanding of what it is that we're doing and why. 

Like the what is providing stability into the environment. We want a more stable environment. So what is this that we're going to do to provide more stability? We're going to reboot our environment on the weekends within a maintenance window. And then the how we're going to do that is some simple lines of code and automation that will only execute within this timeframe. 

And so then you're on the same page with the business with your customer on that side of if a reboot happens outside that window, it might be the automation's fault. Highly doubt it because we have confidence in our skill. We have confidence in the product that we're using to do the reboots, but absolutely let us know because we're on the same page of things being stable. So we want to figure out that problem and understand what caused it. And it's focusing on the why, focusing on the what is the purpose of whatever it is that you're doing.

Because you're not just rebooting a server. You're not just automating the reboot for the sake of rebooting. You're trying to deliver that outcome of stability within the environment. So that why, right? That shift of the business outcome, the value goal on the delivery of it is what you have to define and then communicate to the business. I think a lot of us get really stuck in the technical mind and space of it that we sort of lose track of that effective communication of the mutual benefit of the effort that is, in this example I talked about stability, stability, stability. We're on the same page for that and this is what we're gonna do to move towards it. And then that should develop a bit more of confidence in the solution that, okay, it happens on the weekend when it should happen, they understand that it was put in place for the stable outcomes during the week.

And so the next time you approach them, you can then say, Hey, the business outcome for a new kind of automation that we're putting in is going to be, I don't know. Let's say I'm still sticking with like this, this image in my head of a restaurant or something where we say, okay, we're, we're going to force another reboot in the middle of the week. Because we find that there's Patch Tuesday releases that come out, we test them and then we want to apply the change more urgently, right, is when we have to launch it. So we're going to use that reboot script again at a different point in time, but it's going to be much more tightly triggered and windowed in. And because you've established that we've used this tool before, it's tested and everything else, they'll trust that your maintenance window in the middle of the week is going to be much tighter. 

So a simple example, a simple story, but it's again breaking down that component of communicating the why, communicating the outcome of that automation. And then, when it comes to the solution as to the how you get it done, it has to be tied again to that value on the side. And they mostly don't care how you get something done, but it does help to have it there, at least articulated so they can understand that when something does go wrong, it's an accessible thing for them to point at and say, oh no, it's something that runs automatically if it happens in the middle of the week, then there's something else happened. So it is still important to communicate that how. And then lastly, in terms of implementing automation and that safety thing for us as practitioners, there's the, do I trust the method? Do I trust the how, do I trust the script? I've seen it where a lot of folks would rather have, it's kind of like the,

I know nothing will happen until I physically go and click it and do it because that feels so much safer because I am in control as opposed to relying on a script or a tool to do it. Cause we just see glitches and bugs happen all the time.

And that's where I encourage to look at tools for this sort of thing, right? Yes, it's a simple task that you could like DIY with your own script tool and deploy within your environment. And you could R&D your kind of own solutions for a lot of this stuff and save a buck, right? In doing that, but you're accepting this risk innately by doing it.

Whereas you can offload that risk and even eliminate it entirely by investing in a product that does it for you. And the, the, the outcomes, right? Again, focusing on the value to the business and why the investment is worth it is that it's been researched and developed by a team of full -time dedicated engineers. It's been vetted by other customers that trust and rely on that product. Think of it like, would you accept a reboot all my servers on the weekend script from a newly hired sysadmin that he's like, yeah, I got a USB drive filled with a bunch of script files, or would you trust a product that lets you schedule and run those tasks that's been used by tens of thousands of other customers in bigger environments than yours? So in that kind of storytelling, you can bring that to the business and say, hey, for us to deliver this outcome of stability with the environment, we want to perform this kind of action. 

And we want to have that stability and know that it's going to be done within that timeframe that it needs to be done. And so we're not going to mess around and, you know, just ride it ourselves and trust, trust, you know, the, those scripts we're going to rely on a vetted, supported and established service and product that can do it for us. So definitely think laterally in that way of, of. Trusting your gut and what you feel confident in and, and investing in making sure that you deliver that value to the business in the end goal. 

And again focusing on that outcomes and what you're delivering. So hope that one is short and sweet for you today. Thank you for listening. I'll catch you next time on Automate IT with Automox. Peace.