Being an Internet old-timer has some cons. I miss ol' good times when the word netiquette had some significance. Times have changed and [ ... long, sour rant here ;) ... ]. Nowadays people tend to use some Internet tools mindlessly, without caring how it affects other people work / time. E-mail is a great example.
Why a blog post about e-mail in particular? I've seen software dev projects screwed because of faulty architecture, wrong tech assumptions, lack of dev experience - and I think I've already written about all of those reasons. But bad communication can silently & gradually choke whole projects & organizations as well - people still think they are doing something ("hey, I've sent 75 e-mails today!"), but they actual progress is literally non-existent - they are descending into the chasm of information chaos & organizational paralysis.
E-mails are evil
Well, no, they are not. But in the hands of people devoid of imagination ...
Basically, e-mails are:
- asynchronous
- limited in terms of content transferred (no body language, tone of voice or similar emotion indication)
- slow (writing them takes time, being asynchronous doesn't help either)
- chunked (not interruptible, poorly fork into threads, referring to parts is cumbersome)
- provide only basic information structuring
- perceptible by just one sense
- scale poorly (in terms of length, quantity, number of participants, ...)
Asynchrony is a great feature (less distraction) while other ones (from the list above) are just limitations. But people tend to fall into the trap of overusing e-mails as a form of communication, because e-mails are perfect when you don't bother to listen (because you don't like to, don't have time to, don't respect the other party, etc.). It's so convenient to make your statement when:
- no-one can interrupt
- it's easy to ignore / skip part of conversation you don't like ...
- ... or re-use the same arguments after a minor re-phrase to make them appear as new ones ;P
The truth is: e-mails are great when you're about to initiate a discussion or to conclude one (after all has been agreed), but they are terrible for performing actual discussion. Unfortunately, sometimes organization is large enough (or distributed enough) that you have to rely on e-mails more than you'd wish to. To make an e-mail communication efficient, it's good to keep the following rules in mind:
My mail fu is stronger than yours
- Keep content tailored to the recipient
Respect other people time. Don't send them e-mails that are not relevant for them: adjust the level of detail, split e-mails with multiple recipients who have different expectations for information. Otherwise people WILL ignore you and it's YOU to be blamed.
- Grasp the difference between TO vs CC
Make sure that the key target recipients (the ones you expect to respond or execute some action) are in the TO field, while people who just should know about the content of the e-mail are on CC only.
- Responsible responding
When you respond, verify recipients' lists. Some of initial recipients of the e-mail you're responding may be totally uninterested in your response. This is usually true in case of "fan-out general question" type of communication. Does it really matter? Yes, having 2 e-mails (question + your own response) in mailbox is significantly better than having 20 (question + your own response + 18 distractors you don't give a f@$% about).
Btw. there's a great chapter about messages & notifications as distractors in Simon Sinek's "Leaders Eat Last" - recommended read.
- Brevity is the greatest of virtues
Algorithm is simple:
- Write e-mail, but don't send it yet.
- Shorten it by half.
- Shorten it by half.
- Shorten it by half.
- Now you may consider sending it.
Personally, in everyday communication (except for initiating / concluding open discussion) I try to follow this rule. If I HAVE to write a longer text, I usually start with TL;DR synpopsis sub-section in the header, so anyone can immediately find out what's all the fuss about.
- Both Form and Function
Unstructured wall of text is a clear indication of complete lack of respect for recipient(s). If you want them to read it, help 'em do it - use headings, bullets, enumeration, highlighting, bold-out the most significant parts, etc.
Help them understand the structure at the first glance, so they will be able to follow your flow of thinking, argumentation, reasoning. You may have spent 5 minutes more, but you may have saved 5 x 10 = 50 minutes of their total time.
- Help to embrace the scale
Inboxes tend to grow. Fast. Furiously fast. And sometimes the most important e-mail ain't the one you're reading now, but the one someone sent you few weeks ago - now the challenge is to find it. That's why it's so important not only to give proper (meaningful) subjects with some keywords (for easier search), but also to use some kind of convention for e-mail labeling (for instance: [Project X], [Tests], [Claims]), so properly set-up rules can tidy the inbox up.
This gets another twist in long communication streak - sometimes threads get that long that initial subject is not relevant anymore -> it's one of the cases you should keep an eye on: don't hesitate to change the title / categories if necessary or just fork new separate threads for the sake of clarity.
- Don't make them guess
If you want action, ASK for action explicitly.
If you have questions, ASK for response explicitly.
Propose due dates, emphasize the intentions. In case of actions - make sure that recipients are 100% sure who precisely is expected to act. In general - tasks in e-mails are an anti-pattern (unless you have very few of them & there are few parties involved, so high transparency / tracing isn't required). They lead straight to hell AKA "Inbox as a task queue" or "Inbox-driven people".
- Avoid the one-way bottomless pit
Sending a non-FYI e-mail & getting no answer is usually a very bad sign. And setting the due date ("if I do not get a response until tomorrow, I assume that everyone agrees") doesn't really help AT ALL. At least not with making sure everyone is in sync & everyone commits to the idea proposed.
It's vital to check whether all parties are on the same page - especially because the written text gets misinterpreted very easily, so feedback is crucial. Set up some follow-up meetings, make one-on-one phone calls to confirm whether everyone had time & chance to read your stuff, reserve time for Q&A up-front & send the invites (attendance: optional) to anyone interested.
- Use the right tool for the task
If you want to make a poll, use software dedicated to make polls.
If you want to co-develop a document with auditable version history, use version control / or at least shared storage.
If you need to formalize some workflow - there are tools for that as well.
If you want to share huge files, there's definitely better way to do that than e-mail.
Don't treat e-mail as an universal tool for every kind of work you're doing.
- What if all of the above didn't help ...
... and people are still stuck in endless streams of pointless e-mail exchange? Then you're doing it ALL WRONG. These people use the wrong form of communication:
- they should either work together side to side
- or at least have dedicated SPoCs working together
- or that's something absolutely wrong with the ground rules of their cooperation - maybe they don't share the same goals (or worse, have opposite ones) - something to get cleared out in direct face-to-face communication
Pic: © Ogerepus - Fotolia.com
