The perils of BCC

When you’ve got to deal with as much information as everybody in a large company does, most people write Inbox rules to redirect DLs to their own sub-folders. They then group the folder “By Conversation,” which lets them quickly read the threads of interest. But most importantly, it lets them ignore the ones that do not.

 

If you don’t yet use these techniques to help you manage your own mail, you will love yourself for starting. I may follow up with a post in the future about that, but it’s a staple in email management in any large company.

 

When you BCC a distribution / discussion list, that mail break the inbox rules of everybody subscribed to the DL. That includes your boss, the person managing the sr. exec’s mailbox, and the person just about to jump off a cliff from email overload.

 

So aside from being rude (people set these rules up for a reason,) it doesn’t actually solve the problem you might think it does. Although it is nearly always done with the intent to minimize "noise," noise in a person's mailbox is much worse than noise on a distribution list.  Inbox rules are the single most effective means that we have to manage the massive stream of information that flows through the company.

 

 

BCC to "take Offline":

Please do not use BCC to take a thread offline.  Instead, a reply-all with "taking this offline" will suffice. The alias knows that the thread is being addressed, and further conversation is unlikely to follow. In a follow-up mail to the person, you might provide the information you planned to originally. For those that batch their reading of the alias, they probably don’t even care about this specific thread, and will skim right past it.

 

If the conversation continues (i.e.: despite the intention to take offline,) then it was clearly of interest to the DL. No amount of BCCing will prevent the conversation from ending on its own schedule.

 

When you've resolved the issue, people often appreciate it when you follow up with the main thread with the details of the resolution.

 

BCC to "Redirect to another Alias":

Please do not use BCC to redirect a thread.  Instead, a reply-all with "please take this up on the <more-appropriate-alias> alias." The alias knows that the thread is being addressed, and further conversation is unlikely to follow. For those that batch their reading of the alias, they probably don’t even care about this specific thread, and will skim right past it. Aaron Lerch recently wrote a cool macro to unfortunately automate exactly this scenario.

 

BCC to prevent "Reply All":

Please do not use BCC to prevent Reply-Alls.  There are very few situations when limiting “Reply All” makes sense on a distribution / discussion list. If a conversation starts or continues (i.e.: despite the intention to prevent Reply-All,) then it was clearly of interest to the DL. No amount of BCCing will prevent the conversation from ending on its own schedule.

 

A DL isn’t there to be people’s internal version of the LazyWeb — so I disagree with attempting to prevent Reply All. A thread will continue until it runs out of steam – in which case no amount of prevention will stop it. If it was a boring question in the first place, you don’t have to worry about a reply-all storm anyways.  DLs that are highly populated involuntarily (i.e.: organizational aliases) should have the send-to permissions restricted. But since techniques exist for managing mail to DLs, a Reply-All storm really doesn’t matter.

 

Case in point: An internal alias recently suffered a meltdown. With rules in place, my only comment was “weird, why do I have 3000 mails in that folder all of a sudden?”

 

In the very unlikely chance that you have a good reason to prevent a Reply-All, Scott Hanselman’s suggestion (or an Outlook NoReplyAll form) is probably the best bet.

 

 

BCC for unknown reasons:

Please do not use BCC unless you have a good reason to.  Instead, send a message saying, "Please reply directly to me," if that was your intent.

 

3 Responses to “The perils of BCC”

  1. Aaron Lerch writes:

    Oh, and, I forgot to mention that at my company, most times that I use the technique I described on my blog, it’s regarding a very small "subset" DL that usually includes the 10-20 people on my team sitting around me, who it doesn’t bother (or at least nobody has complained yet! one person commended the idea 🙂 ). Also, we tend to use our smaller DLs very frequently, even for intra-team communication, and I doubt many of us have those DLs going to subfolders, or at least don’t keep up with the emails frequently.
    Anyway, just some context. I’m going to add a disclaimer on my post. 🙂

  2. Aaron Lerch writes:

    Apparently my first comment didn’t make it – for some reason I saved the text (I’m weird like that)

    Very interesting – I personally don’t make heavy use of outlook rules for the various DLs that I’m on (I do use some) so some of this didn’t even occur to me. I have nearly all my email come into my inbox and just view conversations as they stand – regardless of how I was addressed (I do use coloring to give me a visual cue).
    (Some might call me crazy, though)

    Am I understanding you right in saying that the main argument against BCC’ing is that the final email of a "conversation" (as outlook defines it) will not make it into the desired subfolder? If that’s the case, is that really a horrible thing? I suppose for DLs with heavy traffic you could get a lot of "noise" in your inbox, and if you’re just reading emails in subfolders you might miss the so-called termination of the thread.
    I’ve been burned too many times, though, by email threads that have snowballed out of control – DL after DL gets added, even if I don’t do the adding, people frequently don’t have the etiquette to redirect the thread themselves, they just tack on the DL I mentioned. (Hence the desire to risk breaking outlook rules if it gets the thread in the right place.)
    So I can see your points, but it still seems like in some cases, and depending on the email-usage-culture of the company, a well-placed BCC can be a positive thing. Or maybe it’s just worth upsetting some people… 😉

  3. PleaseNoBCC writes:

    If that’s the case, is that really a horrible thing?

    Yes, yes it is. "Dealing with" each BCC email takes about 5 seconds. Multiply that by the number of people on the list (and then by the number of times BCC email is sent to that list), and those seconds add up fast. As do the interruptions; it takes 15-20 minutes for the average developer to get back into the same state of mind they were in after an interruption (and interruptions occur every 3 minutes these days, on average, so it’s a recipe for failure — but that’s a different topic).

    Every time I get a BCC email in my Inbox, I send a few links describing how to achieve the desired effect without breaking everyone’s Inbox rules and causing extra expenses for our employer. I’ve added this page to that set of links. Thanks very much for the well-written post.

Leave a Reply