Summary (draft)

This prioritization shapes the design of my ContactCard.

The read vs. write preferences are asymmetrical. This asymmetry reflects my current state/understanding and indicates the need for further analysis.

Background

I'm capturing and collecting some notes on my experiences with optimal human to human communication protocols and mediums from my perspective, i.e. when others are trying to communicate with me, what works well and what doesn't work so well, and why, in the hopes of maybe helping to uncover and define more efficient habits for purely factual communication between humans.

Most of what I've recorded here seems "obvious" to me, and yet is either not commonly known, or not commonly adopted. Perhaps by documenting it (per communicating content preference #1, wiki), it will be easier to encourage improvement in factual communication styles.

Disclaimers

  • Incomplete Work In Progress This page is very much both incomplete (is merely being filled in as examples are found and/or experienced) and a work in progress (communication protocols will be incrementally improved over time).
  • Non-emotional For now, other than this brief note, I'm specifically not including "emotional" and other highbandwidth personal communications which typically have very different requirements (interactivity) and different ideal solutions (e.g. face to face) than purely factual communications.
    • Emotions are often filtered out in text communications and thus difficult to discern. This can be a positive (reduce drama, spreading of negative emotions) or a negative (emotional miscommunication).
    • Emotional context is best communicated in order: IRL F2F, video chat, audio chat (e.g. phone). The quality of the audio is important, as is the realtime nature. Voicemail is perhaps the worst.

Related Projects

Preferences

Methodology

Communications should maximize:

  • Signal to noise ratio
  • Information density
  • Multitaskability
  • Positive reinforcement
  • Permalinks to content
Communications should minimize:
  • Time length of synchronous communication
  • Time length of voice or other read-time constrained by write-time messages
  • Roundtrip requirements (the number of times you have to back and forth)
  • Intrusiveness
  • Cognitive load
  • Negative reinforcement
  • Latency
  • Ephemeral content

Preference Order

Reading Me
Current state:

Updates: Communicating content / state information
  1. wiki - easiest to incrementally collect state and state changes, in an open manner that others (the community) can help iterate. Organizational/capturing cognitive load is shifted more towards the writer than the reader, and thus is overall more community-efficient since typically more readers (and reading) than writers (and writing). Check The Wiki Wiki Wiki Wiki. Note special cases:
    1. consultant/client communications (e.g. contracts/designs). Any documents or specifications of a transaction/commerce nature will likely require strict datetime versioning and both access and editing controls so that the expectations are set and persisted as agreed to, based on the reality that clients frequently try to change the specifications for work (designs, etc.) after contracts have been signed.
  2. specialty sites - e.g. http://upcoming.org/ , http://flickr.com/ - greatly simplified interface for capturing data-type specific state information (whether attending/watching an event, photos) and communicating it to those that have expressed an interest without me having to bear the cognitive load of who to tell etc. everytime I make an event attendance/interest decision. Ideally these would be represented using data-type specific microformats which could be published on a blog or wiki, thus reducing the number of places to check/publish-to.
  3. blog (including Twitter) - permalinks to content help encourage more efficient discussions about the content
Obsolete:
  1. email - cognitive load of figuring out "who" to inform, what "subject" to use, noise from ".sig" etc. email signatures. See EmailEfail for more.
  2. fax - can't index/search it
  3. printed letter - high latency
  4. voicemail - read-time constrained by write-time, unnecessarily slows down consumption of content to the rate that it was recorded at, often has unnecessary higher cognitive load (the effort required to listen and remember what a person is saying is greater than reading and being able to easily re-read a word or two as necessary by moving one's eyes rather than having to rewind/replay a voice message). Regularly checking only about twice a week when in the US, may check once every 2 weeks when traveling. DO NOT leave voicemails for anything needing a response in a week or less.

Notify:
  • IRC channel, IM, txting, email
Notification
Good:
  1. IRC channels - empowers/enables the distribution of simple request handling load. archived channels ideal, especially if archived with semantic HTML and permalinks for each statement
  2. instant messaging - brief FYIs re: URLs are good
  3. txting (SMS) - works well with smartphones with decent browsers, especially those with IM clients as well for copy/paste sending such URLs back to a desktop client.
  4. Twitter direct messages including URLs - relieves the sender of needing to decide how the reader wants to receive it (would be above IM, but Twitter is too unreliable on a day to day basis for that. above emailing because Twitter DMs are sent as email in addition to the notification method of recipients choice).
  5. emailing - UI requires more clicks to get at the content, and more contextual noise as well. Regularly checking once a day on home weekdays only. Email sent on weekends or while I am traveling will likely not be read until the first weekday after returning home from traveling. DO NOT email for anything requiring less than 24 hour response.
Reviewing:
  1. phone - phone calls are *incredibly* intrusive and thus almost always rude and undesired. Almost. See the Telephone section below for exceptions.
Obsolete:
  1. voicemail - again read-time constrained by write-time, any URLs need to be retyped (rather than just clicked). Regularly checking only about twice a week or less when traveling. DO NOT leave voicemails for anything needing a response in a week or less.

Etiquette

Web

Photo sharing

DO:

  • Upload flattering photos of people - everyone likes seeing nice photos of themselves.
DON'T:
  • Upload unflattering photos of people, unless they specifically ask you to (goofy/funny photos etc.)
PROTOCOL(S):
  • Photo that you are in takedown protocol. If you see a photo with you in it in my Flickr stream that you dislike for any reason, tag it with "YOURNAMEHEREhatesthisphoto" and I will promptly mark it private.

Instant messaging and IRC

DO:

  • immediately mention in initial message the general topic area / URL that you want to FYI / ask a question about or discuss.
DON'T:
  • just make generic presence queries / greetings without context, because the receiver of such a query has no idea whether they have the time to interrupt what they are doing to bother with what your real request is, and thus have no choice but to deprioritize your interruption to an extremely low level (effectively being ignored). Expect that IM windows (or IRC /msg windows) opened with the following will simply be immediately/reflexively closed due to the zero-content/stateless nature of the message. E.g. avoid (as in don't even bother wasting your time with starting an IM conversation with) any of the following (regardless of capitalization)
    • "allo"
    • "allo?"
    • "alo"
    • "alo?"
    • "got a sec?"
    • "hey, around?"
    • "hey tantek"
    • "hey tantek, got a sec?"
    • "hi"
    • "howdy"
    • "psst"
    • "pssst"
    • "there?"
    • "u around?"
    • "u there?"
    • "ut?"
    • "you there/"
    • "you there?"
    • "you up for a quick question?"
    • "yt?"
  • just make generic get back to me requests without context or specific purpose, they will be ignored. E.g. avoid:
    • "email me at some point"
  • ask me to promote something on a voting site, e.g. avoid:
    • "Can you please digg if you get a moment? {URL}"
    • "digg please: {URL}"

Email

Summary Response

Suitable for dropping into email responses (reconsidering...)

I'm reducing my use of email. Please see http://tantek.pbwiki.com/CommunicationProtocols .

Not so sure about this. It seems too short and perhaps a bit rude and discouraging of communication in general. For those with whom I might want to discourage communication with, I would hope there would be a better/nicer way of doing so.

Removed or left out:

  • "in deference to IM/IRC+wiki". to keep the actual preferences live on the CommunicationProtocols page rather than statically captured in an email.
  • "in order to scale". I think this meaning of "to scale" will only confuse most people.
  • "for how to contact me". If they can't figure out that's what I mean, do I really want them contacting me?
For now see EmailReduction for improved email handling.

Telephone

Calling

First, note that I almost never pick up the phone. Because:

  • Phone calls are almost always an intrusion into whatever I am doing realtime "in the moment" in front of me, and thus a distraction (efficiency reducer, priority inverter, GTD collect vs process separation failure), and rude to the people I am with in person.
    • Instead: try txting, giving a very clear reason why you think a phone call is necessary (at the moment or later).
  • I'm often in loud areas where phone conversations just don't work.
    • Instead: txt.
  • I'm traveling. Answering phones works very poorly in airports, e.g. checkin, security, loud announcements, distractions, etc.
  • I'm abroad. If I'm in a different country, especially one more than 3 hours off from my current time zone, I will almost certainly not answer the phone.
Exceptions. There are a few (very few) cases where phone calls *may* make sense (even then most of the time txting works better).
  • realtime sync for meeting up. When trying to meet up for an event planned in advance (via some other communication method), a short phone call *may* sometimes be more efficient to coordinate than txting back and forth. That being said, try txting first, and only after one back/forth is insufficient, then call.
  • emergency for emergency contacts. Everyone has a short list of folks for which they are emergency contacts, and who know to respect using the phone only when it is absolutely necessary and thus likely to be an emergency of sorts. I'll answer these kinds of calls if possible, but since it's often not possible, even in an emergency, txting may be a more reliable method of communication.
  • local to the city I'm traveling in. When abroad, I may answer phone calls from those local to the city that I'm in, as it may be a more reliable communication method than other options. I will still encourage folks to instead:
    • Twitter direct message (free for the sender and the receiver)
    • Txt
  • emotional context. Just a pointer to the Disclaimers section above.

Voice Messages

First of all, avoid voice messages if at all possible due to the read-time-constrained-by-write-time problem. Use IM or Texting instead.

However if you must leave a voicemail (e.g. you are unable to type/text, perhaps you are driving, maybe you shouldn't be talking on the phone and driving though) then:

DO keep your message under 30 seconds and identify:

  • NAME. who you are
  • ORG. what organization you are with (sets context for the message)
  • TOPIC. about what topic (immediately helps receiver determine whether to process this to-do item immediately/urgently or to postpone)
  • REQUEST. what you need/want - mention a specific request (ditto)
  • BY WHEN. when you need an answer (helps with processing prioritization and relevance as well)
  • CONTACT INFO. leave follow-up contact info (redundancy, in-case the receiving voicemail system does not record the caller-id of the sender, or another medium is preferred for response, e.g. wiki/email/IM etc.)
DON'T:
  • pause with "uh"s while collecting your thoughts
  • use impatient, patronizing, condescending or otherwise negative communication tones
  • make general non-specific contact requests (expect these to get deprioritized, just like "yt?" IMs). AVOID only requesting
    • "call me back"
    • "get in touch"
    • "can you please give me a call"

Reference

Others Communication Protocols And Analyses

Discussion Elsewhere

Most recent first.
View blog reactions

Related Articles

Most recent first.

2008

March

February

2007

October:

  • E-mail Faces Deletion (2007-10-12) by Robert Scoble published in BusinessWeek.
  • E-Mail Is Easy to Write (and to Misread) (2007-10-07) by DANIEL GOLEMAN published in The New York Times, Job Market section.

    In contrast to a phone call or talking in person, e-mail can be emotionally impoverished when it comes to nonverbal messages that add nuance and valence to our words. The typed words are denuded of the rich emotional context we convey in person or over the phone.

    E-mail, of course, has a multitude of virtues: it’s quick and convenient, democratizes access and lets us stay in touch with loads of people we could never see or call. It enables us to accomplish huge amounts of work together.

    Still, if we rely solely on e-mail at work, the absence of a channel for the brain’s emotional circuitry carries risks. In an article to be published next year in the Academy of Management Review, Kristin Byron, an assistant professor of management at Syracuse University’s Whitman School of Management, finds that e-mail generally increases the likelihood of conflict and miscommunication.

    One reason for this is that we tend to misinterpret positive e-mail messages as more neutral, and neutral ones as more negative, than the sender intended.

August: July:

Historical Documents

The following article documents various historical communication habits and differences across a variety of late 20th century cultures and examples:


Return to ProjectsList or FrontPage.


Page Information

  • 2 days ago [history]
  • View page source
  • You're not logged in
  • No tags yet learn more

Wiki Information

Recent PBwiki Blog Posts