On the Meaning of Leadership

·

As some of you might know, I’m the point person on publising content for the ILTA ’09 Conference Blog. On Fridays, we publish a “Profile in Leadership” of one of the volunteer leaders of the International Legal Technology Association (ILTA). One of the primary questions we ask during the interview is, “What does leadership mean to you?” This, of course, got me thinking about how I define leadership.

To me, leadership means:

  • People want to follow you
  • You have somewhere to go
  • You can be creative and flexible in defining your goal(s) and how to get there
  • You use your followers’ diverse strengths
  • You admit that you’re wrong when you are (as I always say, “I’m perfectly happy to admit that I’m wrong–after it’s been proven to me.”)
  • You have self-confidence
  • You can be humble
  • You shine the spotlight on your followers
  • You take responsibility when things go wrong
  • You are primarily collaborative, but can be authoritative when the situation demands it
  • You evolve

There are undoubtedly many other characteristics of a leader, but these are the ones to which I aspire. These, however, are the traits that come more naturally to me or that align with my personal values. Others define leadership according to their personalities and values, and may have a vastly different idea of what leadership means.

ILTA’s “Profiles in Leadership” fascinates me, as many of the people profiled are role models to me in my legal technology career. As I read them each week, my definition of leadership might change, thus fulfilling my last trait of leadership above–I will evolve.

Dear Vendor:

·

Someone (a vendor, of course!) recently pointed out to me that I’m not so easy on vendors in my Tweets. So I figured it might be an interesting exercise to humorously dissect my relationships with vendors in the form of some “how to” letters to anonymous vendors.

Dear Vendor:

Thank you so much for calling to see if you can get my business. Unfortunately, your telephone signal was so unclear that I could neither understand your name nor number. Have a good life!

Dear Vendor:

Well, I assume you’re a vendor. You didn’t mention a company name, and your voice mail just said, “Please give me a call.” I didn’t find your name in the company directory or on my vendor contact list, so I assume you had the wrong number?

Dear Vendor:

That testy voice mail you left me whining about how you have been trying to get me and you hope I’m polite enough to call you back? Yeah; not so much.

Dear Vendor:

I think we got started wrong. I walked up to your booth wearing a suit and a convention name tag. Despite my utter lack of cleavage, you somehow thought I was a booth babe. Then you looked completely shocked when I happened to mention that I was the head of an IT department and might be in the market for your product. I’m wondering which forehead tattoo might have helped clear up the situation, and would really appreciate your help choosing one from the following list:

  • NOT a booth babe.
  • BS from MIT + MBA (highest honors) from Simmons
  • IT Director
  • Both a beauty AND a geek
  • Brains inside!

Sincerely,
Jenn

But seriously, if you’re a vendor and want my business, be friendly, understand what my company does, and solve a problem for me. If I don’t have a problem for you to solve right now, accept it gracefully and let me know that you’d still like to build a relationship with me. That’s what works for me, and will probably work for most of my colleagues as well.

On Transparency, Part III

·

To continue my omphaloskepsis on transparency, I find myself asking the question, “Why bother if they don’t even look for the information?”

A comment on my last post pointed out that the meeting wasn’t the point–the availability of the information was. While I certainly agree, I should mention that nearly all the information was already available in a central repository or two, but people still kept asking me for it. Saying, “go look here” every time seems awfully rude.

Which brings me back to my initial question: why invest the time and energy making the information available if no one uses the resources?

I’ve heard answers to this question like, “You have to train them.” Or, “They might only use the information if nothing else is available, but that’s when it’s really valuable.” While both answers have merit, there’s still one elephant in the room to me: scarce resources.

In this economy, very few IT departments have adequate resources. Some of us struggle to find the bodies for day-to-day support. Others can do that, but run out of bodies if anything goes wrong. Still others can handle those, but can’t do any projects. Given that daily user service is our first priority, how exactly do we find the time to also make information available?

While I don’t have a good answer for the “how” question, I’ve realized that making resources available both internally and externally is worth the time. Why? It all comes back to user service:

  • Users feel better served if geeks can answer their questions more readily.
  • Geeks feel more empowered if they know they have (or can find) information.
  • Users feel less helpless in a crisis if they can find an update faster (or know where to look).

I’m still trying to figure out how to train everyone to look in the developed resource repositories (namely the intranet for the users and the knowledgebase for the geeks), but I’m a little more satisfied that putting the information out there is worth it.

On Transparency, Part II

·

My apologies for the 2-week gap; I’ve been developing content for a blog that will launch mid-May.

But on to the subject: transparency. Again. In Part I, I discussed opening up my master project list to my peers and the anxiety that provoked. Now I’ll be talking about transparency inside my own department.

As the head of a (geek) department, I find it sometimes difficult to determine how much information to disseminate to my geeks. Unlike giving information to my peers, this uncertainty is not motivated by my fears. The primary reason I find it tough to figure out how much info to share within IT is that I read too much.

I’ve read articles on transparency and agreed with them. I’ve read articles on information overload and agreed with them. I’ve seen staff who drop out of meetings because they “just don’t need to know” and the information would confuse them or increase their stress levels. I’ve seen other staff completely frustrated by lack of information about what’s going on in other parts of the department. What’s a geek leader to do?

I don’t think there is an easy answer to that one. In my last department, we were small and seated all in the same area. At least once each day, we’d end up congregating at the Lit Support Specialist’s cube right outside my office. We would chat about anything and everything, ranging from childhood memories to weekend plans to current and upcoming projects. This worked well for us.

My current department, however, is twice as big and very spread out. We often congregate in the Help Desk area, but usually not the entire team together. I eventually realized (thanks to some rather gigantic “hints”) that the casual method of information sharing that worked at my last firm wasn’t going to fly at my current one.

So I started having weekly 30-minute meetings. I moved these meetings from the training room to the Help Desk area, since the Help Desk folks were having trouble making it on time and staying. After trying a few different times, we settled on a time when most of the firm was at lunch so the phones weren’t quite as continuous.

At some of these meetings, I do most of the talking. For example, when I started a new change management procedure, we spent most of the time talking about that. At other meetings, we go around the room and each person talks about his or her current projects or issues. Each geek shares as much as he pleases or tunes out if he doesn’t want to know. They have access to my master project list (the live document) and can question anything they please. (Somehow, this doesn’t cause me any fear. This is probably a good thing.)

We’re still trying to get to the appropriate level of granularity, since not all my staff talks to each other often enough to disseminate solutions to specific problems. I have to admit that I find that frustrating, since a 30-minute meeting is only long enough for brief discussions. But we’re getting better.

I have to wonder, though, if there’s ever a “perfect” level of internal transparency. If so, anyone know what it is?

On Transparency, Part I

·

Finally! Here it is folks, Part I of some of my thoughts on transparency.

I really thought I was into this Enterprise 2.0 collaboration/transparency/etc. thing. I thought I was all enlightened and loved to communicate. Then I decided to do something completely unexpected and shared a link to my master project list (all 14 pages of it) with my peer directors at my firm so that they would know about upcoming IT changes. You know what I found out?

Transparency is SCARY! Why?

  • If people know what you’re doing all the time, they’ll know when you’re doing something wrong.
  • Opening the kimono (so to speak) invites people to comment on what’s going on. Even if you don’t want them to!
  • If you’re the first person in your company to open the blinds, people will know much more about your work/department than you’ll know about theirs.
  • Even if you’re not doing anything wrong, the more people know, the more gossip (both positive and negative) will happen about your doings.

So I sent the email (while experiencing all of the above fears) and held my breath. “What if they think I’m nuts? What if I’m doing something wrong? Do I want them to be able to tell me what I’m doing wrong when I don’t know what they’re doing to attack back?” These thoughts were surprising to me. I always claim that I could LIVE on camera given the chance. But no, I was paranoid about sharing a document that included information that I would have been happy to tell each of them in-person instead.

Results? Well, no one has said anything. One person has looked at it. I’m honestly glad I did it, if only to experience some of the feelings that people have that make them hesitant about opening things up.

On Letting Go

·

I’m not very good at letting things go. I have learned to forgive easily (I’m pretty much incapable of bearing a grudge), but if I know that someone is carrying around a misconception, it will literally keep me up at night. I want people to know and understand the RIGHT answers to their questions. I want people to thoroughly understand ALL my reasons for doing something (at least from a high level). I want my husband to know EVERYTHING he’s doing wrong.

Okay, I’ve grown out of that last one (mostly), but I still have trouble letting things go.

For example, some of the commenters on my post, “Why IT Goes Nuts Sometimes,” have the impression that I’m nuts because I have to deal with stuff coming to my predecessor instead of to me. (That doesn’t bug me at all; the non-support by the guy who emailed me was what drove me nuts.) Knowing that these commenters had the wrong impression has seriously bugged me until this moment, when I could correct it in this post.

Why do I need to let go of my lack of letting things go?

  • Most people’s brains, attention spans, and patience cannot take a rapid-fire list of everything.
  • Contrary to what I usually like to think, I am not always right.
  • I don’t ever want to know every little detail of something. (And it actually drives me nuts when geeks do a deep-dive into the how-to or how something works in a 30-minute meeting.)
  • Most people don’t really care about having the wrong impression of something trivial.

In my experience, many geeks have this same tendency (Edit: You know, like this comic.). This is why management gets bored with technical details or users get frustrated at lengthy explanations. Does my boss care about every high-level reason behind my strategy? Nope; just the most important business-related ones.

Just as I get frustrated with getting bogged down in details, others get frustrated by long lists of abstract reasons. Or worse, lists of their faults or mistakes as I see them. Now that I’m more cognizant of this, perhaps I can let it go.

On Tactics

·

Like most heads of IT Departments, I have a long-term strategy in place. Granted, it’s vague (it has to be), but I look at industry trends, technology trends, and my firm’s history, shake them all up, and dump them out into a crystal ball. I gaze into the crystal ball and take a stab at where we’ll need to be in the next 3-5 years.

I also have a shorter-term strategy, where the next year’s goals are more concretely expressed. I determine the probable larger capital expenses and figure out generally where we’ll be in a year in the hardware, software, staffing, and user experience realms.

Tactics, however, are where I might depart from the “normal” way of doing things. See, my tactics are never truly solidified beyond the next step or two. Why? Because I plan my tactics according to the Theory of Constraints.

(Brief note to my Operations prof: See? I listened in class and even read The Goal!)

How does this play out? Well, I’m so glad you asked!

  1. I collect all of the various tactical components I need to have done in order to accomplish my short-term strategy.
  2. I determine which of said components are dependent (e.g., I have to move File/Print off of two blades before I can expand my Citrix farm onto the same blades).
  3. I determine which immediate actions will address the most user pain.
  4. I execute that set of actions. (Okay, so it’s actually mostly my geeks and various consultants who do the true execution here, but you already knew that.)
  5. I move to the next most painful item, and continue the process.

Someday, I hope to run out of user pain to address such that I can manage more proactively. In other words, I hope to find the “bottleneck” that will cause pain and address it before the users feel the pain.

On the one hand, this gives me a lot of freedom to be more agile in implementation. On the other hand, it can drive some of my linear thinkers insane…

Why IT Goes Nuts Sometimes

·

I still have lots of thoughts on the transparency discussion going on in my brain; eventually they will become a useful blog post.

However, I just thought I’d share briefly on why I go nuts sometimes…

So it’s time for us to renew an SSL certificate. How do I find out? The email goes to my predecessor’s email account.

But not to his name; that was to an old network engineer who left well over a year ago.

Okay; fine. I go to the link, try to renew, etc. I can’t. I don’t have the password for it, and it’s not on my (10 page) password list.

Again, fine. I’ll put in the email of the technical contact.

Doesn’t work.

Try a different one.

Still doesn’t work.

Try every possible permutation of every IT Director or Network Manager/Engineer and domain name. No luck.

Email customer service rep that I need help renewing, because I cannot get the website method to work.

What does he do?

Sends me the same $%^&* links, and says I have to renew that way. And you all wonder why I’m slightly nuts sometimes?

On Information

· 1 Comment ·

Years ago, a friend’s parents told me a story of when they decided that he could and should start taking responsibility for his own decisions. At the end of winter break, they decided to let him make the call of when to leave for the airport for the plane back to Boston. They asked him what time to leave, and, when he named a time, they knew it was too late. However, they didn’t say anything. He missed his plane, of course, and had to work with the airline to get back to Boston.

I mentioned this to him later (they told me the story in his absence), and his response was, “You’re kidding! I honestly thought the plane was an hour later! I wish they’d at least said something about the time so that I could have known. That really pisses me off.”

To a large extent, I know how he feels. Somehow, geeks often expect their leaders to know about things and act upon them, but they haven’t told us the time of departure. Likewise, users will sit on a problem for a long time and expect geeks to fix it. Their (usually irate) conversation goes something like this:

User: As you know, this has been a problem for a while.

Geek: Uh… I’m sorry; I didn’t know. For how long has it been a problem?

User: Since I called you six months ago and told you about it.

Geek: I’m sorry; I thought we resolved it at the time.

User: Well, you fixed it for me that once, but it keeps happening, and I’m just at the end of my rope!! Why are you so incompetent!?!?

At this point, the geek gets off the phone and drinks heavil–er, fixes or escalates the problem appropriately.

Geeks and leaders of geeks aren’t mind readers, and we’re not perfect. Sometimes, especially if things have been stressful, we completely forget to follow up on a problem or assume it’s fixed. That problem was one of 40 or so that the geek heard or found and fixed that day. (That’s not an excuse, but it is an explanation.)

Leaders are often treated similarly to the geek above. Maybe I forgot to return your phone call when the systems crashed. Maybe I didn’t get back to you about that great project idea you had. Please tell me. Please remind me. I’m sorry if I dropped the ball, but I can’t fix something if I don’t know it’s broken.

By giving me information, you help me to know the following:

  • The problem still exists.
  • The problem is important to you.
  • I need to either take or facilitate action to resolve the problem.

If I cannot address the problem immediately, I need to manage your expectations such that you know I haven’t forgotten about it. As I often say, if I don’t know about something, I cannot fix it. Or, to put it another way (as my Help Desk often hears me say after they get off of a call like the one above), “Help me help you.” I cannot do that without information.