I vividly remember one of the first times I stepped back from the abyss. While I was looking for a full-time job after I graduated from college, I did some IT consulting for local businesses in my hometown. One of my clients was a successful family business that had outsourced most of their IT work to a consulting firm. I filled the gaps between visits from their main consultants with anything that needed to be repaired, installed, or upgraded: PCs, printers, Internet access, software, etc. These were basic tasks I felt very comfortable performing, and low-risk.
One day, I was asked to install a piece of software that ran on the office’s shared application server. There was a new text editor program they wanted to run on all the terminals attached to their networked computer system. Would I take a look at it? Okay…sure. I was brought to the server closet and saw the two computers at the heart of their operation. Looking back across the bustling office to the lobby, I saw all of the employees and customers that depended on this system working correctly. A lightning bolt of warning struck me: “Don’t mess with this, you’re out of your league!” Up to this point, I had never worked on a networked application server, much less in such a high-risk situation. Let’s face it, I was as green as could be. I don’t know what triggered that candid moment of self-awareness. Normally, I’m a “get in there, tear it up, and see what happens” kinda guy. Maybe it was the worst-case scenario flashing before my eyes: a vision of me crashing the system and the business closing indefinitely until a high-priced guru could be flown in to mend the situation. I politely declined the work, citing my inexperience.
Belle Of The Ball
As your troubleshooting skills grow, you may find yourself becoming quite popular. Don’t get too excited, we’re not talking “Homecoming Queen” popular, but rather the “Can you help me with this problem?” kind. Sorry, but you can still buy the tiara if you want. While it’s great to be wanted, you’ll have to set boundaries to protect yourself. It’s not only about guarding your time, you also need to shield those whom you intend to help. When I declined that opportunity to work on the application server, it protected me and the people I was trying to help. A blunder would have ruined my reputation (and weekend), along with their ability to conduct business. Biting off more than you can chew is annoying to you and the person who asked for your assistance. The guiding principle is “do no harm.” If you’re there to help, make sure that actually happens.
Flattery Gets You…In Over Your Head
“You’re so smart, I just know you can fix this!” Everyone likes being complimented, but it’s also a recipe for getting in over your head. I’ve seen flattery feedback loops end in big failures. The problem is that if you assert you can fix something, most people will believe you. It takes two to tango: a person with a problem will typically give you all the rope needed to hang yourself. Once you take control of the situation and start mucking around, it’s rare for a customer to say, “Are you sure you should be doing that?” You might be the first, last, and only line of defense against hubris. When you pack your gear, throw some restraint into your toolbox.
Leave Yourself An Out
Whenever I go hiking, I like to remind myself that every step I take away from the trailhead will require a step back when I return. In a sense, every step outward is a commitment, a promise to take a step in the opposite direction. You can’t hike for 4 hours one way and then be angry when it takes 4 hours to return! Hiking a trail is a good example of a debt that slowly builds over time, one that must eventually be repaid.
Likewise, large repair projects have implicit obligations that can be accumulated over time—or even in a single moment! Taking a particular repair path requires you to make a commitment, but often that commitment is made without careful consideration of the long-term consequences. Certain actions are difficult to reverse: many machines are easy to take apart but very difficult to put back together (even if you’ve taken notes or pictures). Removing a suspicious part may destroy it; long, complicated procedures that don’t bear fruit may require an equal amount of time to revert. Back to our virtue of maintaining boundaries: you must be aware of what’s happening and not cross over these lines without a deliberate plan.
So, before you reach the “point of no return,” stop and ask some important questions:
- Will repairing this system require downtime? If so, who will be affected?
- How long will this repair take? What if it’s not completed on time?
- What are the risks of attempting this repair? Can it be reversed and what are the steps to get back to where I started?
- What if I am unable to complete the repair?
Answering these questions is a great invitation to forming a contingency plan, an “out.” The “when” of a repair is often negotiable: even if a system is running slowly or intermittently, it may still be doing useful work, allowing a repair to be postponed until a more convenient time. Of course, if the broken system is already down, there’s no issue about interrupting work—it’s already happening!
Even when your hand is forced, there are still important decisions to be made because the question of risk is present in any major repair. I always favor swapping if there is a good possibility of damaging a machine while troubleshooting: it’s always better to attempt those kinds of fixes in a low-pressure environment.
Blessed is he who expects nothing, for he shall never be disappointed.
Perhaps the most important boundary you can set is someone’s expectations. I’ve learned the hard way the value of being modest when promises to help are being made. Besides, it’s always best to let your actions speak for themselves. If you find yourself prone to verbal boosterism, at least tap the brakes when it comes to two crucial subjects: time and money. These are always the most requested pieces of information about a repair, but speaking too optimistically about either risks major-league disappointment. It’s much better to say “I don’t know, I’ll have to take a look.” Which happens to be the truth: how can you really know how long a repair is going to take and how much it’s going to cost without a thorough assessment of the situation? Underestimating the time of a repair has led to some of my worst, “in over my head” incidents. If you’re hacking away on a Sunday night, remember that Monday morning will eventually come.
While I’ve solved a lot of tough problems, I feel that some of my most impressive fixes (at least from the perspective of those I was helping) were simply the result of initially being circumspect about what I could accomplish. There’s nothing like starting off with, “Geez…I’m going to have to take a look first…I’m not sure if I can help you.” And then 5 minutes later finding the solution. Standing ovation.
The emotional arc of this kind of repair drama is very satisfying for those you are helping: doubt → optimism → elation. Compare this with the trajectory of expectations violated: certainty → doubt → anger. The funny thing is that two troubleshooting exercises can be identical except for the expectations created: one results in a happy customer, the other in an angry one.
Granted, you can go overboard with sandbagging people’s expectations. It’ll take some trial and error to find the right balance between being confident and being guarded, the right tone appropriate for the people you’re trying to help. If you’re too much like Eeyore, the undisputed king of low expectations, you’ll never be asked to do anything! People will rightly expect that you project a baseline level of confidence that communicates you are competent. While it takes effort to make this calibration, the overall goal of deftly managing people’s assumptions is worthy of your time: it’s always better to exceed expectations than to be perceived as coming up short. It’s just human nature.
*** Questions? Comments? Have a related troubleshooting story that you’d like to share? Feel free to leave your feedback in the comments section below! ***