Month: September 2008

On Correction

·

One of the greatest challenges in management is correcting staff, especially when you’re somewhat annoyed at them. While it might feel really good to vent your anger by stalking into your geek’s cube and start yelling, “What the $%^&* were you thinking!?!?!?”, this isn’t the best way to maintain her respect or team functions in general. And, I have to admit, I have a temper, which makes the yelling part even harder to resist.

How do I deal with it?

So glad you asked…

  1. Find out what actually happened. Your question to the geek shouldn’t be, “What the $%^& did you do to the managing partner’s computer?”, but should be, “So, what’s up with the managing partner’s computer?” And it should be said in a true tone of inquiry, rather than anger.
  2. Think about it. Think before reacting or thinking (If I, an extreme extrovert can do it, so can you–honest!). Make sure you’ve listened, and ask whatever follow-up questions you need to ask so that you feel like you thoroughly understand the situation.
  3. Figure out how to phrase your correction. Usually, this will become somewhat clear as you understand the situation. I find that I usually phrase correction starting with, “In the future, I’d prefer it if you…”, or, “I understand why you did that; in order to fix this, can you please…”
  4. Recognize if there’s no need for correction. Once you understand the situation, you might find that your geek didn’t actually do anything wrong. Don’t be tempted to correct anyhow.
  5. Strategize for the future. Let your geek know how you prefer these situations to be handled. Or ask for the geek’s input on how to prevent it from happening again. You might learn something.

It’s not easy; as I said, it’s one of the greatest management challenges out there. You’ll probably make some mistakes (heaven knows, I have!), but, if you can keep your temper, you can fix the situation (at least for the future) and keep your geek relatively happy.

On Customer Service

·

My sister got married on Saturday in Pittsburgh, PA. A lovely time was had by all, and she’s happily on her honeymoon.

After the reception, however, she ran into a bit of a snag. When she and her shiny new husband came back to the hotel after the reception, they discovered that neither of them had a key card for the room they had both checked into two days before. So they went to the front desk and asked for the key card. The front desk refused.

Refused. My sister was in her elaborate bridal gown with her veil in hand, and shiny new husband was still in his tuxedo. It was approximately midnight at the end of a very, very long day. They refused to take shiny new husband’s ID, insisting on having my sister’s, since the room was originally in her name (in the room block that had both names, but whatever). Of course, her ID was LOCKED IN THE ROOM–the same room for which they were trying to get the key. After all, there aren’t many pockets in wedding gowns. Finally, after approximately 30 minutes, they got the key card.

In my opinion, this was a complete failure of customer service. I attribute it to two things: blind rule-following and lack of thought. I’ve seen user-facing geek positions have the same two problems.

I find that it usually happens when geeks are bored or burned out. They find it easier to simply auto-pilot according to a strict interpretation of the question asked or the rules of the company, and fall back on that instead of moving into problem-solving mode. Unfortunately for them, most companies don’t tolerate the lack of problem-solving mode for long.

Lack of thought certainly compounded my sister’s case. After all, is a couple clearly dressed in wedding finery and registered in a known wedding block in that hotel going to try to break into a room? At midnight? I don’t know many thieves, but that would have to rank amongst the most brilliant schemes I’ve ever heard of. User support geeks will sometimes fail to think as well. Specifically, they fail to think about what the user is actually TRYING to do, rather than what the user is actually asking.

Now that I look at it, good customer service really comes down to engaging your brain, and solving the problem. Geeks (and hotel employees) also need to have the power to implement the solution, but I think that’s a post for another day.

On Attitude

·

Approximately two years ago, in my class on Authentic Leadership, we read an article (can’t find the citation–sorry!) on how having a positive attitude led to better working results in every single profession. Except in attorneys, which probably says a lot about my career choice to be a Leader of Geeks in the legal industry, but that’s not actually the topic of this post.

I find that geeks easily fall into sub-optimal attitudes, which usually fall into two categories. The first is what I call the “stupid user” category, where they develop the attitude that anyone who doesn’t work in their department or on computers is too stupid to function. The other I call the “end of the world” category, where they develop a Chicken Little attitude about anything that goes wrong.

A good example of the “stupid user” attitude is the Saturday Night Live sketch, Nick Burns, Your Company’s Computer Guy. From Wikipedia:

In the sketch, Fallon portrays “Nick Burns”, a caricature of the stereotypically condescending computer expert. Burns is the systems administrator for a large corporation, who is apparently always on-call to support technical problems. He is presented as a nerd, wearing multiple pagers and cellular phones.

…

He would start troubleshooting a problem by rattling off instructions to the character in confusing technical jargon, and quickly gets fed up by their relative technical ineptitude, eventually yelling his catchphrase, “MOVE!” He then sits at the keyboard and fixes the problem himself, gloating at the relative ease of the solution (“Was that so hard?”). There are two other recurring lines in the sketches: at the beginning of the segment, whenever it is mentioned that Nick Burns is coming into the office, Chris Kattan‘s character mutters, “I don’t like that guy”, and at the end of the segment, Burns exits, and comes back sarcastically yelling, “Oh by the way, YOU’RE WELCOME!”

My favorite example for the “sky is falling” attitude comes from real life. At one point, I had the pleasure of experiencing two server room waterfalls in one week’s time. After the first waterfall, I brought someone who is a software engineer in real life with me to help with the clean-up. He spent his entire time there saying things like, “You’re so screwed.” When I asked him (not as politely as I should have) why he kept doing that, he said that it was normal for his work environments. “We sit around and talk about what a mess things are, then we figure out how to fix them.” I didn’t take him with me to clean up after the second waterfall…

Neither of these attitudes is a good working attitude. The first attitude is antithetical to customer service; the users won’t like the geeks, because they feel like they’re being talked down to or belittled all the time. The second attitude leads to negativity and frustration–it is simply not a positive attitude to have.

In my work environments, I watch for these attitudes and actively discourage them for several reasons. First, I really want to create a service organization inside my law firm. Second, it’s just more fun to work around positive people. Finally, I want better work product from my geeks, and, since they’re not attorneys, a positive attitude leads to better working results.

On Communicating Expectations

·

I love the suggestions I’ve gotten thus far–keep them coming! However, inspiration struck in the middle of the night, so you’re getting this one instead.

On Tuesday, I returned to work from the ILTA conference to discover that I had misplaced my staff. Or rather, that they had misplaced themselves. I stuck my head into the Help Desk office, only to discover that it had become a storage room. I turned around and located the office, only to discover that it only had one desk (and the corresponding one human) in it. I walked past the spare office, only to discover that the door was now labeled for the other Help Desk person. As you might imagine, I was relieved to discover that my name was still attached to my office, and my key still worked! (Although there was a huge cardboard box on my desk. Lame compared to my last firm, where they toilet papered my office post-conference, but we’ll work on that…)

I was somewhat shocked. After all, the promotions that would give the respective Help Desk folks their new offices haven’t come through yet. The two people working the Help Desk are now in different offices, and I was unsure that would be as effective as sitting six feet from each other.

However, this was exactly the final configuration that I had specified. And the only configuration I had discussed with everyone. Last week was slower than expected, so they executed what they knew to be the plan.

I had to sit down and figure out why I was shocked that they had executed the plan I had communicated. I realized that, while I had communicated the final plan to them, I had failed to communicate that I had expected it to be phased in differently. And that I had expected them to tell me a little more detail about the moves they were making.

They were executing 100% of what they knew to be the plan, and they were doing it faster than we had thought it could be done–there was nothing wrong with that. What was wrong was that I had failed to communicate how I expected them to execute the plan.

Lesson learned: geeks can’t read my mind. Also? My staff executes plans quite efficiently, when motivated. Next step: better define expectations.

Writer’s Block

·

Anything you’d like me to blog about? Any questions you might have? I could use your assistance getting over my current bout of brain constipation.