The Key From Moving From an IT Fire Fighter to a Zen Master

I’ve been thinking about how setting short-term goals and working in the future is the only way to accomplish anything useful at work. Setting short-term goals helps you to be successful without feeling like you’re overwhelmed, stressed-out and can’t get anything done.

Whenever you feel like your day is going well, getting a lot done, projects are going well and everything is fine, when does that usually occur? For me at least, that usually occurs when I have a sense of control. I don’t have all these things popping off all over the place that I don’t expect. I don’t have all these crazy support calls, or a co-worker coming by asking if I can do something for them right now, or if something can fit in the project. It’s all about feeling like you’ve got everything you were supposed to do, done. That’s fine, but how do you actually get to that point?

You get to that point by defining some sort of plan early on. For example, let’s say you have a project to roll out a new version of the software to a bunch of machines. As part of that, you’re always going to develop a project plan. This could include finding all the machines; how the machines are going to be updated; defining how long this project is going to take. All the different steps to actually make it happen.

If you’re not able to properly think about the end goal and keep getting distracted about what it takes to do each step, you’re going to hit roadblocks. It’s going to be stressful as hell. You’re going to want to take shortcuts to do it faster and faster to meet this crazy deadline that you may not even have thought through in the first place.

Eventually, it’s going to turn into a bad day. If you continue this process over and over, eventually it turns into a culture, and that’s what’s called a toxic culture. It’s really hard for me to put an exact description on this, it seems like anytime you’re successful at a project or at getting something completed, it’s about working in the future.

You’re never supposed to fight the fires and then stop, fight a fire and then stop, and not think past today. You should always be thinking about the future; next week, next month, where we are and periodically evaluating these things.  How are we going to do this?

Perhaps somebody calls the support desk and they’re unable to get into their email. The support person tells the caller to reboot their computer, and the caller states that it’s fixed. That’s thinking in the now, thinking in the present. That’s not actually fixing the core issue of why it happened in the first place.

Not thinking about fixing the core issue is about thinking that the user is having this problem now; what’s going to prevent them from having it now. When a user calls in and says they’re having a problem with Outlook, and you go through that ‘what if” scenario in your head, you automatically think, “they are having the problem now, what if it happens tomorrow, next week?” You think about how that’s just going to be terrible for both of us because the user can’t get an email, and I don’t want all these calls.

You start reevaluating your mindset of how you fix problems. You think about how this is going to be bad in the future if this keeps happening. You’re putting a band-aid on it and making the problem go away for a while without figuring out the root cause. You’re probably going to get it over and over again, and nobody wants this. In a perfect world, there would be no support desk because everything would work perfectly. This kind of gives you the goal of what to do.

Same with an automation engineer, like I’m in, and DevOps. In a perfect world, we would have nobody doing deployments manually. You should always have that thought in the back of your head. How is this thing I’m doing going to relate in a perfect world? To get your head around that is to be always thinking in the future, don’t think ‘the now’. If you’re an IT professional, if you want to learn PowerShell, or write a script, you’re fixing something now, why don’t you write a script instead of writing documentation on how to fix it? Why don’t you either fix the root cause or, if not, at least write some code, a script or something to just fix it immediately? It’s all about thinking in the future. It takes a day to run through all this stuff, and if you don’t document the necessary steps to fix the core problem, and the same thing happens again next week, month, or year, you’re going to have to take an entire day again. Why not spend the time to either write some code or at least write some documentation on how to do this?

‘If I have to do this again’ is the mindset you have to get in. Live in the future, develop a plan. Think about ‘what if I have to do this the rest of my life?’ How do I want to improve this process to make this happen?

 

This post was brought to you by yet another #CarTalks YouTube video. Be sure to check out all of the other #CarTalks videos and other video content on the Adam the Automator YouTube channel!