I once worked for someone whose pattern of rampant dishonesty blew my mind. Shortly after beginning work, I realized two things: Ernie absolutely could not admit that he was wrong, and he consistently lied to everyone around him – coworkers, staff, and users.
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:
Seriously loving the storytelling aspect of marketing today. Anyone else enjoy that?
— Jenn Steele (@jennsteele) September 10, 2013
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.
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:
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.
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?
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.
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:
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.
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.
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:
Perception counts. Manage it well by communicating and playing nice.
One of the most unfortunate business practices I’ve seen is management’s failure to consult geeks before committing to deadlines. I’ve experienced this personally (“We’re moving in two months and need all new technology! We haven’t signed any contracts or bought any hardware! Have fun!”), and have inflicted various forms of it on my geeks (“We had a flood in the server room. We have to be up and running yesterday.”). In any form, however, it’s sub-optimal at best.
Failure to consult geeks before making hard deadline commitments to clients, however, is one of the more horrifying forms of scheduling nightmares. While this obviously happens more often in software companies, any company with a geek-driven client-facing product or service has probably run into this problem.
As much as I’d like to portray geeks as the poor, unfortunate victims of this hideous management practice, I cannot. To some extent, geeks (and their direct leaders) bring this on themselves. How? Well, how many times have you had or heard this conversation:
Geek Leader: We need to do [project]. By when can you get it done?
Geek: That depends.
GL: On what?
G: Well, I’d have to investigate to find out.
GL: Can you give me anything? Ballpark? Something? I need to tell the client by today so that we can get the contract signed.
G: Uh, I guess it could take anywhere from three weeks to three months.
GL: @#$%^&*()!!!
The geek has undoubtedly given the geek leader accurate responses. Unfortunately, the responses are completely useless to the geek leader. And the contract has to be signed, because the business needs the money. The geek leader will probably make something up based on previous projects and have the client sign off on it. The geek leader will then inform the geek, who will be absolutely flabbergasted at the miracle that she must pull off–doesn’t the geek leader understand ANYthing???
The very nature of geek products and services prevent accurate estimates of time. However, the geek and geek leader might have a little more luck by following these steps in trying to form a deadline:
Will it be perfect? Of course not. Will it lead to better estimates and fewer necessary miracles? Probably. This process can be initiated by either the geek or the geek leader. It might take a little time, but will lead to happier geeks (and clients–after all, you’ll probably blow fewer deadlines!).
Did that title get your attention? Good. The title will become clear…
Geek leaders (and the geeks who follow them) are often frustrated by the business folk in their company. We present upper management with a brilliant solution to some obvious problem, only to be shot down. “Morons!” We think. “How can they not see that my solution will be the panacea that this company needs???”
Lather, rinse, repeat. After a few cycles, the geeks or geek leaders come to the blindingly obvious conclusion that the company is being run by a bunch of idiots.
Okay; maybe the business folk aren’t the whiz kids that the geeks always have been, but they probably have more active brain cells than geeks think. So where’s the disconnect? Why don’t the business folk see the obvious solutions? Why can’t the geeks and geek leaders convince them?
It’s a foot issue. Anyone tends to lead with their most-used foot. Unfortunately, it’s not the same foot that the business folk receive well (the metaphor breaks here, but I figure you’ll forgive me). The business folk expect to see the business foot come first, and when they see the geek foot, many of them tune out instantly and never hear the geek leader’s (valid) arguments–either business or technical.
Think of it as a marching band. All of the members had to learn to lead with the same foot to begin, or else–chaos. In business, geeks and geek leaders have to learn to lead with the business foot (to business folks, who are also leading with their business foot), or else–chaos.
Are the technical arguments stronger than the business case? Probably. But the point isn’t to lead with what you think are the strongest arguments–it’s to get your proposed solution approved. While leading with the business foot feels awkward and wrong, it’s the foot that will get through to the business folk. And then, when they actually listen and approve your solution? Maybe you’ll discover that they’re not quite as dumb as you thought…
You can find On Language, Part 1 here.
If you are a leader of geeks, you will find that you often have to translate their tasks and projects to someone above. Someone distinctly NOT a geek. Someone who might think that the word “incentivize” is a perfectly reasonable thing to say. Clearly, this person has no idea what an IP address is, wouldn’t know a heap from a haystack, and may have put a CD in the holder with the label side down once or twice.
He and the geeks just don’t speak the same language. Literally.
So what do you do? You prepare.
If your geek has just explained something that will “massively improve business as we know it!!!” Your first inclination might be to run into the non-geek’s office and tell him all about it! The problem is that he’s not going to understand a word, and will probably just get frustrated and angry. Trust me, I’ve done this before. It works about as well as trying to use business-school speak with geeks, and the non-geek can probably make your life a lot more miserable than they can.
When you do run to the non-geek’s office (I’d actually suggest setting up a meeting and telling him what it’s about), you need to lead with the business–not the technology. Will the solution fix the painfully slow Citrix problem? Then tell him that your geek has found the solution for the remote access problem, and give him timelines and resource requirements for implementation. Can you massively cut costs with the solution? Then lead with that.
If you spend the bulk of your time with your geeks, leading with your business foot will not be your first inclination, because you spend most of your time hopping around on your geek foot. This foot, unfortunately, is more likely to step on a non-geek’s toes (geek feet being more awkward and all that). If you think about which foot you use when you walk into the non-geek’s office, you’ll be more likely to have a leg to stand on.
Really bad puns aside, this type of translation takes practice. If you haven’t had the (mis)fortune of going to business school, listen to the language that the non-geek speaks and use that kind of language when you communicate with him. It might feel annoying or awkward (try not to roll your eyes when he says “synergy”), but it will make your job, your geek’s job, and the business guy’s job much easier in the long run.
Leading Geeks 