Working professionally in IT has forced me to learn many non-technical things I never anticipated I would need to know: How to politely tell a user that their password isn't working because they missed 5 emails about it expiring, or how to respectfully explain to someone that they don't have the authority to make a particular decision without hurting their feelings. (Still haven't found a perfect solution for that second one if I'm completely honest). People in tech have to balance keeping everything running smoothly, while also being skilled navigators of the corporate world in an effort to keep everyone happy.

One thing I hadn't anticipated I would need to learn was how to handle things that weren't quite in my job description. Sometimes a problem is brought to you that isn't exactly under your control or scope of management, but you need to help with it anyways for one reason or another. In an ideal world, we'd only work on problems with systems that are under our control, or at least only on problems with work-related systems. Unfortunately, we don't live in a world that's purely black and white, instead it's a vast canvas of nuanced gray complexity.

Sometimes, the boss asks you to help out one of their family members with accessing their email. Other times, you need to help troubleshoot a problem with the custom code a developer is writing. And of course there's always one person who inexplicably leaves irreplaceable personal data on a company machine before getting let go, and HR wants you to help get it back to them. For one reason or another, there will always be gray areas in IT, and navigating them is an important skill. I'll share a few notable experiences I've dealt with personally where I've had to work on an issue that would be in one of these gray areas. I'll change a few details where necessary, otherwise these are firsthand accounts.

A Developer's Woes

I had a support desk ticket get escalated to me for a user we'll call Lucky. Lucky was in a developer-adjacent role at one of my clients and had submitted a support ticket requesting assistance with a Python module. He wasn't a full time developer, but was trying to leverage the big-data processing abilities of Python. He had enough knowledge to use, or at least find, code that would accomplish what he was looking to do. The support request was regarding an error message he was receiving when trying to import and use a specific Python module from GitHub in his code.

Where I work, we have a policy to not directly interface with any client code and to avoid offering advice for anything development related. So, I accessed the user's machine and had him show me what he was trying to do, and at what point in the process he was running into the error message. The issue ended up being that the module he was using needed access to a C compiler and he didn't have a compatible one installed. While I wasn't able to offer him advice on what compiler to use, I still wanted to make sure I was understanding the issue holistically and point him in the right direction for a solution. I'm no full time developer, but I've worked with Python enough to at least give him an idea of where he needed to go next. That was enough to show Lucky that we cared about his support request and get him pointed in the right direction while staying in the bounds of company policy.

Personal Printers

A few years ago now, I got a phone call from a client requesting assistance with a printer that wasn't printing. I asked the standard questions of where the user was located, in office or remote, and what issue(s) they were running into. They let me know that they were remote so I asked the follow up of whether the printer in question was owned by the company or if he owned it. It was one he owned, and due to this I was immediately limited in what I could and could not do to help him out. Our policy with that kind of thing was to install any drivers needed and ensure the computer was working properly, but past that, we were to recommend they bring the printer/router/etc to a local electronics store. We never want to be responsible for changes to anyone's home network or personal devices. (No good deed goes unpunished and the moment you touch someone's home router, the next time their ISP is on the fritz it's going to be blamed on you).

On top of all that, once he told me the make and model, I learned from a quick Google search that his printer was well over twenty years old. Nonetheless, I went through some troubleshooting steps with him and diagnosed the issue as being on the printers side. He had fully updated drivers, was connected to the printer properly, etc. After some troubleshooting I had to break the bad news to this person that I wasn't going to be able to assist them with this issue and that they should probably look into getting a new printer. I offered to speak with his company to see if we could get a company owned printer purchased for him, but he declined the offer since he was fully remote. While I try to navigate gray areas with the hope to at least point people in the right direction, sometimes the solution to the problem is just not something I have control over. In this case, the user's printer had served him for over twenty years and it was time for a new one to be purchased.

Irreplaceable Memories

In my final tale from tech support gray areas, I'll be talking about Betty and the time that I had to recover her personal data from a company laptop. Betty was changing roles in the company to a position where she no longer needed a company assigned machine. We sent her a laptop shipping box with a return label and then didn't hear back for quite a long time. We reached out to HR and found out that she'd been stalling on sending it back since she had important personal data on the device that she didn't want to lose. I talked with my team about the issue and it was decided that the easiest thing to do would be to have Betty ship us the laptop and us take care of the extraction and delivery of her personal data. Immediately, this wasn't something I was overly thrilled about doing. I don't like having access to anyone's personal data in general, much less having to go through it to remove any company files. I may not have liked the situation, but it was one I was faced with anyways and I needed to navigate it as respectfully and tactfully as possible.

In an effort to preserve Betty's personal privacy, what I ended up doing was blindly pulling all the data from her user profile on the device excluding any cached items from the company drive. I created a new SharePoint site with permissions assigned only to our test account. There was enough data that a directly upload didn't make sense and likely would have failed. I signed our test account into OneDrive, synchronized the documents library in the new site to the device and moved Betty's data up to the locked-down SharePoint site. From there, I called on an HR person at the client to review all the data and remove anything that was company related. This way, we were still ensuring that corporate data wasn't being returned to Betty, but also were getting her important files back to her safely. Once cleaned, the files were returned to Betty with me never having to go through her personal data at all.