What 7 Years as “The IT Guy” Taught Me About Problem Solving
Techniques for becoming a more effective problem solver
The troubling thing about problem solving is that problems have a way of redefining themselves by the time you have solved for them... By the time you have solved for “X”, “Y” gets added to the equation and throws everything completely out of balance.
For the last 7 years, I have been the IT guy for three different organizations. As the only IT person on-site daily for a series of box plants, a consulting firm and a County government, it is safe to say that I have dealt with a lot of problems across many contexts. From dealing with the impromptu requests of executives, to the urgent inquiries of production works, to the frenzied pleas of supporting staff, I have always been the front line of support and, many times, I have been the only support available whatsoever.
This is to say that I have been in a lot of situations where I was lacking some experience, knowledge and resources to address issues immediately. In turn, this has occasionally led to me being entrenched with an issue, with tight deadlines and increasingly irritated end-users looming. If it sounds like a lot of pressure, I will be the first to admit that it is. But, over time I have learned a number of approaches to both resolve entrenched problems and provide high satisfaction with my services.
Reframe the Problem, Redefine Your Solution
I recently was working on a project where I had to coordinate swapping out routers at three different locations simultaneously. Having come onboard mid-project as the only IT professional for the organization and having experienced a rocky handover from the previous tech, I was scrambling to fine-tune my plan so that I could get the work done in a timely manner, without a significant impact to end-users.
With the routers configured and tested for two sites, I still had to complete the configuration for the third site and was quickly reaching my deadline for completing the swap. The problem I was facing is that I needed to check/adjust configurations on the existing equipment at that site to get it to ensure proper function with new device I was putting in. I could not find the username and password for that equipment though. And, it was also costing me a lot of time trying to track it down or figure out ways to work around the problem.
This was quite a quandary because I was at risk of missing my deadline. At the same time it would be unacceptable to wait until I put the new router in to be sure that it was going to work. It really got me thinking though and I asked myself, “Is my goal to find the username and password or is it to make sure all the equipment is configured to work harmoniously?”
In the end, I decided my goal was the later and I reset the equipment to factory default late one evening. Within a couple of hours of making that decision, not only had I got all the equipment up and running, but my updated approach to the problem enabled me to simplify the network at that site. Crucially, it also enabled me to get the username and password for all of the equipment documented so nobody would ever have to deal with that issue there again.
Here is the takeaway: When you aren’t making progress and you stop to reframe the problem, not only are you giving yourself a better shot at solving it but you are also giving yourself a shot at coming up with a better solution.
Work Two Angles at Once
This is one of my go to approaches for solving difficult problems. Typically, I am required to address issues quickly, while simultaneously facing constraints around the times when I am able to troubleshoot or when outside resources are available to me.
An example of this is when I was recently working on a server that was periodically disconnecting users. I was not certain if the issue was caused by a Windows Update or a recent network change that was incompatible with the older application end-users were using.
In order to effectively troubleshoot the server, I needed to temporarily take it offline so I could move it to another segment of the network. Since the application worked part of the time, however, I could not do this during business hours, lest people fall even farther behind on their work than they otherwise would.
So what did I do? I took the time I would have used to troubleshoot the problem during the day and put it towards opening up a ticket to queue up resources with my network vendor… After all, at worst I would just need to close the ticket with the vendor if I resolved the problem myself.
In my view, there are are several benefits to what some would say is an inefficient approach:
- In my experience, working a problem from two angles prevents you from getting stuck, becoming frustrated trying to figure out what to do next and ultimately taking even longer to solve the problem.
- End-users usually find this approach highly satisfying because you resolve the problem that much more quickly. In addition, most people understand that it can take time to solve problems and is satisfying for them to hear when you are leaving no stone unturned.
- This is a great way to learn… Sometimes these tangents produce results for the problem you are working on and sometimes they don’t. Often times, with how inter-related all the different aspects of information technology are, these tangents unlock the solution for other problems you are working on. Regardless, I have found that you always learn something.
The bottom line, when it comes to working a problem from two angles at once, is that you typically get stuck less and solve problems more quickly. In the short-term, it can be a lot of work but resolving problems quickly frees up your time to work on other things. In the long-term, it pays dividends in what you learn and trains your brain to avoid focusing too much on any one solution.
Avoid Implementing a Solution at the Complete Exclusion of Others
One of my favorite college professors once warned the class that getting into an “either-or” mode of thinking is a good way to stifle your creative thought process and limit progress on any problem. Instead, he encouraged a “both-and” thought process that encourages you to ask, “How can I utilize both the best parts of this solution and the best parts of another, to come up with an enhanced solution?”
The longer I have worked in the field of information technology the more I have identified with this principal. The truth is that with busy schedules, limited resources and short attention spans, it can seem advantageous to eliminate as many solutions as possible from contention as quickly as you can — then you can implement the one pure and parsimonious solution left standing, right?
The problem with that approach is that it assumes that you already have all the knowledge, experience, resources and attention you need to identify that solution in the first place, if there even is a “pure” solution to the problem you face in the first place.
An alternative way of solving problems with multiple competing solutions is identifying where multiple solutions you prefer overlap. Then you can identify the fundamental solutions or technologies that are common to those options. Once you have identified these components, you can often find inexpensive, open-source and easy-to-implement products that provide those components as the foundation for the solution you implement in the end.
With a solid foundation built, you have now acquired much of the knowledge, resources, flexibility and momentum you need to recombine solutions so you can deploy something that is that much better in the end. In addition, as you build this foundation, you will get hands-on experience that will provide deeper insight into the needs of your end-users.
The biggest advantage to this approach in my mind, though, is that it gets you in a learning mindset that encourages continuous improvement and iteration...
Iterate
Why iterate? Problem solving in a corporate environment can be a bit like playing whack-a-mole. Putting too much time and effort into a singular solution in a dynamic environment, you may find that your solution is outmoded even as you are rolling it out.
Another thing to keep in mind is that it is often better to implement a solution that gets you two-thirds of the way to your goal and improve productivity immediately than to delay deploying anything at all in the search for perfection.
One project I recently worked on had me implementing technology that would allow my organization to put base level security and recovery controls on Apple devices. As you can imagine there are a lot of solutions on the market for this and it was tempting to implement a robust “mobile device management technology” that was going to take a year to plan out, while costing substantially more.
We were already losing devices when employees left the company, due to the activation locks Apple puts on devices when employees sign in, though. We also didn’t want to strictly limit how employees used their devices because it would have limited their ability to do their job.
So what did we do? Well, I found out that Apple offers a fundamental service of any mobile device management solution for free. And, if you sign up for that service, you can easily switch to other Apple-compatible mobile device management solutions as your needs change, without upending all the work you previously did.
This means I was able to quickly and cheaply provide a baseline solution to my organization, which was able to save us money, better secure our technology and even improve productivity. This was all without locking us into a solution that might not be perfect for us long-term.
Go With a Solution Everybody Can Agree On
When all else fails, go with a solution that everybody can agree on, even if they may have some reservations. Problem solving in an organizational setting is about enabling people to do their job, increasing their productivity and avoiding the introduction of new issues, including counterproductive malcontent and frustration.
I am always very careful to set expectations when I am troubleshooting issues or working on projects. I like to talk about the amount of time I expect my work to take... I talk about worst and best case scenarios... I consult with my end-user (or stakeholders) about what they hope to get out of the work I am doing…
When troubleshooting an issue and having this discussion, I sometimes find out that the amount of effort or lost time for the end-user is too great for them to set aside the time to work on it. Perhaps, an unfamiliar issue for me is going to take too much time to fix for a merely annoying problem. Maybe, I know exactly how to fix the problem but the end-user is not willing to give up their device for two hours to give me a chance. Regardless, sometimes it is better to implement a half-measure or do nothing at all, if that is what the end-user is most comfortable with.
One example of this is occurred when people would have problems with their laptops at a company I previously worked for. Due to our service contracts on the devices, we would typically have to ship them in for repairs for issues such as poor battery life. In that situation, employees could not go without their primary computer for days on end so I would issue them a new one. For many employees, the extra effort of getting set up with a new computer outweighed the inconvenience of having to charge their device more often, though. In that situation, we both agreed that the best solution at that point in time was to do nothing.
No matter what solution you choose for a given problem, the key to this approach is that you are providing good customer service, by listening to, being honest with and consulting with your end-user.
Getting Real About Problem Solving in the Work Place
If I am being honest, problem solving in the work place is a lot of work. It takes time, effort and occasionally some late nights. Even with the approaches I have shared here, it is typically not easy. It can get easier though and, using the approaches I have shared here, you can certainly become more effective at it.
Another of my instructors once told me, “Get paid for what you know, not for what you do.” In my mind, becoming a better problem solver is a key skill that is necessary to reaching that measure of success as a knowledge worker.
If your customer isn’t happy, is the problem really solved? Read about how to maintain customer satisfaction in The Reassuring Thing I Tell People When Providing Technical Support.