Month: May 2008

The Grammar Geek: Death Throws

·

Recently, I’ve seen a lot of posts that start, “We’ve been in the throws of an upgrade to Exchange 2007…” or something like that. They keep using that word. I don’t think it means what they think it means.

What they really mean to say is, “We’ve been in the throes…”

Yes, throes.

According to the Merriam-Webster Online dictionary, here’s the deal:

  • Throws means a lot of things. From pitching a ball to intentionally losing a game to hitting someone. While upgrading to Exchange 2007 might feel a lot like being on the receiving end of all of these, this isn’t quite the word to use.
  • Throes only has two definitions: either a pang or spasm, or a hard or painful struggle. Sound a bit more like being in the midst of an upgrade?

Glad you all understand now. Please stop making me twitch.

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.

The Grammar Geek: Cousin It

·

My husband asked me to write about dangling prepositions, but I read some posts today on various groups and sites that had its/it’s confusion, so I’m going to get on my soapbox about that instead.

The word, “it”, can be problematic when made possessive. See, it doesn’t have an apostrophe in its possessive form (see? Just like that.). It’s just one of those things you have to memorize.

Wait, what was that? Oh, I just used “it’s” to mean “it is”. “It’s” can also mean “it has”. It’s a contraction (read: It is a contraction.).

To make things more difficult, my last job was in an Information Technology department, abbreviated “IT”. Unlike the pronoun, “it”, “IT” follows normal proper noun rules. If a telephone belongs to the IT Department, it is “IT’s telephone”. If IT is going out drinking the email subject reads, “IT’s going drinking!”

To recap:

  • its telephone = the telephone belonging to it
  • it’s a telephone = it is a telephone
  • IT’s telephone = the telephone belonging to Information Technology
  • IT’s a telephone = the Information Technology department is at the bar, letting voice mail pick up all the calls.

Okay, so technically, IT should be abbreviated “I.T.” to eliminate confusion, but that’s WAY more annoying to type…

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…