Actually solving problems

I get it. We’re all stressed. Most of us are working ridiculous numbers of hours and maybe only about 40% of it is in our primary skill set (or at least that’s where I am right now).  But after reading this story about a keyboard/mouse issue at the Shark Tank, I had to let this out before I burst.  WHY DO WE INSIST ON NOT SOLVING PROBLEMS?

English: A Microsoft Arc wireless mouse. You c...
Microsoft Arc wireless mouse. (Photo credit: Wikipedia)

In this story, the user insists on keeping her mouse pad, even though it doesn’t play with her new wireless mouse, which came in a wireless keyboard/mouse combo.  What does the geek do?  He walks out of her office.

Seriously? No, really, seriously?

He doesn’t say, “Okay, we’ll use your old mouse, then,” swap it, and then walk out with a great story to tell over drinks to other geeks.  He walks out, because he couldn’t get beyond what he saw as stupidity and stubbornness.  He decided to be stupid and stubborn right back.

Quite frankly, if one of my geeks had done that, he would have received a stern talking to, if not an HR write-up. Solving her problem is this geek’s job. Maybe it’s annoying as all heck to have to cater to “stupid users,” but it’s your job, so suck it up.  Try to figure out a way to actually solve the problem.  If you can’t move the mountain, go to the darn thing, will you? If you can’t budge the crazy user, at least try to make her happy.  TRY. If you fail, chances are that she’ll be way more likely to swap mouse pads.

I see behavior like this more and more. We have arguments where we should actually negotiate. We complain about problems rather than actually trying to fix things.

Stop it already, okay?

Management styles: chutes, shields, and shows

I’m becoming convinced that there are three basic types of managers: chutes, shields, and shows.  Each of these types should be preceded by a certain word that I won’t say on my blog, so let’s call it stuff.

English: Chute spillway of Pando dam
English: Chute spillway of Pando dam (Photo credit: Wikipedia)

Stuff Chutes

Especially if you’re a new manager, is is incredibly easy to be a stuff chute. If you’re a chute, you take all the stuff generated above you, concentrate it, and direct it directly at your staff. You’re a chute if you:

  • Always tell your team about any and all stress/upset by the Powers That Be (PTBs)
  • Use implied pressure from the Powers That Be to motivate your staff (note: NOT motivating. NOT. No way, no how.)
  • Ensure that the Powers That Be know exactly who did anything wrong (who wasn’t you)

If you haven’t figured it out, you don’t want to be a chute. Maybe you think you’re doing things right by being transparent about the “hair on fire” attitude of the PTBs, but what you’re really doing is concentrating all of the stuff from them and stressing out your team with it. Unfortunately, chutes tend to have stressed out staff who dislike their employers, which leads to morale and retention problems.

E3 2011 - Captain America's shield from Captai...
E3 2011 – Captain America’s shield from Captain America: the First Avenger (Sega) (Photo credit: Pop Culture Geek)

Stuff Shields

It’s definitely harder to be a stuff shield. You have to walk the tightrope between transparency with your team and shielding them from the stuff from above. You’re a shield if you:

  • Give your team credit for everything that goes right while taking the blame for everything that doesn’t
  • When the PTBs go into panic mode, indicate that there’s stress above, but don’t go into enough detail to pass that stress along
  • Motivate your team positively, rather than with threats

In the battle of the corporate world, shields sometimes fail (as you might), but you can always re-arm.  (Did I push that metaphor too far? Sorry about that…)

Closed red curtain at the Coolidge Corner Thea...
Closed red curtain at the Coolidge Corner Theatre – landscape (Photo credit: brokentrinkets)

Stuff Shows

The most annoying managers create their own stuff, so I call them stuff shows. They might also be chutes – or even (rarely) shields – but they primarily function as shows. You might be a show if you:

  • Regularly lose your temper or show your extreme stress to your team, especially in the context of trying to make them do things
  • Give your staff instructions, only to change them afterwards (possibly multiple times) with no justification or explanation to help them understand why the change is necessary
  • Expect your team to read your mind, and chastise them for not conforming to your (secret) requirements

I can come up with an almost endless list of how to be a show, but I’m hoping you get the idea.

Clearly, you’d rather be a shield than a chute or a show. Unfortunately, I’ve seen very few managers who are shields who haven’t spent significant time and effort on meeting the needs of their team. How to be a shield, however, is a post for another day.

Are you a bottleneck?

Is your staff frustrated? Do you feel like they’re all inefficient? Is there a line every night out your office door and a long queue of email from your team awaiting your reply? If so, I have news for you – the problem probably isn’t your geeks. The problem is mostly likely you.

bottleneck
bottleneck (Photo credit: DailyM = Differentieel + JeeeM)

You have become a bottleneck.

You probably meant well.  Or maybe your team is new.  Or maybe you suck at documentation (heck, I sure do).  You probably have great reasons for it, but it’s still an issue – geeks get incredibly frustrated when their boss becomes a bottleneck.

Honestly, it’s going to take significant effort to stop being a bottleneck.  However, it’s entirely worth it – your team will be happier, your stress will be lower, and everyone will get a heck of a lot more done.  Here’s what you need to work on:

  • Trust. Look, you have to trust your geeks.  You have to trust that they’ll do their jobs, and you have to communicate that trust to them.  Yes, this means you have to accept that they might not do things exactly the same way you will, but if you don’t trust, well, get used to having to hire replacements. 🙂
  • Communicate. Your geeks must be clear about your expectations, or they’ll constantly double-check things with you.  Proactively communicate about what you expect to see from their work.
  • Establish Patterns. If each project has a different reporting mechanism, you’ll get stuck telling everyone how to report on each new task.  You’ll also get stuck double-checking their work, since they’ll never know what constitutes acceptable results and reporting.
  • Teach. Giving someone step-by-step instructions differs from truly teaching someone. Spending extra time making sure your geeks understand why they’re doing what they’re doing, how you think about problems like the ones they’re trying to solve, and what success looks like means that they can pattern-match for subsequent tasks. And that means that they won’t queue outside your office as much.

Investing this time will certainly help with frustration, stress, and constant questions.  You should note, however, that you’ll still need a good way to keep tabs on projects and problems once your geeks no longer ask you about everything. The best advice I’ve ever read on how to do that is in The One Minute Manager Meets the Monkey. It’s a quick read, and totally worth it (even if it’s not on Kindle yet.  Grrrrr.)!

2012 in review

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 2,400 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 4 years to get that many views.

Click here to see the complete report.

My main takeaway?  Get off my butt and BLOG in 2013!

Getting better at being wrong

WRONG WAY
WRONG WAY (Photo credit: CarbonNYC)

A few days ago, someone corrected a mistake that I made. I nodded and said, “Now I know.”

Perhaps this doesn’t seem like a strange situation to you, but it represents a lot of personal growth for me.

I have spent most of my life sucking at being wrong. I don’t think that this is unusual for many geeks – we build our self-esteem on our brains, and our brains are rarely wrong. Therefore, we seriously lack practice. It can be embarrassing to be wrong as well. When I was in elementary school, my friends would giggle with glee if I was wrong about something, and they’d tease me about it for days.

I got to the point that I would be defensive about being wrong. It was never that I was actually wrong, but that there were circumstances beyond my control. Like aliens stole my brain, or this other person was wrong and told me the wrong things. In retrospect, I’m sure I looked even more ridiculous by being defensive, but I would do just about anything to avoid admitting that I made a mistake.

I was in a singing group in college (with a bunch of other geeks – our name was a calculus term), and we used to always tell each other to sing more loudly by saying, “If you’re going to be wrong, be wrong loud enough that you can tell and fix it!” This was hard for me, as my mistakes would be (gasp) heard! Before I could fix them! But I eventually realized it was better to be wrong in practice and corrected than to carry the mistake over to our performance.

While I would love to say that I got better immediately after this experience, that wouldn’t be honest. I’m sure I could tell you lots of stories of my being in denial about being wrong over the years, but I’ve apparently blocked them out.

Eventually, however, I made another step. I realized that if I didn’t know that I was doing something wrong, I couldn’t fix it. I would just continue to do the wrong thing, and the consequences could be rough. Folks could quit if they disliked how I treated them, or I could really blow a budget or project based on an incorrect assumption. I developed a pretty strict policy of, “If I don’t know about it, I can’t fix it.”

By developing this policy and treating being wrong (and finding out about it) as a learning experience, I eventually came to value being corrected. I’ve also worked at a few non-law firm companies now, where being wrong is treated as more of a learning experience than an exercise in shifting blame, which has helped me a lot. I can’t say that it doesn’t still embarrass me – I did blush when I was corrected earlier this week – but I have finally learned to accept it and move on.

Making people successful

Perhaps I’m a bit optimistic, but I am inherently convinced that anyone can be successful given the right attitude and circumstances.

Two small test tubes held in spring clamps
Photo credit: Wikipedia

I think I came to this conclusion in college.  During my junior and senior years, I was a lab TA for the intro biology lab at MIT (7.02). This class had four major experiments (that I’ll call units), and the TAs would rotate between groups of students for each unit.  During my junior year’s class, one group of students had a 3-person team (all others were 2) that was known as being a complete disaster.  They had no idea what they were doing, and the other TAs would be constantly frustrated by getting them to work successfully on their experiments.

I’ve always been a bit rebellious, so when I rotated to this group on the third rotation, I decided that I wasn’t going to let the other TAs’ frustrations influence me.  I spent the first day of that rotation watching and listening to them.  I discovered that they were struggling to take the protocols designed for two people and expand them to three without being confused.  I started working with them to try to more effectively divide and conquer each day’s tasks (and I had the advantage of having the best teacher for this myself – my lab partner the previous year had been SO GOOD at strategizing in the lab that I had learned some amazing ways to do it).  At the end of that unit, when it came time to grade them, I was able to grade each of them a full letter grade higher than anyone had been able to during the first two units.

My experience with the “disaster” team convinced me that setting up the right circumstances could help pretty much anyone be successful. It (along with my experiences later) taught me that, to make people successful, I needed to:

  1. Watch and learn. Had I not taken the time to watch the “disaster” team to find out what was going wrong, I never would have been able to figure out how to fix it.
  2. Identify the real problem or challenge. And I don’t mean identify the problem that I thought existed before going into the situation . With the “disaster” team, we honestly just assumed they weren’t very good at biology lab. It turned out that their real problem was struggling with logistics.
  3. Communicate. Quite frankly, the “disaster” team knew that they were pretty disastrous.  By talking to them about what I’d observed and the problems I’d identified, I got their buy-in to try to fix the problem together.
  4. Change the circumstances. Once we decided to try to fix the problem together , the “disaster” team and I talked every day about ways to solve it. As time went by, they felt more comfortable proposing their own solutions and asking me questions.

I’m not saying that my “disaster” team all pulled their grades up to As.  But they definitely improved because we were working together to create successful circumstances for them.

In the business world, I’ve learned that successful circumstances don’t always include the current role for someone. The strategies I’ve used to address that (after I’ve exhausted the above) include giving negative feedback and, eventually, terminating the person. Luckily, however, I’ve found that more often I can (with the help of the person) create an environment that helps make him or her successful.

I am a stealth geek

Jenn Steele: Stealth GeekIt’s been a while since I posted, so I figured I’d introduce myself:

Hi. I’m Jenn, and I am a stealth geek.

I would think that, by now, I would be accustomed to the surprised looks I get when I join in a conversation about Star Trek captains (Picard was the best. Stop arguing.) or Wheel of Time characters, but I still occasionally get puzzled by the surprise.  I think it’s because I truly believe that I’m a total geek.  (Well, okay. The nerd/geek/dork test says I’m pure nerd, but I’m going to own geek culture anyhow.)

Here’s why I believe in my heart of hearts that I’m a geek:

  • I LOVE reading epic fantasy (my username at MIT was arwen. Do I really need to say more?).
  • I hate not having admin rights on a computer.
  • I have a slashdot login.
  • I lived on the “geeky” side of campus when I went to MIT.
  • Speaking of which, I did go to one of the geekiest schools in the country.
  • When I was in IT, when a new server came I would immediately want to open it up to see the components.
  • My favorite TV shows and movies usually have to do with magic, dragons, superheroes, sci fi, aliens, or whatnot.  I am a HUGE Joss Whedon fan.
  • I play video games for fun.
  • I deeply love intellectual debates.
  • I WILL correct you if you’re wrong.

Despite being a bit geeky deep down (a bit – who am I kidding?), I don’t necessarily come across as one.  I have some theories as to this as well:

  • I am an extrovert. Quite massively so.
  • I love talking to people.
  • I currently work in marketing.
  • I wear make-up.
  • I smell kinda good. (I wear perfume.  “Good” is subjective.)
  • I don’t wear glasses (during the day).
  • I dress somewhat stylishly (yay Nordstrom stylists).
  • I have a Nordstrom stylist.
  • I’m really into exercise and physical fitness.
  • I once played a ditz in drama club and high school and I have NEVER gotten rid of some of those mannerisms.  Sigh.

All that said, I could be completely wrong.  What do you guys think?  (I will return to less narcissistic posts in the future, I swear.)

How I give negative feedback

emotion icon
emotion icon (Photo credit: Łukasz Strachanowski)

In my previous post, I talked about how to give negative feedback. In this post, I’ll describe the steps that I personally take when I have to give negative feedback to someone.

  1. Do my homework. First I have to make sure that I know what I’m talking about and why I need to give the feedback.  This also gives me a chance to make sure my emotions aren’t leading the conversation. Especially with geeks, I’ve found that facts trump emotion every time, so making sure I have factual arguments rather than emotional ones is key.
  2. Speak privately. Unless I’m giving negative feedback to a group, I always make sure my conversation is private. If I have a regular 1:1 and the feedback can wait until then, great.  Otherwise, I have to find a way to speak privately without interruption. This also means that I’m careful not to blindside my geek on the way to somewhere or in the middle of something – I have to make sure I have  her attention as well. Ideally, I also have Kleenex on hand just in case (although I don’t remember often making my geeks cry).
  3. Say, “I wanted to talk about situation x. Can you tell me what happened?” I never start with my side of the story. I’m a huge believer in the idea that there’s my side of the story, her side of the story, and then the truth. So I need to get the geek’s side of the story in order to even remotely approach the truth (this is especially true when I have to give negative feedback about a situation that I heard about second-hand). Letting the geek go first helps me do the following:
    1. Understand how she saw the situation.
    2. Understand the reason behind why she took the actions she did.
    3. Understand whether she already feels bad about it – does she understand why the situation didn’t go well, or does she think everything is fine? I approach the rest of the conversation VERY differently depending on her current perspective.
    4. Find out whether she has already taken steps to fix the situation.
    5. Find out whether she knows what she should have done instead.
  4. Base my response on where she is. If she doesn’t understand what went wrong, I talk about that so that she understands what was wrong about the situation. If she already knows and is sorry, I talk about how to fix it or move on.
  5. Bring up what she did RIGHT in the situation. Rarely is an event all bad – it’s vital that my geek knows what she did correctly so that she can repeat it!
  6. Make sure she knows how to handle this type of situation in the future. Quite frankly, giving negative feedback is completely useless if there’s no way to draw something positive out of the situation. And the most positive thing is to make sure that it won’t happen the same way next time.
  7. Have a pleasant ending OR come up with action steps. Depending on how my geek assimilates the information, we’ll need to agree on what to do next. Either we move on and talk about pleasant things or we need to come up with next steps (e.g., regular check-ins or how to fix the situation if anything is fixable).

Honestly, I’ve had this blow up in my face once or twice, but trial and error have led me to this overall methodology.  I’d love to hear about what other methods work for you!

Giving Negative Feedback

Block diagram for feedback
Block diagram for feedback (Photo credit: Wikipedia)

I have to admit that I hate the word “feedback”.  To me, it’s basically like saying, “I’m about to tell you just how much you suck, but I’m going to put it in business terms so that you can’t get pissed off or cry about it.”  (I may be exaggerating slightly.)

Nonetheless, no matter how I feel, I sometimes have to give negative feedback.  Here are the guidelines that I’ve figured out (mostly by doing things the wrong way):

  • ALWAYS always always get their side of the story.  I can’t tell you the number of times someone reported something “bad” about a geek that looked very different once I had both sides of the story.
  • Keep your emotions out of it. If possible, make sure you’re no longer pissed off before giving the feedback.  Sleep on it, drink on it, kvetch to your spouse about it – whatever you need to do to make sure that you’re not seething when you give the feedback, because, you need to…
  • Make sure it doesn’t get personal.  There’s a big difference between saying, “That came across as harsh,” and, “You’re harsh.” This isn’t about who they ARE, this is about what they did or how they behaved in the situation.
  • Be constructive. It’s not useful to tell them what they do wrong without telling them what they should have done instead. You want to help them learn? Guide them.  For example, one of my geeks once ended up on the floor of his office with a back spasm.  I happened to notice it when I realized all my other geeks were gathered around and making fun of him.  My feedback to them went something like this:

Remember when so-and-so was in his office on the floor with back pain and you were pointing and laughing?  Yeah. So, in the future, please first tell HR, then tell me, THEN point and laugh.  Got it?

  • Make sure they hear you. Especially if you’ve forgotten to leave your emotions at home, it’s easy to say things that wound your geeks and cause them to tune you out or emotionally shut down.  Make sure they’re responding to you normally, but if they’re not…
  • Let them go process it and then get back to you. You don’t NEED them to learn their lessons right away (or feel sorry or whatnot).  You need them, instead, to truly internalize what you’ve said in order for them to do things more correctly in the future. Especially if you’re managing introverts (which many geeks are), you need to give them feedback, tell them how you would have preferred things to go, and then let them go process it so that they can internalize it.  Always leave the conversation open so that they can come back to you with questions or arguments in the future.

This post is getting long, so I’ll leave examples to a future post.  However, what have I missed? What lessons have you learned about giving or receiving feedback?

The burned-out geek leader

I’ve been thinking recently about different types of leaders.  Or at least of different of types of behaviors that leaders might exhibit.  If I keep thinking about it, this may well turn into a series.  If I stop thinking about it, however, I reserve the right to change topics.

2007 Sturgis Motorcycle Rally. Burnout.
Image via Wikipedia

The first one that I thought I’d tackle is the burned-out geek leader.  Some signs your geek leader is burned out include…

  • She can’t remember much.
  • She seems to not pay attention to what’s going on unless it’s right in front of her face – she’s detached and unfocused.
  • She’s behind in email (well, more behind than usual).
  • She becomes obsessed with something that seems relatively insignificant – she has a very one-track mind (seems like a control issue).

I think that pretty much every leadership state has its pros and cons (even this one).

Pros:

  • If your manager is burned out, you get to pretty much just do your job.  Unless you’re working on that one thing with which she’s obsessed, she’ll just leave you alone.
  • You have a chance to shine by keeping things running while she doesn’t have the mental wherewithal to deal with them.

Cons:

  • Getting a substantive answer about anything is pretty much next to impossible.
  • If you try to keep things running and fail, you have a very good chance of being thrown under the bus.
  • Finding her is tough; she could be crazy in meetings or off hiding.
  • You have to continuously hound her in order to get anything done (e.g., my vacation begins tomorrow, can you please approve it now?).
  • There’s some chance that she’ll give you short-sighted or distracted answers (“Just do this and leave me alone.”) for which you’ll pay later, either personally or professionally.

I thought I’d give an example of this last point from my life.  As I’ve mentioned before on this blog, I once went through two water disasters in five days (waterfalls in the server room).  We – that is, my team, my boss, and I – were all operating in a state of extreme burn-out.  During a conversation about the damage, my boss told me to get a second replacement Storage Area Network (SAN), and when I questioned the order (saying that I wasn’t sure that insurance would cover it), he snapped at me and told me to just get it.  Fast forward a few months, and it turns out that the insurance company would pay for the first SAN, but not the second.

So what do you do with a burned-out boss? (Full disclosure: this is how I like my team to deal with me when I’m burned out).

  • Keep things running.  She will adore you for that.
  • Do your best to get answers, but make sure you need the answers before hounding her.  Don’t hound her for an answer that could have waited, and don’t waste her attention.
  • If you have a good relationship with her, encourage her to take some time away.  Maybe it seems like working all weekend will make the next week easier, but chances are that working all weekend will only exacerbate the burn-out and make the next week even worse.  Working without a break massively decreases efficiency, especially for folks who are burned out.

What other behaviors characterize a burned out leader?  What are other coping methods that work?