How to Revise an Email So That People Will Read It(blogs.harvardbusiness.org)
blogs.harvardbusiness.org
How to Revise an Email So That People Will Read It
http://blogs.harvardbusiness.org/silverman/2009/04/how-to-revise-an-email-so-that.html?cm_mmc=npv-_-WEEKLY_HOTLIST-_-APR_2009-_-HOTLIST0417
3 comments
Have you tried eliminating the body of the message, and just sending the bullet-points? If the reader appreciates it because they're not going to read the rest of the message, why give them the rest of the message?
Good point. The terse details are there for two reasons:
* Stakeholders need specifics -- While some managers just need to skim, some peers and deeper stakeholders on the thread require details to validate the points because it impacts them specifically.
* Managers want access to details -- The manager wants to be able to skim, but also have details on a specific item if they choose to dive into it (now or later). It's hard to tell which ones these will be, so providing extra information after the heading allows them to pick and choose without obstructing their quick-skim-ability.
* Stakeholders need specifics -- While some managers just need to skim, some peers and deeper stakeholders on the thread require details to validate the points because it impacts them specifically.
* Managers want access to details -- The manager wants to be able to skim, but also have details on a specific item if they choose to dive into it (now or later). It's hard to tell which ones these will be, so providing extra information after the heading allows them to pick and choose without obstructing their quick-skim-ability.
I don't find it particularly uncool to convey your meaning as effectively as you can, especially when, in a corporate environment, there is so much other data competing for the attention of your reader. Thanks for the tip. I'm going to try to use this myself.
I would recommend Strunk and White's Elements of Style to help. This post was essentially that with a little hastiness for the reader built in. -A
Search YC
http://searchyc.com/How+to+Revise+an+Email
is your friend for finding duplicate submissions:
http://news.ycombinator.com/item?id=562447
http://searchyc.com/How+to+Revise+an+Email
is your friend for finding duplicate submissions:
http://news.ycombinator.com/item?id=562447
If this is a duplicate, it's one that a lot of people could benefit from.
Summary:
1. Delete redundancies. 2. Use numbers and specifics instead of adverbs and adjectives. 3. Add missing context. 4. Focus on the strongest argument. 5. Delete off-topic material. 6. Seek out equivocation and remove it. 7. Kill your favorites. 8. Delete anything written in the heat of emotion. 9. Shorten. 10. Give it a day.
Summary:
1. Delete redundancies. 2. Use numbers and specifics instead of adverbs and adjectives. 3. Add missing context. 4. Focus on the strongest argument. 5. Delete off-topic material. 6. Seek out equivocation and remove it. 7. Kill your favorites. 8. Delete anything written in the heat of emotion. 9. Shorten. 10. Give it a day.
Summarising even further... note that most of those involve "delete"!
At least, that's what I usually end up doing. The more concise it is, the easier it is to absorb. It's quite sobering how long it can take to get something that concise though.
At least, that's what I usually end up doing. The more concise it is, the easier it is to absorb. It's quite sobering how long it can take to get something that concise though.
First 9 are good.
Who has "a day" to give?
Who has "a day" to give?
[deleted]
If they're only going to spend 20 seconds glancing at the response, I want it to be a breadth-first scan of the bolded items rather than a depth-first scan of the first paragraph.
For what it's worth, every management team I've worked under in the past decade of software development has loved it. I feel "uncool" for typing this here, but maybe it'll help someone to try the same approach (in addition to the great revising steps listed in the article).