small medium large xlarge

Effective Emails

Think Before You Send

by Josh Carter

Generic image illustrating the article
  That email you just sent says a lot about your professionalism. Here’s how to be sure your emails what you want.  

We’re called upon to communicate many things to many people via email. Doing this clearly and efficiently is an essential skill to master.

As you pop open a new mail window, the first questions to ask yourself before typing anything should be:

  • Who am I writing this to?

  • What do they need to know?

Answer these up front and you’ll immediately save everyone, including yourself, a lot of time. Your audience determines the length of your message, the topics that are relevant, the amount of detail that’s appropriate, and the humor you can get away with.


Let’s consider a few audiences and their implications for your email:

  • Upper Management: These people are busy, they get hundreds of emails a day, and they often read email on a cell phone while traveling. More than anything else, you must be concise to reach this crowd. If an upper-level manager can’t understand your point within the first couple of lines of text, they’ll simply delete your email and move on.

  • Your Manager: While she might also be busy and reading email on her phone, you need to give your manager enough details to make informed decisions. The appropriate level of technical detail depends on your manager’s background; many are ex-programmers and still want to hear it.

  • Other programmers: You’re on your home turf, so go technical! If your message could be broadly useful, for example explaining gnarly details of some software component, consider documenting that in an appropriate place—docs in source control, intranet wiki—and email a link instead.

  • People outside the company: Use your judgement, but with a couple of obvious limitations: don’t mention or imply anything that could be considered a trade secret, and keep a positive, professional demeanor. You may not work in Marketing, but that doesn’t matter: you are a representative of your company, and you need to act like it.

Of course, some email isn’t so simple: managers, programmers, janitors, etc. may all be on the distribution list. What then? My rule of thumb is, write for the most important audience. That’s not always the person with the highest title. Instead, it’s the audience that stands to benefit most from the email. For example, if the topic is gnarly software details, but the company CEO is on cc:, still write for the programmers.

One caveat: if upper managers are on your email’s distribution, do them a favor and include a brief summary at the top. This could be called out as an “executive overview,” or you can be more subtle. Open with, for example, “The component will work once Bug 2112 is fixed. Let me add some background information on the design of that component...” That gives the managers their key information up front.


You can address an email using to:, cc:, and bcc:. Your choice sends its own implicit message to the readers.

People on the to: line are the most important audience; you’re saying “this message is to you.” Your message should be directly relevant to everyone on this line.

When you put someone on cc:, you’re stating “this message isn’t to you, but you should be aware of it.” When replying to a message, it’s common practice to reply to all, but bump some people to the cc: line. Those are the people that should still be in the loop, but only as a secondary concern.

One warning: sometimes a person will get huffy when replying to an email, and they’ll add a bunch of managers on the cc: line. Or they’ll email you and cc: your manager. This is a jerk move. Dragging managers into a email thread that’s going downhill doesn’t fix problems—it makes them much, much worse.

Finally, when you bcc: someone, you’re saying, “this message isn’t to you, but I’m slipping you a copy and nobody knows it.” Quite simply, don’t ever use bcc:. If the person on bcc: hits “reply all,” you’re hosed. Just send your message with no bcc:, then forward a copy to that recipient. That’s much safer.

For an already-running email thread, be careful when adding or removing people from the distribution. When adding, include a line near the top such as:

 [adding Bob to cc:, this thread is relevant to his team.]

Removing is tricky, as some people may take offense. The most tactful approach is to send a brief reply-all indicating that you’ll start a new thread, and your reason for doing so. Then send a second email to the trimmed-down list.

Content and Structure

An email’s content contains between one and three major chunks: the subject line, the first couple of lines of the message body, and then the rest of the body. Technically, of course, the message body is just one thing. In practice, however, the first couple of lines need special attention.

Subject Line

You must get your subject line right if you want people to read your message. Vague subject lines get an instant delete from busy readers. A concise subject line, on the other hand, is a blessing.

Let’s look at a few examples:

 Subject: Replicator software v2.34 rolling out Friday

My take: good. Selects its readers (people who care about the software release) clearly, and communicates the most pressing detail (rollout date) before the reader even opens the message.

 Subject: Project delayed!

My take: bad. Fails to indicate who should read it, the nature of the delay, and whether or not the situation is under control. Combined with exclamatory tone, this subject line will wind up a bunch of people—maybe not the right people—and your manager will spend the next week doing damage control.

 Subject: Need your approval: new switch for test lab

My take: good. Use of “your” implies one recipient, presumably the person that approves lab equipment. Clearly implies that the recipient needs to take action, the nature of the action, and what it relates to.

 Subject: Josh, you have notifications pending

My take: bad. If a notification is important, it should be summarized in the subject line. Instead, this email just sounds like a social networking website desperately wanting to show me ads.

First Couple of Lines

This is “the lead,” your opportunity to capture the audience’s interest. Like the subject line, it needs to capture the essence of your message. Any essential or time-sensitive content needs to be here, or at least mentioned so that readers know to look for it. Any summary information for busy managers needs to be here. For an email with many recipients, your lead should narrow the audience.

Have you ever sent a long email that included a question for the recipient, then not received a response? You can guess what happened: your reader saw the length of the email, scanned the first few lines, then moved on. Maybe he had the intention of coming back to it later... just like the other 2,000 old emails in his inbox.

Many times, when you cut the fluff and commentary from your email, you’re left with just a subject line and one paragraph. That’s great—most corporate emails don’t need to be any longer!

Everything Else

At this point in your message, you’re free to go into details. If you’ve done your job well, most readers will already have the detail they needed, and they’ve moved on. The readers wanting the whole story are the only ones still reading. You don’t have license to ramble, of course, but you don’t need to edit with the same scrutiny as in the beginning.

Damage Control

Earlier we discussed choosing the audience for your email. Let’s add a caveat: you only choose the initial audience for your email. Once you hit “send,” your message can go anywhere from there.

The havoc wrecked by forwarded emails can know no end. Before sending anything, ask yourself:

  • Who could this email be forwarded to?

  • What damage would it do if it fell into the wrong hands?

If your email criticizes a person, assume it will be forwarded to them. If you insult a piece of code, assume it will be forwarded to the programmer. If you say the company’s products suck, assume it will be forwarded to the CEO.

Therefore, treat all email as etched in stone and notarized. There’s no delete button, and measures like Outlook’s “recall email” only bring more attention to your mistake. (Note, however, that IT administrators can delete messages from folders on the Exchange server—I’ve seen it happen.)

No-No Email Topics

Given the nature of email, stick to in-person conversations for these topics:

  • Criticisms of fellow employees. Exception: your manager may ask for a written criticism for that employee’s performance review. In that case, keep it as fact-oriented as possible, and review it in-person with your manager before sending.

  • Negative personal opinions of company projects and products. Bad-mouthing is generally in bad taste anyway.

  • Discussions related to patents, especially possible violations of patents. These emails may be subpoenaed by a court.

  • Any matters of questionable legality. (And in this situation, maybe your conversation should be with your lawyer.)

When in doubt, save your email as a draft. The next morning, read it again, and then decide if it’s appropriate to send.

These rules apply to other electronic formats as well. Your company may be logging instant messages, Twitter, and other communication as it passes through their firewall. Don’t count on privacy while using any corporate network.

Style and Cultural Matters

Many times you need to send email to people you don’t personally know, and they could be anywhere in the world. If you work for a large, multi-national company, even your peers could be scattered across the globe.

In these situations, take a few steps to ensure your message hits its mark:

  • Beware of American and sports idioms like, “ensure [x] hits its mark.”

  • Humor is easy to misread, and don’t rely on emoticons (smileys) to fix it. As a rule, don’t use emoticons in professional email.

  • Some languages have both formal and informal means of addressing a person. Respect their standards, and whenever in doubt, go with formal.

  • Don’t use ALL CAPS, ever. (But you knew that one already.)

Sure, you might come across sounding stiff. That’s better than sounding disrespectful.

Case Study: Weekly Status Report

Let’s consider a few examples, starting with the humdrum weekly status report.

 To: (Your manager)
 Cc: (Other managers, as needed)
 Subject line: 2012-04-27 Status report, Josh Carter, Project Foo
  [possible delay]

So far nothing special. The subject line includes the date and name, which seems redundant, but I include it because status reports are commonly forwarded. I also added “[possible delay]” as a heads-up. Now for the body:

 Foo project delayed because prototype board won’t boot. I
 suspected solar radiation, so I started designing a test to
 determine the correlation between sun spots and the
 non-workingness of our prototype board. First, I built a
 Faraday cage out of scrap metal from [...]

Whoa, now we’re off track! (In more ways than one.) This level of detail isn’t useful to managers. Let’s try that again:

 Prototype board did not boot, and standard debugging practices
 didn’t resolve the problem. Ordered replacement from vendor;
 arrives Tuesday.

That’s all that needs to be said. If someone wants the full story, let them ask for it. Often, we really want to tell the story so that managers appreciate the amount of work we put in, but your status report isn’t story time. A competent manager will already know the story from day-to-day interactions with the team.

One more item for the status report:

 Bugs 2112, 2113, 2114 resolved. All related to common problem, see
 documentation in wiki [1] and resolution of bug 2112.
 [1] http://wiki/engineering/projects/foo/hardware_bugs

This one’s good. Feel free to document useful things you discovered—but do it in the right place. Engineering wikis are good for this, and a link in your status report lets curious readers get the full story.

Case Study: Feasibility Report

Many times we’re asked to investigate some technology and see if it would work with the company’s product. Someone says, “Hey, should we use Ruby on Rails for our web app instead of J2EE?” And then it lands on you to see if that’s feasible and send a summary report to management.

This is a tough one, because while the work itself might be fun, your report needs to distill inherently technical topics into something managers can use to make a decision. Let’s start with the first draft, sent to your manager for initial review:

 To: (Your manager)
 Cc: (Other team members who helped)
 Subject: Draft 1 of Rails feasibility study

Easy enough. Now for the body:

 This document summarizes our study of using Ruby on Rails for
 Project Foo’s web front end. Initial study looks promising, with
 a possible downside of higher latency on certain pages, but still
 within acceptable limits. We recommend moving forward with Rails.

Strong lead! Non-technical readers can stop right there, they’ve got the bit they needed to know. The engineering managers, however, will keep reading.

 Routing is configured using the file config/routes.rb, and you
 create routes by matching lines like match foo/:id => foo#view,
 or you can create REST-style resources with lines like [...]

Stop, stop! Too much detail, this isn’t a book on Rails. Let’s try again:

 Routing is configurable, and while there is a bias toward
 REST-style paths, custom paths are also supported.

That’s all that needs to be said. If someone wants to know how to create a route, they can buy a book on Rails.


While this may seem like a lot of rules about writing email, it all boils down to this: be clear about the audience you’re writing to, and give them the level of information they need. You’ll find your emails getting to the point much faster, and generally getting shorter overall.

You’ll also find, unfortunately, that writing short, concise emails is not faster than writing long ones. Quoting Pascal, “I would not have made this so long except that I do not have the leisure to make it shorter.” It takes effort to put yourself into the mindset of your audience and cut out all the cruft that’s not relevant to them.

But we’re not ones to take the easy way out, are we? Put in the work to write effective email, and your career will benefit accordingly.

Josh Carter is the author of the New Programmer’s Survival Manual. He’s a professional programmer with more than 15 years of experience, both in programming and engineering management. Josh has a passion for programming and keeping on the leading edge of technology, but it’s balanced by the Steve Jobs mantra, “Real artists ship.” These days he’s equally passionate about helping the next generation of programmers make their own mark in industry.

For more pragmatic career advice, be sure to check out the New Programmer’s Survival Manual, now in print. The Survival Manual includes much more discussion of corporate organization, understanding personalities, and working with a team. Acknowledgements: Thanks to Jim Reekes and David Trachy for their contributions to this article.

Josh is on the web at and Twitter as @joshcarter. Send him your feedback or discuss the article in the magazine forum.