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

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

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.

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 Complementary Strengths

I’ve read and heard many places that most people hire people like themselves. (I mostly hear this in the context of why white men hire more white men, but I’m not touching that here.) I’ve also seen many studies that prove that diversity leads to stronger decision making and a better bottom line.

Anecdotally, I can tell you that the best team I’ve ever built started when I hired people very unlike me in strengths and habits.

Why? Because I have weaknesses. (I’ll give those of you who know me a moment to get up off the ground, since I’m sure you fell off your chairs at that public admission.) I’m very good at big-picture thinking and people management and team-building, but I’m weak at details and physical organization.

So you can imagine that if I built a team out of people just like me, no one would remember to book conference rooms for our meetings, and eventually our work space would be covered with piles of mixed-up papers. However, when I built a team out of people who were great at details but weak at the big picture and people who were physically organized but weaker at human interactions, mixed in a few people who were great at research, and so on, our strengths compensated for each other’s weaknesses.

Building a team out of people with complementary strengths leads to stronger work, but it can also be hilarious, as you find each other’s weaknesses amusing. Being able to laugh with (and occasionally at) each other also builds a better team.

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.