Month: March 2009

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.