Years ago, I worked for a mutual insurance company in Distributed Computing. This department included, Software Development, Help Desk, LAN Administrators and Server Solutions. In my role as tech support and LAN Administration, I knew a Software Engineer who was wickedly smart, incredibly talented but didn’t always exceed in transparency.
What do I mean? I’d sometimes noticed that if you’re smart with technology and receive very little oversight, you’re sometimes careless with updates. This individual would make changes to the network login script at various times of the night — often without testing or a thorough review. These updates were typically done for specific business purposes. In addition, his changes were never communicated to the help desk, so when a call came in about early bird users not accessing their files or desktop icons after logging in, those on the help desk did two things. One, they would gather as much information about the issue and attempt to troubleshoot if possible. Two, they would look for trends or commonalities to possibly help other areas do a root cause analysis to determine what changes were done to the network infrastructure.
It didn’t take me long to catch on to his bag of tricks. Through a few login script changes, I realized when certain departments were missing key icons or files once they logged into their network, my colleague, the Software Engineer had previous made changes to the script.
So, if I told him all of Marketing had issues logging in, he displayed a poker face and encouraged me to tell him more. After saying it affected just one server login script and just Marketing on the third floor, he said he’d quickly investigate. As I walked back to my desk, I knew he was scrambling to remove the code he had added hours before.
This continued to occur for over a year. When I saw a trend with certain departments having issues in the am, I’d call him and after no answer, I’d briskly walk 5 minutes to his desk as he was surfing the Internet. I’d mention login script issues and he’d always say, “I’ll take a look at this.” Changes were quickly made by him so executives would not find out, so after his change, his response was the issue would be resolved once all users rebooted their systems.
He knew that I knew but he wasn’t going to be honest and transparent.
In fact, the same scenario occurred with his colleague as I mentioned a department wide outage and asked if changes were made to that departments’ login script and he’d say “No.” Because this was not my first rodeo, I knew someone wasn’t telling the truth.
I never quite figured out why they weren’t telling the truth. Were they ashamed? Did they feel threatened that someone with fewer IT credentials was on to their game? I’d often mention that when changes were made to servers, it would be helpful to communicate this information to the help desk in case a flood of calls came through. Often, they’d agree with that communication approach but something was lost in translation as those on the help desk never got a “head’s up” on those server script changes.
At times, I wondered if I should have been less customer focused and let double or triple the amount of calls come in and ignore that trend right in front of my eyes, that way, IT management may have gotten involved to investigate. Perhaps that would have been one way to get to the root of the issue. However, I had empathy towards those users who were at their desks at 7 am ready to work. I never could have neglected my duty by being mischievous knowing that’s not my MO and not the way I would have wanted to be treated. Although I’d be lying to think that approach didn’t cross my mind from time to time.