Adventures in home working

One of the researchers who works for my company produced a great guide on the uses and abuses of cummuication and collaboration technologies a few years ago.  When I first read it I was impressed but at the same time depressed at the neglect that most companies have of their basic (common) business processes.  I have continued to be interested in how companies can extract maximum advantage from simple IT infrastructure technologies by focussing on how to use their tools to best effect. 

The following post therefore caught my eye - seven rules for e-mail - it would be great to see a best practice debate on how the phone, SMS, email, syndication, IM and conferencing technologies should be used.  The seven rules above provides a good but limited start. For those of you who don’t want to wait, here they are:

SEVEN E-MAIL RULES THAT WILL CHANGE THE WORLD

HWe’re all, busy, okay? Life is short. Sometimes we want long rambling rants like mine. But ow much more efficient our lives could be if we all adhered to these simple rules:

 

1. If your entire message can fit on the subject line, put it on the subject line—followed by EOM  (end of message).  Nothing more.  For example: 

 

SUBJ:  Thanks, Sanji!     EOM

 

·        Or append it to the existing subject line:

 

SUBJ:  Dinner Thursday?   ß YES!  THANKS!  CU THERE!   EOM

 2. Make the subject line descriptive.  If you make it: SUBJ: check this out and it turns out to be yet another copy of Bush’s resume (“I was arrested twice for drunk driving . . .”) that we’ve all seen 50 times by now, it is annoying. But if you make it: SUBJ: Bush’s resume, then we can smile faintly and delete it in three-tenths of a second.

 

This is especially true if you’re forwarding a link – let alone sending an attachment.  Tell us what it is, so we know whether it’s worth opening your e-mail, following the link, or downloading the attachment.

 

·        Instead of: SUBJ: Funny!   How about: SUBJ: Jewish haikus

 

·        Instead of SUBJ: do you know this guy?   How about: SUBJ: do you know Danny Shindler?  Or even (if there’s no more to your message than that): SUBJ: do you know Danny Shindler? EOM.

 

·        The obvious reason is to save time, but the other reason is to make searching easy.  Say this grows into a spirited exchange about Danny Shindler, because you do know him.  And that a month later, one of you wants to go back and find that thread.  Isn’t the logical thing to search on “Danny Shindler” rather than trying to remember that the thread was entitled “do you know this guy?”

 3. If your message is to one person, begin the subject line with that person’s first name:

 

SUBJ:  Jane – separation of church and state

 

That way, she instantly knows you are speaking to her, and this is not a blast e-mail to the 300 people on your list.

 

This is especially important if you are forwarding something that the recipient may have seen – the Bush resume – but also have a personal message.  (“Have you seen this?  And by the way, Thursday’s meeting has been moved from 3pm to 2pm.”)  Otherwise, the recipient may see it’s a “forward” she’s already seen and delete it – and miss the meeting. 

4. If you’re sending to a large group, use “blind copies” (unless there’s an awfully good reason to have everyone see the e-addresses of all 215 recipients). 

5. If you’re responding to a group e-mail, hit REPLY rather than REPLY ALL unless you really think the whole group wants to see your reply. (Ah, the boorish irony of those who REPLY ALL with the message, “I do not appreciate your cluttering my inbox – please take me off your list.”)

6. If you’re attaching a letter or a newsclip, also cut and paste it into the body of the e-mail to spare the recipient’s having to open the attachment.

7. Place post scripts before your sign off, for reasons amply elucidated in the only really important column I have ever posted in this space.

As an illustration of such a debate in action, albeit on a slightly different subject, there is no better example than the getting things done forums.

Werner Vogels wites an interesting article about what he looks for in a good report.  The advice is slanted towards academic papers, but its pretty useful for any technical writer.  he also references an excellent article that goes into the subject in greater detail.  Here is an extract with the main points:

• User or system requirements. Most of the papers I read are about networking, operating systems, distributed systems, but being active is such a deep technical field does not exempt you from thinking about WHY you are doing this. Who or what is going to use your system? Can you write down the requirements and constraints such that it is clear to the reader why this drives your research? Do you have trace or input data that matches your requirements? Even if you did not start out with requirements (sometimes you just have a cool idea), when you write about it you must define what the criteria for success for your project are and why.
• Alternative design decisions. It cannot have been the case that there is only one path to your goal. You must have seen other roads along the way, but you decided not to follow those. Why not? It is important to motivate the choices you have made, if you want your reader to learn from your process, not just from your final success.
• Context. You are not the only person doing research and you are not the only one producing these wonderful unique solutions. You have to spend more than 2 paragraphs on placing your work in context. It is OK to say that others have done the same before, but that you are approaching it from a different angle, or with different data. For example a good engineering paper might not have fundamentally new results, but can focus on how to bring results into practice, which might be just as hard a problem or even harder. Do not discard other people’s work with just a single sentence but give them the respect you would like your work to get.
• Implementation details. If you add this to your paper, make sure you really provide details. Not just a schema of how your components fit together, but also information about why you got to this software design. It cannot have been the case that you got it right with one try. What were the other attempts that you discarded and why?
• Experiments I can talk days about how to perform good experiments in support of your research. But I consider experiments in support of a paper to be something else; here the goal of the experiments becomes communication, not just data mining. With the selection and description of the experiments you have to keep your audience in mind. What were your requirements and how can you show that your solution meets those requirements, by presenting your experimental results. Often your experiments you ran during your research are not the same as the ones you use for your paper. There is not enough room in papers for exhaustive experiment descriptions, so design tests to get the message across.
• Boundaries. It cannot be that your solution is perfect for all cases. Show us what is the window of your success, but also show what are the boundaries. This is often just as important as the describing the successful application.
• Lessons. What lessons did you learn from your work? Positive as well as negative. Your audience will often learn more from your negative experiences than from your glorious positive ones.

I just read a very nicely crafted article describing 10 tips for writing the Living Web.  Essentially its about writing blogs.  As I progressed I wondered increasingly who could have put together such an article and what motivated them to put in the effort.  When I got to then end I found it was Mark Bernstein who is chief scientist at Eastgate Systems, publishers of Tinderbox, a personal content management assistant.  I went straight there to have a look, (so its good advertising Mark!), but unfortunarely its for the Mac only, but they are working on a Windows version.