Category: care and feeding

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.

On Morale

·

Happy people are more fun to work with. Many people have no idea how to make geeks happy, however. I have a few “rules” that I follow that have historically kept my geeks upbeat:

  1. NEVER treat them like idiots. They’re often the smartest people in the room and might have a clearer picture of your management challenges than you do.
  2. Let them be creative. Never demand that they do a project according to strict rules, because doing so likely produces weaker product. (Note: strict REQUIREMENTS or specs are necessary, but those aren’t “how-to” rules.)
  3. Encourage laughter. If your company will tolerate it, encourage practical joking. My staff once toilet-papered my office when I made mention that they might do it in a column I once wrote.
  4. Institute non-mandatory “monotony breaks.” I often sent my staff fun (and work-appropriate) online quizzes, “questions of the day,” or Dilbert cartoons in order to allow them to blow off steam. Anyone very busy could ignore them, but they appreciated the change in routing and the chance to blow off steam.
  5. Let them bond. Take them out to lunch in appropriate groups. Encourage post-work gatherings. Let them chat at work. As I mentioned in my post, On Geek Socialization, this bonding will help them relate and keep their tempers during emergencies.

Overall, I treat geeks as I want to be treated. Helping them build morale leads to happier geeks, a stronger team, and better work product.

On Delegation

·

Okay; so you’ve worked really hard, you’re fantastic at your job, and your reward is to finally get promoted over other geeks. What’s the hardest part of your job now? For a lot of geek leaders, it’s delegation. It always struck me as funny. Many geek leaders became leaders because they were very good at doing things, and the reward? You get to make others do them now.

These two skill sets are quite separate–especially if you’ve been a relatively solitary geek. And the hardest part of delegation? Letting go. Letting someone else do something that you’re probably better at doing than they are. Letting someone else do something in a different way than you would do it yourself. Letting someone even make a mistake! For which you will be held accountable! It can be frightening.

If you fail to let go, however, your team (department, whatever you want to call it) will only be as good as you are. You will also become a micromanager, and I can’t think of a single person who appreciates a micromanager. (Granted, some geeks require closer management than others, but that’s outside the scope of this entry.)

If you succeed in letting go, your team has the chance to become much stronger. Why? Well, I could cite the countless studies that say so, but doesn’t it just make sense that multiple brains will think of better possibilities? Will catch each other’s mistakes? Will compensate for each other’s weaknesses? The best thing about letting go is that you don’t have to think of everything yourself, allowing you to become a force-multiplier for your team. You will manage their tasks and projects from a high level, and you’ll be a resource for them if they get stuck or would like some brainstorming help. Your entire team will benefit from your skill and experience.

Letting go also pushes some geeks out of the comfortable nest. Conceivably, you’re giving them enough rope to hang themselves, but most geeks will fly rather than hang (mixed metaphor, but you know what I mean). Watching your geeks stretch themselves in order to achieve the goals that you’ve set and (mostly) succeed is one of the most rewarding aspects of being a geek leader.

So let go. It won’t hurt. Much.

On Perceived Pain

·

On Wednesday, after being tortured by Attila the Dental Hygienist (who apparently uses “scared straight” tactics to get her patients to floss more), I got to experience stage I of my first crown. I am a huge chicken when it comes to mouth pain, so I approached this whole thing with the attitude of, well, a huge chicken. My teeth aren’t easily numbed, and I’ve had live nerves hit several times, so I had a valid fear of pain during the process.

During the drilling (yes, I will eventually get to how this pertains to leading geeks–have patience), I felt PAIN! So I lifted my left hand and made them stop. I panicked, thinking that THE NOVOCAINE DIDN’T WORK and I would be IN PAIN for the rest of the procedure. I asked them to wait until I could stop hyperventilating, since I didn’t want to inhale bits of filling and tooth. And, after I thought about it for a bit, I realized that the pain wasn’t in the tooth–it was in my jaw. Apparently, my jaw muscles were protesting the vigorous cleaning and the new procedure, so each time the dentist pressed down, I’d get a shooting pain through the joint. Once I realized that it wasn’t a live tooth nerve I was feeling, I could deal with the pain and continue with the procedure.

The reason I panicked was that I felt pain and I perceived that it came from the tooth itself, because that was where it had come from historically.

While I was leading geeks, I discovered a similar phenomenon: geeks would get annoyed by something, and assume the annoyance came from where it had come historically. Geeks would also assume that people who had been wrong in the past (consistently) were wrong in the future.

For example, if something came down from “on high” that the geeks disliked (e.g., we had to wait until 9:00 PM to reboot servers rather than doing it at 6:00 PM), they would assume it came from their least favorite “on high” folks, rather than someone they might like. Sometimes, this could be comical, like when one geek insisted that a ball that I had dropped was dropped by the HR Manager–even after I insisted that I was the one who dropped it!

My geeks would also assume that users who habitually “cried wolf” would never call with a valid problem. Sometimes, it took a bit of work on my part to make them realize that the user really had a problem with which we needed to deal.

As a leader, you must be aware of the perceived pain phenomenon–even in yourself–so that you can recognize it and deal with it. As with many things, the only way to deal with it is to see it and communicate about it.

On Hubris

·

Today, I checked myself out of CVS using one of those self-checkout kiosks. I always feel like I’m getting out of the store much faster if I do it myself. As I awaited my bus, I realized that my believing that I was faster at checking out purchases than someone who does it every single day displayed remarkable hubris on my part. After all, every good operations class points out that as people do a task repetitively, they get better and faster at it.

Where does this come from, and what does it have to do with geeks?

Well, I think that geeks and I have this in common: we were much better at certain things than people around us. These certain things likely were related to logical thinking or problem solving, which then translated to the technical world. As such, we all believe that we are naturally just better at things than everyone else.

Although this should not translate to tasks we do not do regularly, it does in our minds. This is why I call this hubris, rather than simple ability or self-confidence (where hubris is defined as excessive self-confidence or arrogance). We/they are not trying to make others feel stupid, we just have an innate assumption that if our brains can grasp the logic behind something, we can do it better.

While leading geeks, it is good to keep this in mind. It means that sometimes they need to be told–gently–that while they might be the smartest people in the room, others occasionally know how to do things.

On Geek Socialization

·

One thing that surprised me about geeks was how much they actually do like to socialize.

Yes, socialize.

Maybe they’re not out at martini bars with the beautiful people, but very few of them dislike social interaction altogether. My geeks really enjoyed chatting with each other in-person (although I understand that they did even more chatting electronically), much to my surprise. Also to my surprise was that the chatter didn’t often get out of hand, especially with the amount of time they spent chatting.

By letting this chatter go (i.e., not asking them to stop), I allowed them to bond as a team and hash out problems together. I know that non-geeks can sometimes go overboard with the amount of time they spend chatting, but most geeks–especially introverted ones–should be encouraged to chat with each other.

Why? Because when stressful times and crises occur, it is exactly those interpersonal bonds formed via socialization that will allow the geeks to work well together. If they already know and like or trust each other, they will be more likely to forgive a snippy comment or approach each other when they need help. And as a geek leader, I value that teamwork.

On Decisions

·

Making decisions with geeks around can be frustrating sometimes. You ask for their input, make a decision, and then (moments later), they start offering alternatives to the decision.

Hello? Did they not hear what I just said?

Well, they did hear it. But it didn’t stop their minds from working on it. And that’s what you’re experiencing when they start offering alternatives to the decision that you thought you already made.

You might find it frustrating, but, if you cannot go back on the decision, I would suggest trying to simply tell them that you’re done with the decision and can move on. Surprisingly, they usually won’t find that offensive. (That was the part I had to learn.)

You should also consider listening to them, assuming that you can change the decision. Sometimes those post-decision ideas are much better than anything that led to the decision.

On Teamwork

·

Many geeks have the propensity to be individualistic animals.

The geek is nocturnal and is a solitary creature that feeds almost exclusively on Doritos and Coke; the only fruit eaten by geeks is that fermented into beer. A geek emerges from its burrow in the late afternoon or shortly after sunset, and operates over a limited home range, peering at a computer screen. When a concentration of Slashdot articles is detected, the geek digs into it with its powerful skills, keeping its shoulders hunched in order to escape management notice. When successful, the incorrect people’s or troll’s stinging attacks are rendered futile by the amazing power of the geek’s brain. Its keen hearing warns it of predators: managers, directors, and idiotic users.

(Description flagrantly poached from Wikipedia’s Aardvark entry. It’s surprising how little I had to change.)

Despite the geek’s solitary tendencies, she may be required to work on projects that involve (gasp) other people. If the geek is fortunate, she will have to work in a team with other geeks, who are more likely to have the same tendencies. In this circumstance, geeks are usually capable of finding their own common ground, and your skills as a leader will be called upon in the case of conflicting ideas and solutions.

If the geek is unfortunate, she will have to work in a team with non-geeks or semi-geeks, who have vastly differing habits. For example, she may be required to attend a meeting in the morning, or communicate via telephone or face-to-face. In this case, as a leader, you will be required to prod your geek a bit more in order to make her engage in this working environment.

Whenever a geek with solitary tendencies is forced into any team environment, watch her carefully. Make sure she has your support, and do not assume she understands group behaviors that you believe to be normal. Many geeks will rise to the challenge and surprise you. Some might take mentoring in order to learn how to adapt to this environment. There are very few who cannot eventually adapt, at least for short periods of time.

On Trading

·

Once I traded a bottle of vodka to a geek for a vacation day.

We were in the midst of our second water disaster in five days, and I knew we would need to support sneakernet (where documents were dumped to USB drives and run to local printers) the next day, so I needed all hands. He wasn’t leaving town, and I was perfectly within my rights to simply revoke the day, but I didn’t–I said, “Can I trade you a bottle of vodka for your vacation day tomorrow?” Two weeks after he gave up that day, I showed up with a bottle of Grey Goose, and handed it to him.

Did my company reimburse me for the vodka? No. Did the vodka’s cost in any way resemble the cost to him for the day? No. Neither of those was the point.

The point was to recognize that I was asking him to sacrifice his personal benefit for the good of the company. I knew that he would lose the vacation day, since it was December and he couldn’t carry any over. He knew that I definitely needed his help. The vodka was a tangible recognition that he was doing something explicitly to his cost and for my benefit.

Overall, it was likely more of a “thank you” gift than an overt trade, but it is the most explicit example I have of a small way to make a geek feel appreciated when he goes above and beyond.

On Prioritization

·

One thing that I had to learn about leading geeks was how differently each geek treats self-management. Some geeks preferred that I list out every possible task I wanted them to do and then chat about general priorities, leaving them to prioritize specifically for themselves. Other geeks wanted just a few projects at a time with specific priorities, allowing them to methodically match my requirements.

My difficulty with the latter type of geek was that I have a personal weakness when it comes to specific prioritization: I’m not specific within my own mind. I build clouds of projects of varying priorities and then try to utilize my staff to have all the projects in the top cloud covered immediately, and go from there. If I’m asked about the priority of project 1 vs. project 2, I find it easy to answer, but I find it more difficult to prioritize the gigantic list of projects and requests that an IT department encounters daily.

So what did I do? I learned. I realized that it was horribly inefficient for me to cling to my abstract thinking at the expense of assisting my team to perform at their best. If someone needed explicit priorities, I would either figure them out before assigning tasks, or (more often) actually sit down with the geek and determine precise priorities together. The latter approach had the advantage of bringing another brain into the prioritization process, and that different perspective led to better overall priority decisions.

It’s not all about manipulating the geeks; often, it’s about changing oneself.