People skeptical of distributed, asynchronous, written communications sometimes make they understandable objection that it is often difficult to interpret the reactions, specifically the absence of reactions, to written online communications.
The reasoning goes like this: if you inform someone of something in a face-to-face conversation, there is practically no way for them not to provide some sort of feedback. Even if the recipient of a verbal message doesn’t say a word, they usually exhibit some unconscious, nonverbal reaction, which can carry a whole load of information:
- The person might smile, light up, and become actively engaged,
- they might express surprise (pleasant or unpleasant),
- they may show signs of dismay or annoyance, or even anger,
- they might just stare or wander off, indicating disconnection or indifference,
- or anything in between.
In online, textual communications, people obviously also exhibit all those reactions, sitting at their desk, lounging on their couch, walking with their phone — it’s just that the sender of the message usually never gets to see them.
In addition, a face-to-face conversation is a one-to-one communication mode that we direct our undivided attention to. In contrast, textual online communications are often many-to-many, and we usually get many more parallel inputs than we do when we’re speaking to a colleague or acquaintance or friend.
That means that while in a face-to-face conversation we’re always answering, or at least showing our reaction to what was said, in online textual communications we must pick and choose what to react to, and what to just absorb without providing any kind of feedback to the message sender.
In online communities this has been known since at least 2000, when Bryan Warnock formulated it as “the ostrich theory”, although it eventually was named “Warnock’s Dilemma”1 by Dave Mitchell. Writing about mailing list posts without replies, Bryan wrote:
The problem with no response is that there are five possible interpretations:
1) The post is correct, well-written information that needs no follow-up commentary. There's nothing more to say except "Yeah, what he said."
2) The post is complete and utter nonsense, and no one wants to waste the energy or bandwidth to even point this out.
3) No one read the post, for whatever reason.
4) No one understood the post, but won't ask for clarification, for whatever reason.
5) No one cares about the post, for whatever reason.
— Bryan Warnock, “Re: RFCs: two proposals for change”, perl.bootstrap mailing list, 2000-08-07
In asynchronous and distributed work communications, we have much the same issue. The beautifully crafted five-paragraph briefing that you sent out this morning may have been considered manna from heaven by your recipients (if you’re a manager, your recipients are usually your direct reports), and they immediately sprung into action energized by your electrifying leadership. Or maybe nobody understood a word of the unintelligible drivel you concocted, but out of respect or courtesy they are very hesitant to point this out.
So in my humble opinion, there are two very simple things you can do as a manager to address Warnock’s Dilemma in your distributed team: making it a habit to specifically encourage objections, and establishing a culture of acknowledgements.
The habit I have developed to encourage objections is to not merely ask the recipients of a message to raise questions if they have them, but to ask them to poke holes in whatever I’ve been writing.
To that end, I have standing phrases that I use, such as:
- “Do you think that sounds reasonable?”
- “Did I overlook something important?”
- “Can you think of a better way to do this?” (Better than my suggestion, that is.)
- “I’m pretty sure I’m missing something here, can you pitch in?”
- “Am I way out in left field with this?”
- “How nuts of an idea is this?”
I might use a variation on one or several of these phrases at the end of an email, but also in the comments section of a wiki page (or in individual inline comments), or even in the reply thread of an issue tracker.
This serves multiple purposes:
- There are many individual areas of knowledge where someone on my team is more of an expert than I am. Obviously, I want those people’s ideas on the table.
- It establishes the notion that nobody’s opinions or suggestions on technical matters are sacrosanct, and we want to do the right thing in any situation, not follow the hippo.2
- It encourages others to ask for feedback in the same manner, whenever they float ideas or suggestions of their own.
- It establishes that there’s nothing wrong with being wrong from time to time.
So now, on to acknowledgements, that is, what to do when you have no objections on something.
Here’s a general rule that I use: all communications should be acknowledged. Yes, really. Anything my team sends me, I try to reply to with at least “ack” or “OK”, but frequently it’s something like “great, thanks!” — it costs nothing to be kind.
Likewise, for everything I send to my team I can count on getting the same kind of reply back. There’s something I need to pass on from higher up? Or just something I want everyone to know? Out goes an email, in come a few “ack” replies over the next few hours. I don’t even have to specifically ask anyone for acknowledgement anymore, it just happens.3
In this context, we deliberately use written acknowledgements — as in, somebody actually types something, even if it’s just the two letters “OK”. I find Like buttons or thumbs-up or email “read receipts” (anyone remember those?) oddly perfunctory.
This has a nice side effect, in combination with encouraging objections: someone who — while knowing that objections are always encouraged — acknowledges an idea, opinion, or plan, actually makes it clear that they are on board with it.
HiPPO: the Highest-Paid Person’s Opinion. Following the hippo is when you value ideas and opinions by seniority of their originator, not by correctness or factual merit. ↩
We’ve also codified this in my team’s communications guidelines. You don’t have something like that? Write them. ↩