Category: managing up

Telling Stories – Even in Technology

Recently, I got to have a blast telling a story. We put together a story about our company’s two-year history and posted it to SlideShare. In fact, I had so much fun that I’m going to show it, and then get on with my post:

I hope you flipped through that, because I work with a great bunch of folks who have senses of humor similar to mine (which is pretty darn remarkable when you think about it).

But anyhow, on to my point: storytelling.

When I was working on the storyboard for the slideshare, I tweeted:

And it’s true – I had a blast with the storytelling part of marketing.  So I started mentally composing this post all about storytelling and marketing and yada yada yada.  Then I realized something: storytelling isn’t isolated to marketing. In fact, I may have done more storytelling in technology than I do now.

Think about it for a second. What are you doing when someone asks you what’s going on? Or what happened? Or why the $%^&* exchange server is going on?

You’re telling a story.

You may be telling the story of the heat in the server room that caused the hard drive in the SAN to degrade combined with the SAN being too full to replicate when you swapped the drive. (Not that I’ve ever told that story or anything. Nope, not me.) Maybe you’re telling the story of the bug that flipped all the bits and made your product choke for six hours while you fixed it. Or maybe you’re telling the story of a budget that’s stretched too thin for what you need to do.

Whatever it is, you’re storytelling.

And with all good stories, yours needs to have a beginning, middle, and end. It also needs to have a plot people can follow. Frankly, as geeks, we pretty much suck at this. We give too much detail, or we leave out the beginning or the end. Whatever we do too much of (or not enough of), we lose our audience. Or we fail to consider our audience. Or something like that.

We’re always telling stories. If we’re aware of that, our communication – especially to non-geeks – will likely get infinitely better.

On Wars and Battles

Over the past few weeks, I’ve found myself using the phrase, “Right war, wrong battle.” As a principled leader, I’ve fought wrong battles many times without realizing that fighting those battles may have cost me the wars I was trying to win. As a geek, I’ve found myself doing the same thing. I’ve been so concerned with doing things right that I miss out on my chance to do what might be far more effective in achieving the right result.

Think of it this way: if you use all of your ammunition in winning a single battle, you won’t be able to fight in subsequent battles, which will cost you the war. Whether your ammunition is political capital, human resources, trust, or budget, this analogy holds.

I’m resolving to ask myself the following questions:

  • What war am I trying to fight?
  • Is this situation simply a skirmish?
  • Will winning this battle cost me the war?
  • Is there a better battle for me to fight?
  • What is my ammunition? What resources am I burning to fight this battle?

Surrendering a battle isn’t my nature. I am passionate about achieving effective, efficient results for my company, and my default behavior is to fight for that in every situation. I’m hoping, however, that by prioritizing the war over each battle, I will become a more effective leader.

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 Information

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.

On the Blame Game

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 Managing Expectations

My apologies to my faithful readers who expected a post yesterday. Somehow that whole week starting on Tuesday thing really threw me off, and I’m swamped this week, with something due for the BU course for which I’m adjunct faculty and the Simmons course I’m taking right now.

Being late for this post got me thinking about how I manage expectations whenever I lead geek projects (and, having no PMO at any of my last organizations, I managed projects for a HUGE percentage of my time).

Here are my top five ways to manage customer and team expectations:

  1. As I mentioned in my post On Scheduling, first build as accurate a time line and due date as possible. Build in all known issues and be up-front about warnings or traded priorities (this last very important for internal customers).
  2. Communicate!!! Your geeks MUST know relevant due dates in order to prioritize and schedule themselves. Your customers MUST know if you’re likely going to miss the agreed-upon date, and they should know as soon as possible in order to plan. Likewise, geeks and customers must know and agree on specifications, requirements, and deliverables.
  3. Make nice with your geeks. If a geek has to give up weekends or family time in order to hit the deadline and specifications, do something nice in return. I mention in my post On Trading that I once traded a bottle of vodka for a sacrificed vacation day during a crisis.
  4. Make nice with your customers. When I was a customer and a vendor had to miss a scheduled due date, I’d occasionally get taken out to lunch or receive a box of cookies for my staff as a thanks for my patience. Obviously, follow your company’s rules and regulations for things like this.
  5. One of my favorite things to do while managing deadline expectations was to estimate a new deadline and then beat it. It’s all about managing perception–if I haven’t communicated with you and we come in a week late, you’re really annoyed. If I tell you we’ll be two weeks late, send you a bottle of wine in thanks for your patience, and then come in only one week late, you’re pleasantly surprised.

Perception counts. Manage it well by communicating and playing nice.