Author: Jenn Steele

The Grammar Geek: Win Some, Loose Some

·

And the Grammar Geek is back!

A comment on one of my old Grammar Geek posts reminded me of something that makes me twitch: too many letters in lose. In other words, it seems like more and more geeks are spelling lose “loose” on various listservs, comments, tweets, and blogs.

  • lose: there are 12 definitions of this word in the online Merriam-Webster Dictionary, but, in short, it means to become without something. You know, like losing weight, losing the software license key for MS Office, losing one’s mind… Note that losing something causes a loss. And you’re a loser.
  • loose: on the other hand, loose has fewer definitions (7 or so) from the same source, most meaning not dense, not fastened securely, or to set free. Note that loosing something sets it free, and if it comes back to you, it’s yours. And you’re probably not a loser–I guess you’d be a looser, but that just sounds funny, doesn’t it? And, while looser is a word, it means more loose, as opposed to one who looses.

If you don’t have a headache after that last sentence, I hope that you now understand how many times to use the letter o when you have misplaced something. (That would be once, for those of you who forgot…)

On the Blame Game

· 1 Comment ·

I pride myself on not playing the Blame Game. I tend to say, “I don’t really care who caused the problem, I want to know two things: how to fix it, and how to make sure it doesn’t happen again.”

A few weeks ago, however, I really wanted to play it.

Why did I want to play the Blame Game? Because I was MAD. I was angry. And I wanted someone to pay for it. I wanted them to know exactly whose actions caused me this pain, and I wanted them to be penalized for it.

Wait, that’s not how I normally work. That is, in fact, antithetical to how I run my department. But this was outside–I wasn’t running the show in this case.

This experience gave me a bit of insight into what I’ve experienced from bosses, users, attorneys, and even my father: when you’re mad, you want someone to pay. As a leader, I have to be on-guard for this from myself, especially with the people that I lead. As the head of an IT Department, I have to realize where the Blame Game is coming from when people either inside or outside the department.

By understanding, I will find it easier to empathize and guide the conversation away from blame and towards a productive solution. By understanding, I can explain to my staff what’s going on outside the department so that they can understand. By understanding, I can guide situations away from blaming and towards fixing.

I guess getting angry and wanting someone to pay for it taught me something. Go figure.

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.

Jenn Speaking at ILTA ’08

·

For any of you who might be attending, I’ll be speaking at the International Legal Technology Association (ILTA) 2008 Conference in Grapevine, Texas next week.

On Monday, August 25th at 10:30 AM, I’ll be a panelist in the “Best Practices in Professional Development in Law Firms” panel. Ruth Halpern, of Halpern & Associates, put together this panel; she’ll be providing the “meat” of the content, while Kathryn McCarthy and I will be telling all sorts of stories.

On Monday, August 25th at 4:00 PM, I’ll be a panelist in the “Business Continuity Technologies that Work for Law Firms of All Sizes and Shapes” panel. This panel should be fun–there are a lot of characters with a wide range of disaster experience. My role is pretty much the poster child for “what not to do.”

If you happen to be a New England ILTAn, I sincerely hope to see you at the Regional Meeting at 5:15 in Austin 1, 2, 3. After all, percentage attendance is one of the events for the Regional Competition!!

On Communication

·

Let’s face it: geeks can sometimes be poor communicators.

(It’s tempting to end the post there to prove my point…)

I’ve seen geeks forget to inform colleagues and bosses that they’ll be on vacation, geeks neglect to inform companies about scheduled downtime, geeks fail to ask essential questions, and everything in between. So how does one, as a leader of geeks, deal with this?

  1. Know yourself. Many geek leaders were once geeks themselves. Have you inadvertently created a culture of non-communication? Do you tell your geeks if you’re leaving the office to play golf or have lunch? Do you let them know about potential changes and plans?
  2. Know your geeks. Wander into offices and cubes and ask what’s going on. Ask “why?”. And actually listen.
  3. Communicate about communication. Let your geeks know what is and isn’t acceptable to keep quiet about. For example, I make it clear that my geeks can tell me as much or as little as they want about their lives outside of work, but if I ask what they’re working on for their jobs, I require answers.
  4. Leave your door open. Allow your geeks to come by when they feel like doing so. Won’t happen much, but some geeks are more comfortable chatting than emailing. No, really, I’ve seen it. Honest.
  5. Revisit things. Introverted geeks won’t ask all their questions and voice their concerns in an initial face-to-face meeting; they’ll need to mull it over. If you don’t give them space to bring up these thoughts, you may never hear them. And they’re probably good thoughts to hear.
  6. Consider written communication. Email can be useful for this, but I’m planning to set up a wiki for my department to track projects.
  7. Don’t play the blame game. There are definitely unacceptable levels of communication (see examples above), but before ranting and raving at your geek about how he or she was REQUIRED to tell you about the system change, go into inquiry mode. Find out why the geek forgot to do it. Make it clear that it can never happen again, and then, if necessary, examine ways to prevent it. You may need to make a template email that the geek can send out to the company for downtime, or you may simply need to accept an apology.

If you try, you can probably create an environment where your geeks will communicate more. They’ll never become The Great Communicator (thank goodness), but you should definitely see some improvement.

On Inquiry

·

Good geeks ask “why?”.

If you give them a number to hit, they’ll ask “why?”. If you tell them your sales goals, they might ask “why?”. If you ask them to do something, they’ll ask “why?”.

If your geek fails to ask “why?”, you probably don’t have a great geek on your hands. Or she is shy, and you should make her comfortable enough to ask “why?”.

Why?

Well, I’m glad you asked…

Asking “why?” shows curiosity, which is a close cousin of creativity. I find that geeks can get to the fundamental issues of a matter and develop a solution that is often better than the original task proposed (the one that they questioned). If they don’t ask “why?”, your geeks risk getting stuck in the box of your way of doing it.

Yes, it’s possible for them to go overboard, and sometimes you won’t have a good answer to their question, but don’t be worried when geeks ask “why?”, be worried when they don’t.