Of all the lessons I’ve learned in my IT career none have been more important than CYA.
CYA in the IT realm can mean many things:
Backup before you move forward (duh) if you don’t backup your work, you shouldn’t be in IT or you won’t be for long.
-or-
Have a backup plan, such as, if I make this change and it makes things worse, can I un-do what I just did so that I can “at-the-very-least” get back to where I was? Or if things really go wrong. Do I have a plan B? Such as: If I put this piece of hardware in this server and puffs of smoke come out. What will I do then? It’s not supposed to do that, but what if?
That is technical CYA and failing to do that may very well get you thrown under a bus, but that’s not what this particular article is about. No Sir.
———————
The other type of CYA is political CYA.
This is the most difficult type of CYA for us IT types because we tend not to recognize it. We tend to look at things in black and white. Working or not working. Broken or not broken. Fast or slow. On or off. Access Allowed or Access Denied.
For us stuff works or it doesn’t and when it doesn’t it’s our job to make it work, fix it if it’s broken, and generally the sooner the better right?
When was the last time a user complained to you and did so with your job in mind?
- “I can’t check mail, or my email is broken, but I understand you can’t fix it right now. I’ll sit tight until maintenance night so you don’t impact all the other users”
- “My VPN connection doesn’t work but I understand you can’t help me because I’m not at home to test it.”
- “My XYZ application is really slow, do you have a work around that I can use until the real solution (hardware/resources/etc) that are beyond your control can be put into place?”
Oh, Never that’s when. We’re expected to routinely read minds and perform miracles on a daily basis with little to no information and do so without ever interrupting anyone, anything or any service.
But we try, and try as we may to short circuit the process, to help folks be productive and fix these problems and not make users wait it will sometimes cause rifts.
We constantly have to weigh the risks of making changes to things now vs. waiting to make change later and the impacts that may cause. We have to react to requests of upper management who may not have all the data to support the changes they are requesting, but we have to do it anyway, because, well, they said so.
All you can do in this case is document your role. Document the fact that you’re trying to do what’s best for the organization from your point of view. That you’ve worked with the right people and received adequate permission. Documentation is the key, and it will save your ass every time.
While it’s true people don’t argue with their own data, they won’t argue with yours either if it’s well documented and logged. If you produce evidence that you did everything in your power to reduce the casualties and got permission to make the changes to improve the results then life will be good.
