Information: what to communicate

Misrepresenting opinions for facts and other dangers of communication

Continuing the series of 7 topic-by-topic emails covering the Miirror Framework for written communication. Our usual reminder of it:

First, think about the Message - which is formed by Information and Intention.
Then think about the Reader - which requires Rapport and Order.
Then Rewrite it.

This email is about the Information.

Information is the core of communication

Information is the content of the message. It is what you want to communicate. It can be facts, opinions, instructions; or questions, requests, doubts.

When you write down your ordered list of topics to include in the message, all that is Information is listed first. Write these topics in a very precise way. Being precise is the only thing that matters at this moment. It may be prolix, blunt, curt, rude. You are just organizing your thoughts and writing a note for yourself. You do not need to worry (yet) about the intention, how you sound to the reader, and it only has to be clear for you. All the exact pieces of information you want to communicate must be present in this comprehensive list.

Make the type of information explicit

It is important to write down what type of information it is. A lot of misunderstanding and friction happen because readers confuse the nature of the information they are reading. Let me go through some examples.

Opinion vs. Fact

Make it clear in your mind when something is an opinion or a fact, then check that your writing is reflecting that.

An opinion stated as a fact will be read as a false, manipulative or arrogant statement; and can lead to incorrect decisions if taken at face value.

A fact stated as an opinion will be read as insecurity, lack of knowledge or passive-aggressiveness, and can lead to unnecessary further debate, delayed decisions and waste of time and energy for everyone involved.

Make sure you are correctly using “I think it is…” and “It is…”.

Suggestion vs. Order

Orders are a sensitive topic. Outside of the military, no one like to receive direct orders stated as such, even from bosses and CEOs. However, this is such a common issue, that we have a very established solution: always use "please". Say it objectively, then use "please". For suggestions, you will use other cues, like "I think you should..." or "Why don't you...".

Orders that look like suggestions may be dismissed and not executed. Suggestions that look like orders may be implemented even if the reader had good reasons to suggest otherwise and will also create friction in the relationship as the perceived order will probably be out of place, as it was a suggestion in the first place.

A caveat: these are writing tips for a situation where you presumably need to give an order and present the risks of making it sound like a suggestion. As a career and personal advice: don't overuse orders, even if you are in a hierarchical position to do so. It removes autonomy and weakens future orders that could be more important. If there is no hierarchical relationship, then don't use orders at all. Every request you make is a favor you ask or a suggestion per definition.

Suggestion vs. Question

Rhetorical questions — a question used to make a point rather than to obtain an answer — might be interesting in philosophical texts or coaching sessions, but often cause bad impressions in professional written communication.

Imagine a case you are using rhetorical questions to suggest another developer should write more descriptive commit messages. If the answer is too obvious, the reader will consider it patronizing — "What is a commit?". If the question's tone sounds derogatory, the reader will consider it offensive — "What kind of person writes 'changes' in a commit message?". If the question allows for multiple valid answers, then your suggestion will not be clear — "What a new developer will read to understand your software?".

Avoid rhetorical questions, leave questions for real doubts.

Request for clarification vs. Skepticism

You may be in doubt about something, or you may doubt someone's statement.

If you do not understand something, state that clearly and use questions to ask for more clarification - "I don't understand. How our deploy will change if we start using GitFlow?". If you are skeptical of an affirmation, state your skepticism clearly and use counter-arguments to explain why you are skeptical - "I don't think we should do it. We have three or four releases each day and GitFlow will just increase work. I don’t see the benefits."

Avoid ambiguous phrasing like "Why do you want to change our deployment flow?". It is hard for the reader to understand if it is a rhetorical question stating that you think you shouldn't make any changes or you are honestly asking for the reader's reasons to propose a change.

If skepticism is perceived as an honest question, it will lead to everyone wasting time. If an honest question is perceived as skepticism, not only it will not be answered as it may be read as a sarcastic question and deteriorate your relationship with the reader.

—

Making these distinctions is what I mean by saying you shall be precise when listing the information you want to include in the message. Avoid misunderstandings by making it clear what type of information you want to communicate.

Next week, I will write about Intention. How to have it in check before writing and avoid confusions transmitting it.

Thanks to everyone who replied me. I would love to hear from more people with feedback and specific requests for help. Just hit reply!