Category: care and feeding

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

·

I love the suggestions I’ve gotten thus far–keep them coming! However, inspiration struck in the middle of the night, so you’re getting this one instead.

On Tuesday, I returned to work from the ILTA conference to discover that I had misplaced my staff. Or rather, that they had misplaced themselves. I stuck my head into the Help Desk office, only to discover that it had become a storage room. I turned around and located the office, only to discover that it only had one desk (and the corresponding one human) in it. I walked past the spare office, only to discover that the door was now labeled for the other Help Desk person. As you might imagine, I was relieved to discover that my name was still attached to my office, and my key still worked! (Although there was a huge cardboard box on my desk. Lame compared to my last firm, where they toilet papered my office post-conference, but we’ll work on that…)

I was somewhat shocked. After all, the promotions that would give the respective Help Desk folks their new offices haven’t come through yet. The two people working the Help Desk are now in different offices, and I was unsure that would be as effective as sitting six feet from each other.

However, this was exactly the final configuration that I had specified. And the only configuration I had discussed with everyone. Last week was slower than expected, so they executed what they knew to be the plan.

I had to sit down and figure out why I was shocked that they had executed the plan I had communicated. I realized that, while I had communicated the final plan to them, I had failed to communicate that I had expected it to be phased in differently. And that I had expected them to tell me a little more detail about the moves they were making.

They were executing 100% of what they knew to be the plan, and they were doing it faster than we had thought it could be done–there was nothing wrong with that. What was wrong was that I had failed to communicate how I expected them to execute the plan.

Lesson learned: geeks can’t read my mind. Also? My staff executes plans quite efficiently, when motivated. Next step: better define expectations.

On Communication

·

Let’s face it: geeks can sometimes be poor communicators.

(It’s tempting to end the post there to prove my point…)

I’ve seen geeks forget to inform colleagues and bosses that they’ll be on vacation, geeks neglect to inform companies about scheduled downtime, geeks fail to ask essential questions, and everything in between. So how does one, as a leader of geeks, deal with this?

  1. Know yourself. Many geek leaders were once geeks themselves. Have you inadvertently created a culture of non-communication? Do you tell your geeks if you’re leaving the office to play golf or have lunch? Do you let them know about potential changes and plans?
  2. Know your geeks. Wander into offices and cubes and ask what’s going on. Ask “why?”. And actually listen.
  3. Communicate about communication. Let your geeks know what is and isn’t acceptable to keep quiet about. For example, I make it clear that my geeks can tell me as much or as little as they want about their lives outside of work, but if I ask what they’re working on for their jobs, I require answers.
  4. Leave your door open. Allow your geeks to come by when they feel like doing so. Won’t happen much, but some geeks are more comfortable chatting than emailing. No, really, I’ve seen it. Honest.
  5. Revisit things. Introverted geeks won’t ask all their questions and voice their concerns in an initial face-to-face meeting; they’ll need to mull it over. If you don’t give them space to bring up these thoughts, you may never hear them. And they’re probably good thoughts to hear.
  6. Consider written communication. Email can be useful for this, but I’m planning to set up a wiki for my department to track projects.
  7. Don’t play the blame game. There are definitely unacceptable levels of communication (see examples above), but before ranting and raving at your geek about how he or she was REQUIRED to tell you about the system change, go into inquiry mode. Find out why the geek forgot to do it. Make it clear that it can never happen again, and then, if necessary, examine ways to prevent it. You may need to make a template email that the geek can send out to the company for downtime, or you may simply need to accept an apology.

If you try, you can probably create an environment where your geeks will communicate more. They’ll never become The Great Communicator (thank goodness), but you should definitely see some improvement.

On Inquiry

·

Good geeks ask “why?”.

If you give them a number to hit, they’ll ask “why?”. If you tell them your sales goals, they might ask “why?”. If you ask them to do something, they’ll ask “why?”.

If your geek fails to ask “why?”, you probably don’t have a great geek on your hands. Or she is shy, and you should make her comfortable enough to ask “why?”.

Why?

Well, I’m glad you asked…

Asking “why?” shows curiosity, which is a close cousin of creativity. I find that geeks can get to the fundamental issues of a matter and develop a solution that is often better than the original task proposed (the one that they questioned). If they don’t ask “why?”, your geeks risk getting stuck in the box of your way of doing it.

Yes, it’s possible for them to go overboard, and sometimes you won’t have a good answer to their question, but don’t be worried when geeks ask “why?”, be worried when they don’t.

On Being a New IT Director

·

I started a new job on Monday, and I sent this email to my new geeks:

Here’s the deal with this email: I want to set up individual meetings with you, but I also want to give each of you the opportunity to email me the answers to some of the questions first, so we don’t have to take up too much of your time at the meeting itself. It looks like my calendar is up to date with all two of my appointments, so please schedule a meeting with me for 30 minutes to 2 hours–whatever amount of time you’d like to have to chat, ask and answer questions, etc.

Here are questions (for the first eight or so, it might especially be useful for me to have your emailed response. Otherwise, I’m perfectly fine with just chatting about the rest.):

  1. What are your scheduled hours, and what hours do you actually usually work?
  2. Do you carry some sort of device with which you check your email evenings and weekends?
  3. When is your birthday (month/date)?
  4. What is your favorite cake from Rosie’s? (or let me know if you can’t/don’t eat sugar)
  5. What is your favorite caffeinated beverage?
  6. What is your favorite alcoholic type of beverage? (or let me know if you don’t drink)
  7. What’s the best bribe a boss has ever given you? Nothing illegal, please. Please note that the use of the word “bribe” is used in a joking manner in the first sentence of #7.
  8. Does it bother you to have someone (that would be me) swing by your office periodically during the day to make sure you’re still breathing and that your head hasn’t exploded?
  9. Did you understand my sense of humor in the previous two questions, or am I just overly tired?
  10. What does your typical day look like with regard to your tasks, duties, and stress level?
  11. What are your assigned responsibilities?
  12. What extra responsibilities have you undertaken?
  13. Is there anything that you really should be doing but simply cannot get to due to staffing, time, burnout, etc.?
  14. What are your current projects?
  15. What does your to-do list look like?
  16. What do you want your current job to look like (yes, in a perfect world)?
  17. What do you want to be when you grow up?
  18. What do you see as the next step in your career?
  19. What changes would you like to see in the IT Department in the next year?
  20. What do you definitely NOT want to have changed in the IT Department?
  21. What would you like the IT Department to look like in 5 years?
  22. What kind of boss would you like me to be?

Any questions? I’m happy to answer the first few if you’d like…

Jenn

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 Appearance

·

Stereotypically, geeks just aren’t the prettiest people around. (I like to think of myself as a notable exception, of course.) They’ve usually relied on the brain parts of their heads rather than the face parts to get ahead in the world, and many of them have the preconceived notion that the better the face part looks, the poorer the brain part works. Really, though, you don’t have to be pretty to do a job, and that’s not what this post is about. This post is about how to talk to geeks when their general appearance crosses to the other side of the “acceptability” line.

Many geeks simply aren’t very aware of outward appearances. They grab whatever they find in the closet (or the (hopefully) clean laundry pile) in the morning, and head out the door. That threadbare Baldur’s Gate t-shirt and ancient black faded jeans combination might look a little odd to the CFO when she swings by the cube farm, however. Or maybe you have a geek who wears skirts that would be more appropriate to bar-hopping than to crawling under desks to plug in cables. Sure, the Marketing guy might like it, but it’s not going to help her career.

What do you, as the geek leader, do in these situations? Well, first ascertain that the way the geek looks (or smells) actually is inappropriate for the environment. My husband wears jeans to work every day and would look odd in a pair of slacks, but the same thing wouldn’t fly in a law firm’s IT department. If the way the geek is dressing is actually appropriate, it’s time for you to suck it up and deal with it, even if you personally dislike it.

If the dress is actually inappropriate, it’s time for a closed-door conversation. Dropping hints just won’t cut it–if your geek were observant enough to pick up on subtlety, you wouldn’t be in this situation. Gently tell your geek that he or she should consider eliminating certain pieces from his or her wardrobe, replacing them with slacks/longer skirts/whatever might be appropriate. Don’t give the geek explicit appearance tips (“You’d look much better if you…”), but keep your suggestions consistent with company dress code and standardized company dress “norms”.

This isn’t ever an easy conversation, but it’s essential for both the geek’s career and your team’s general reputation with your company.

On Insomnia

·

Whether it’s due to playing World of Warcraft or the Moose Lodge throwing a party until all hours (don’t laugh–it happens to me), sometimes, just like everyone else, geeks don’t get enough sleep. And, just like everyone else, this often adversely affects their clarity of thinking and judgment.

Unfortunately, as a leader, this often adversely affects the quality of your team’s product or service in turn. How a good leader addresses this issue depends on the circumstances.

When time and situation permit, I’ve been known to send a geek or two home to sleep or get over an illness. I’d always get rather annoyed at anyone who felt the need to come to work sick (unless it was a firm emergency), because the illness would invariably pass to someone else, causing a fun cascade of absences or coughing fits. If the issue is a one-time lack of sleep, I would send the geek home because whatever work he or she would produce would probably have to be re-done the next day, anyhow.

Chronic lack of sleep, however, calls for a different approach. While I was careful to allow my geeks privacy in their personal lives, I always addressed any chronic exhaustion issues. For stress-induced insomnia, I would pressure the geek to take more vacation time or chase him or her out the door after 8 hours of work. I would also examine the geek’s workload to see if I could re-balance tasks or activities in order to ease the stress a bit. For World of Warcraft-type insomnia, a lifestyle-balancing conversation would have to take place. (“I know that this is your hobby, but it is unfortunately affecting your work…”)

For some geeks, however, starting the business day at 8 or 9 in the morning will just be difficult. This is when allowing flex time can help you get the highest quality work out of your geeks. If your company (and project) allows it, allow your geek to shift his or her day by two or three hours–say from starting at 9 to starting at 11, and ending at 7 or 8. If you have team projects to do, establish a 3 or 4 hour block when everyone has to be there (from 11-3 or so) in order to foster teamwork.

Flex time overall leads to happier and more alert geeks who work better and make fewer mistakes. Have I ever told you all about that time when I was working 100-hour weeks and took down the network backbone at noon…?

On Scheduling

·

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:

  1. Compare the project with previous similar projects.
  2. Identify the macroscopic ways in which this project is different from said previous projects.
  3. Take the time for the previous projects and add or subtract time based on estimates for those differences.
  4. Inflate the time to allow for at least one disaster.
  5. Negotiate with the client from there.

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!).

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.