Here are a few quick lessons that consulting has taught me so far. I like these because they’re applicable to life outside of work.
1. Learn to listen to what people really want, rather than just hearing what they say. One of the most valuable lessons I’ve learned from being a consultant so far is that people rarely say what they really mean, and it’s not something that happens on purpose, either. When you deal with technology, oftentimes there are barriers to be broken, walls that have to come down. Things like terminology (the internet vs. a browser, system tray vs. task bar). Outside of technology though, there are lots of time where this same technique is applicable. You have to probe a little bit to find out what they truly mean before making an assumption. Those assumptions can be deadly sometimes, and they can wrap you up conflict.
2. Politeness is free. You can simply help your users (or your friends, relatives, etc.) or you can help them and make them feel welcome. It doesn’t cost anything, and it always makes for a happier ending. For instance, if I speak to someone who’s having SAP troubles, and I can’t help them immediately, I can always neutralize it by being as polite as possible. Again, this technique applies to everything. When my friend PJ would get a rude gesture while driving, he would always respond by giving the peace sign. My guess is that the other driver would probably be confused, and then go back to being relaxed again. The alternative is anger and blame - it’s all worthless, especially when you can just skip over it.
3. Be a person with a personality. You can read a “Hello, may I help you?” script or you can be yourself (within the limits of professionalism!). This happens a lot over the phone. People are expecting a scripted greeting. What if you made it more interesting? For instance, today I’ve been answering the phone with a “Happy Friday!” This is nothing groundbreaking, but it still makes a huge difference. Real life experiment: don’t ask anyone how they are unless you’re really prepared to hear how they are. And when you ask it, mean it. The inflection in the tone of voice of someone who wants to know how you are is much different than the tone of the scripted “how are you.” And then you should really listen.
4. The customer is not always right. There, I said it. I include this because it’s important to realize that you can be as helpful as possible without getting walked on. If your clients/customers expect you to walk on water, they’re going to be disappointed, so it’s important that you explain the reasons as to why you can’t fix something, or what policy prevents you from carrying out a given demand. You should make it clear when you’ve done everything in your power. When I was in college I worked at the front desk of a dorm, and during my 5-7am shift, a student came asking for Tylenol. We didn’t have any behind the desk, and there was a convenience store down the road, but this student clearly stated she wasn’t leave until I solved her problem. So I called my girlfriend, and had her wake up and hand this girl pills at 5:30 am. Did I have to do this? Absolutely not. What did it cost to make this girl happy? 2 minutes out of my girlfriend’s night (she’s forgiven me).
5. You can’t bear the weight of the world. Being on a Tier 1 team definitely teaches you that asking for help from the people above you is not only useful, it’s straight up necessary. I could spend hours trying to help a user solve a problem that a Level 2 could figure out in minutes. Sure, I’d learn a lot, but why waste a user’s time? Similarly, we’re presented with situations everyday where asking for help is the only way to get things done. Experiment: write down all the skills you have (as a worker, friend, etc.) and then match yourself with a friend/colleague who has a complimentary talent. Imagine what you could do as a team, and imagine the time that you could save.
6. Pull out chairs, hold doors. The idea is to make things as easy as possible for your users. If this means redesigning the UI multiple times, then so be it. For my current job, it involves not what I say but how I say it. Most of the users I deal with don’t know their way around a computer as well as I do, and it’s easy to get caught up in computer jargon. A lot of times they’ll pretend that they understand what I’m talking about so that they don’t seem stupid (they’re not, of course). But it does lead to confusion when you think you’re on the same page, but you’re actually on different chapters. You have to find the middle ground between hand-holding and no-training-wheels.
I’m sure that I’ll think of more later.
Leave a Reply