Category: general leadership

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 New Brooms

·

So the classic perception is that the new boss can–and will–make sweeping changes to an organization and staffing.

I can’t say this is very wrong.

I happen to be fortunate that my new staff is excellent, but there aren’t enough of them. And the systems? Well, let’s just say that we need to tweak them a bit, but I have a great foundation on which to work.

But I was having a conversation this morning with my senior network engineer, and we made the observation that I have about 6 months until I won’t be able to easily make big changes. So I need to move fairly quickly.

I plan to take the following steps:

  1. Assess
  2. Propose
  3. Execute

I’m almost done with step 1 now, and I hope to do step 2 next week. One thing I plan to do a bit differently, however, is that I will first get feedback from my staff on the proposal. After all, they already know the systems and players.

On Flex Time: How to Fail

·

In my last post about making flex time successful, I talked about some best practices that I find make flex time a beautiful thing for everyone involved. Now I’ll chat about how to completely fail with flex time.

  1. Be grouchy about it. Your employees aren’t stupid, and they know when you’re unhappy about something. If you resent employees who have flex time, you’ll damage their morale, and give other employees good reason to be grumpy about their co-workers’ arrangements.
  2. Don’t listen to complaints. Let’s say you have an employee who works weekends and takes off Thursdays and Fridays to take care of the kids. This arrangement seems fine, and then you have a huge roll-out that is scheduled to go live on a Thursday. This employee, a vital engineer on the project, might not think that he needs to be there on that Thursday. People complain, and you just shrug. The roll-out is harder, morale suffers, and people start resenting the flex person. This is sub-optimal for teamwork, to say the least.
  3. Don’t plan for it. Make sure you remember that someone has a four-day week when you’re planning projects and schedules. You cannot always depend on that person to show up on every Friday to make up for your poor planning–wouldn’t that defeat the purpose of flex time?

I’m sure there are many other creative ways to fail at flex time, but I’m hoping that these two entries will help you avoid them.

On Flex Time: Making it Successful

·

I blogged a bit about flex time in my post On Insomnia, but I’ve been thinking about what makes flex time successful (or not!), and I thought I’d post my thoughts here. This post is about what to do to help make flex time successful (my next will be on what might cause flex time to fail).

  1. Bilateral flexibility. Both the employer and the employee must be flexible. I had an employee once who worked a 4-day 32-hour work week, and did not work on Fridays (when daycare was closed). However, if I ever needed her to come in on a Friday for a large project or emergency, she put her son in back-up care or called on a relative and was there. Likewise, if she ever wanted to trade a Tuesday (or other day) for a Friday, I let her do so as long as the work allowed it. The bilateral flexibility made this arrangement a resounding success.
  2. Core hours. In order to facilitate teamwork (and I’m not sure there are many modern work environments that don’t need teamwork!), core hours are vital. Team members need to know when they can find each other for questions, brainstorming, etc. I held core hours for my last department to 9:30-4:00, which were hours when everyone’s work schedule overlapped. If I were working in a software company, I might set those hours to 11:00-3:00 in order to handle both my night owl programmers and the crazy early birds who need to pick their kids up from school.
  3. Don’t give flex time if the job isn’t flexible. While it’s admirable for all companies to want to grant flex time, sometimes it just isn’t happening. Nursing shifts have to start and end at specific times. Utility trucks have to all roll out at a certain hour. The help desk has to be covered from 8:00 AM-8:00 PM.
  4. Be honest during the recruiting process. If the job isn’t flexible, don’t tell a great candidate that he or she might be able to negotiate it later. Be up-front about expectations during the initial interview in order to recruit and keep great employees (this goes for much more than just flex time).
  5. Don’t only grant flex time to your favorites. If someone in a certain job has flex time, you have to be prepared for everyone else in the same role to ask for it. If you only granted it to one person due to special circumstances, be honest and communicate the circumstances (within reason–don’t disclose private HR issues) to that person’s co-workers.

Stay tuned for my next flex time post on mistakes I’ve seen (not just the flip side of the five best practices above–honest!). I figure it’ll come out next week…

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.

On Humor

·

While checking my previous entries before titling this post, I was shocked to discover that I have not yet written on humor. This shocked me because one of the first things that many people notice about me is (and I quote), “You have a sense of humor!” To which I always respond, “Yes; I’ve been accused of that before.” Someday, I’ll think of something funnier to say. But onward and upward, here, to what humor has to do with leadership.

I’ve mentioned before, in my posts On Morale and On Complementary Strengths, that laughter and having fun can build better teams, but I’ve never explicitly talked about humor and leadership. I believe that having a sense of humor has really helped me to be a much better leader.

Why? Because I have to be able to to the following:

  1. Laugh at myself. I am not always right (contrary to my wishes), and sometimes I can be glaringly, blindingly, amusingly, and hilariously wrong. By laughing at myself in front of and with my geeks, I made it easier for them to call me whenever I was wrong about something. I also made it easier for me to call myself whenever I was wrong.
  2. Laugh in difficult situations. You know those situations where you either have to laugh or cry? Creating an environment where people laugh in those situations alleviates most of the tension that makes people miserable. Did you geek just field the stupidest user question ever? Better to laugh, right?
  3. Have fun at work. My favorite geek team memories usually involve laughing until tears roll down my face. We had one team member on my last staff who would say many things before speaking, causing us to completely lose it regularly. Guess who was our favorite team member?

But having a sense of humor at work–especially as the boss–means that you have to be careful as well:

  1. Watch for off-color humor. Not to say that you must always speak acceptably for the Queen of England, but (especially as the boss) you must never cross the line from a legal perspective. Yes; that means leave your risqué humor at home. Especially in a mixed-gender team.
  2. Don’t hurt people’s feelings. That team member who opened her mouth before engaging her brain? We couldn’t always laugh at her foibles, because sometimes she was a bit more sensitive about being wrong. You won’t always be perfect, so learn to apologize.
  3. Don’t laugh at the expense of getting things done. It’s always more fun to stand around and make each other laugh than re-wire all the switches. But you should learn to laugh while getting the job done (most of the time, anyhow). After all, unless you’re a comedian, you’re not being paid to make people laugh.

Overall, humor is incredibly important while you’re leading geeks. But, as with all things, responsibility and balance are key components to making humor work in a business environment.

On Grammar

·

Most geeks I’ve encountered in the technology world aren’t exactly well-rounded. Many of them excelled at math or science (or simply computers), but ignored English class. As a result, they are absolutely brilliant at their technical jobs, but act like it’s the end of the world if they have to write a business memo.

As a geek leader, however, you cannot afford the same luxury. Your department or group must be able to present a business-like face to your company or the outside world–especially in printed memoranda or publications. Due to your geeks’ probable dislike of writing, this duty will fall in your lap.

I was fortunate enough to be an English geek in school, and therefore understood and was able to teach my geeks the basic rules of grammar (not that I am always perfect, as you can see by reading this blog). Well, I could at least teach them about my pet peeves. However, no matter how many rules they eventually learned, I eventually learned that I had to proofread most communications that they sent outside the department. Not usually for message, but always for grammar. I also sent out fairly regular “grammar Nazi” emails to my department–usually the cause for some hilarity.

If you are a leader of geeks and don’t feel comfortable with your writing or your grammar, I would strongly suggest reading books on business writing. You can even Google things about which you are unsure. Your geeks might not seem to appreciate your efforts, but your boss will.