Author: Jenn Steele

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.

The Grammar Geek: Oxford Commas

·

From what I’ve seen, most folks, while writing lists in sentences, write them as “x, y and z”. I, however, write them as “x, y, and z”. The difference is that last comma before the “and” in those lists. (Yes, I know that I committed my favorite error in those examples above.)

That last comma is usually called an Oxford comma or serial comma. Wikipedia says it can also be called a Harvard comma, but, as an MIT alum, I think Harvard is quite obnoxious enough already without a comma named after the place.

Overall, I’m a big fan of writing (a) as I speak, and (b) as clearly as possible. When I am verbally using a list, I pause for the same amount of time between saying “x”, “y”, and “and z”. So my brain says that I should use the Oxford comma when I write the list. I also find that, in most cases, using the Oxford comma makes a list easier to read–it reads clearly as a list to my eyes.

The Wikipedia entry has all sorts of fun ambiguity examples that I’ll refrain from duplicating here. I have to say that, despite my love of this comma, I no longer correct it when I proofread documents from authors who don’t use it. I barely twitch, even. Does this mean I’m gaining maturity?

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…?

The Grammar Geek: Avoiding Confusion

·

This post isn’t about grammar per se, but about a good way to find your own grammatical errors in your business writing:

After you’ve written something, read it out loud.

Why? Well, maybe you were interrupted mid-sentence and wrote the end of it hours later. I’ve done that and ended up with all sorts of messes, like doubled or missing words or subject-verb agreement issues. If I read what I wrote out loud and I am careful to read it word-for-word, I will hear the error and be more likely to correct it. After all, most of us know what proper business English sounds like, even if we don’t know the rules behind it.

This technique works best if you can walk away from your work for several hours (or overnight), because you are less likely to read what you thought you wrote and more likely to read the actual words on the page. When I wrote computer training manuals (a very long time ago), I discovered that I often mentally supplied missing words as I proofread my work. Unfortunately, many of my errors made it to press, where I’d find them a week or two later. Quite embarrassing!

Along with reading your work aloud, consider having your own proofreader–preferably someone who doesn’t speak or write like you do. This second set of eyes will be much more likely to catch your mistakes, and can save you from embarrassing gaffes.

(On this blog I usually simply read things aloud immediately after writing and then publish–hence any errors you might find!)

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

The Grammar Geek: My Favorite Error

·

By and large, I conform well to American business writing grammatical standards. There is one way, however, in which I simply prefer to be wrong: the placement of commas and periods in relation to non-conversational quotes. If the punctuation is not part of the phrase, I prefer to put it outside the quotation marks instead of (correctly) inside.

As I discovered earlier this week in conversation with some fellow MIT alums, this is a classic geek preference. According to http://catb.org/jargon/html/writing-style.html,

Hackers tend to use quotes as balanced delimiters like parentheses, much to the dismay of American editors. Thus, if “Jim is going” is a phrase, and so are “Bill runs” and “Spock groks”, then hackers generally prefer to write: “Jim is going”, “Bill runs”, and “Spock groks”. This is incorrect according to standard American usage (which would put the continuation commas and the final period inside the string quotes); however, it is counter-intuitive to hackers to mutilate literal strings with characters that don’t belong in them. Given the sorts of examples that can come up in discussions of programming, American-style quoting can even be grossly misleading. When communicating command lines or small pieces of code, extra characters can be a real pain in the neck.

Consider, for example, a sentence in a vi tutorial that looks like this:

Then delete a line from the file by typing “dd”.

Standard usage would make this

Then delete a line from the file by typing “dd.”

but that would be very bad — because the reader would be prone to type the string d-d-dot, and it happens that in vi(1), dot repeats the last command accepted. The net result would be to delete two lines!

This was a revelation for me, because my preference for the error is directly related to exactly these two things. Perhaps it simply seems less precise to me to include punctuation in phrases where it did not originally exist. For whatever reason, unless I am writing for publication, I put my commas and periods outside. Well, I do so until the grammar-check inside my application corrects them…

On Feet

· 1 Comment ·

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…

The Grammar Geek: Plurals and Apostrophes

· 1 Comment ·

I’ve been considering adding a new feature to this blog in addition to my leading geek posts: The Grammar Geek. I’ll post about my pet peeves. If my readers hate this, I’ll make it go away.

Very little in this world drives me as crazy as making plurals with apostrophes (in second place is probably NOT using apostrophes where they’re necessary). Here’s the general rule for apostrophes:

Apostrophes are used when letters are dropped or (rarely) for typographical reasons. There are three cases:

  1. Possessive nouns (this is historical–possessives were once formed by adding -es to the ends of nouns. When the “e” stopped being pronounced, the dropped “e” was replaced by the apostrophe, making the plural -‘s. Offhand, I don’t quite know what’s up with the possessive of plural nouns, but I think it has to do with the French (no, really, see here).)
  2. Contractions
  3. Plurals of lower case letters (“mind your p’s and q’s” (amusingly, blogger spell check wants me to change this to Ps and Qs. Note that there is no apostrophe for upper case letters–this means acronyms! (more amusingly, Firefox spell check wants me to change those to P’s and Q’s–which is wrong!!)))

Please note that, except for the third case (which has exactly twenty-six uses), NEVER MAKE A PLURAL WITH AN APOSTROPHE. Ahem. Making a plural with an apostrophe has become so common that I think I’ve developed a permanent twitch.

I’m going to give an example with the word that I see most often violated: attorney.

  • attorneys = more than one attorney
  • attorney’s = belonging to one attorney
  • attorneys’ = belonging to more than one attorney

Got it? Good. Now you can twitch, too.

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.