Considerate Communication
What is communication?
“A process by which information is exchanged between individuals through a common system of symbols, signs, or behavior”
— Merriam-Webster
What does considerate mean?
1. Marked by or given to careful consideration
2. Thoughtful of the rights and feelings of others
— Merriam-Webster
So what is Considerate Communication?
Exchanging information:
- Clearly (unambiguously)
- Completely (by being specific and including all necessary context for decision making)
- Kindly (which is not the same as “nice”)
How can I communicate considerately?
- Carefully consider your audience as well as your subject.
- Ask yourself:
- How will this communication be found (discoverability) either by your specific, intended audience or by those searching for the information it contains in the future?
- Who will be reading or hearing this (ages, genders, roles, cultures, etc)?
- What information are you trying to provide and why — for what purpose(s)?
- What is your audience likely to know (and not know), i.e. what may you be assuming or taking for granted?
- How is the information you are providing likely to be understood (and especially how might the information be MIS-understood)?
- Have I provided all the necessary, relevant information, confirmed it and enriched it, by adding images, links, references, etc wherever possible?
- What else can I do to ensure that the information is complete, easy to understand, and actionable without the need for more back and forth?
- How can I make my message more pleasant, enjoyable, memorable, etc?
Where Is Considerate Communication Important?
- Instant Messages, e.g. Slack, Teams Chat, etc
- Written requirements, e.g. user stories, tasks, bug/defect reports, etc
- Presentations
- Confluence documentation
- Naming things
- Source code comments
What Does Considerate Communication Look Like?
Aha! Best Practice Email — Don’t Update Delayed Releases
Hi April,
We’ve been wondering for a while about the best way to handle differences between our high-level, strategic release and feature planning in Aha! and our low-level, tactical sprint and user story/task tracking in Jira.
I’m copying Bob so that he can be familiar with the reasoning behind this recommendation and can add questions or concerns.
Executive Summary
The tl:dr (too long: didn’t read); from Aha! support on this is that we should typically not update our planned Aha! release dates to reflect tactical realities like project delays as they are tracked and reflected in Jira but instead move the diamond-shaped release date icon on delayed, in-progress releases.
If this sounds good to you, I’ll let the team know, and this will become our standard process.
Detail
I contacted Aha! support for advice or best practices related to delayed releases. We use Aha! for strategic release and feature planning with linked Jira user stories to track and manage tactical delivery. This gives us planned dates in Aha! and actual dates in Jira. When actual dates differ should we update the current, delayed release? Update subsequent releases?
Support recommended moving the diamond-shaped release date icon to the right (into the future) on delayed, in-progress releases to visually indicate the delay and rippling the dates on any subsequent releases. In addition, Bob has almost completed adding custom “Started (Actual)” and “Completed (Actual)” date fields to our Aha! features just below the planned “Start on” and “Due on” date fields.
Example Email Template
Please see the Medium article Amazon Accidentally Sent Out Their Email Template — Here’s What You Can Learn from It
Considerate Communication DOs and DON’Ts
- DO start with an executive summary (tl;dr). What is this, why is it important, and what will it require?
- DO provide well-organized, well-structured supporting detail (i.e. show your work).
- DO include supporting, clarifying pictures, diagrams, hyperlinks, etc.
- DO read and re-read your message yourself before delivering it.
- DO find ways to improve it.
- DO be consistent with vocabulary, spelling, and visual formatting. Use standard industry, organization, and team terminology correctly and consistently.
- DO include plenty of white space in written communication. It encourages the audience to read, improves readability by providing structure (grouping related thoughts), and gives the audience’s eyes a chance to rest.
- DO replace personal and possessive pronouns like“it” and “its” and demonstrative pronouns like ‘this’, “that”, “these”, “those”, etc with specific, concrete references to reduce ambiguity.
- DO tag, bookmark, and star important, useful information in online tools so that you can quickly find it later.
- DO declare your intent, i.e. make specific commitments and statements of intent. Statements like “I intend to … by 5:00p this afternoon” bias an organization toward action.
- DO propose your solution.
- DO reference past discussions and work to let your audience know that you’re aware of and have factored in this past thinking.
- DON’T assume knowledge or understanding by the audience.
- DON’T rely primarily on jargon. Call things what they actually are, e.g. an offer is an offer, not a claim, etc. Words are important; they have meaning, based on shared understanding and agreement. Without this, we cannot communicate.
- DON’T use passive voice; instead, use declarative, intentional language, which biases the organization toward action, e.g. “I intend to complete this by 5:00p CT today and will notify you when it is complete.”
- DON’T make your audience re-do work, remember for you, or remind you, i.e. “carry your own water”.
Regarding Jargon
Jargon includes domain-specific terminology (i.e. terms specific to a field like healthcare, military, finance, technology, etc) and abbreviations (e.g. technology’s TLAs or three-letter acronyms 😂, like AWS for Amazon Web Services, SQL for Structured Query Language, etc), which is a kind of compression that can enable faster, more efficient communication.
But both terminology and abbreviation require that all parties understand or are at least familiar with the terms and abbreviations being used, which turns out rarely if ever to be the actual case. Most people are afraid to admit that they don’t know a term or an abbreviation and are extremely grateful when someone else asks for clarification or definition
Assuming this knowledge is inconsiderate and will cause your communication to fail.
Think about all the screeching, skronk-ing, and static that old, acoustic modems used to make when connecting to the Internet. When beginning a new “conversation”, the modem on each end of the connection would establish the communication method(s) supported by the other (e.g. full or half duplex, amplitude, frequency, or quadrature modulation, etc), which we can think of as terminology. They would also try to establish the top communication speed each side was capable of supporting.
Only after all this “handshaking” was successful could a useful conversation take place.
On Long vs Short Emails
You may have heard smart, accomplished professionals disparage long emails and recommend (or even insist on) brevity. I think they may be missing something important and worth considering.
My emails tend to be lengthy, and this is intentional. After 25 years of communicating electronically, I’ve observed that short emails are almost never effective on their own. In order to accomplish anything, a long string of short (incomplete and often inconsistent) emails is sent. Why not invest a little time up front in order to create a message that is actionable?
For me, email often functions as a way of thinking through and explaining my position to an audience who likely doesn’t have all the information needed to reach a conclusion and/or take action. As I’m writing, reading, re-writing, etc, I’m thinking about the DOs and DON’Ts above and adding, removing, clarifying, supporting, enriching, and amplifying information to make it less likely that my audience will need to request clarification or more information in subsequent rounds of communication, each of which can take hours or days to complete. I start with a summary statement and then show my work, leaving the decision about whether to continue to the reader.
As a bonus, these complete records of my thought process often serve to re-orient me after time has passed or when changing contexts during a busy work day or week.
The “too long” crowd tends to assume that everyone already knows the situation, its history, and what’s going on in the author’s head, when usually none of this is actually true. These people also tend to accept something that kind of works to working toward something that works well.
So don’t be bullied into writing short emails. Do what’s best for you and for your audience. They are, after all, your emails.
And remember …
“The people who are nice to you aren’t always being kind to you.
Saying what you want to hear is nice. People sugarcoat feedback to make you feel good today.”
Sharing what you need to hear is kind. People speak honestly to help you do better tomorrow.
Candor is an act of care.” [aka speaking the truth in love]
— Adam Grant, Organizational psychologist at Wharton, #1 NYT bestselling author of THINK AGAIN, and host of the TED podcast WorkLife
Copyright © 2019 Douglas A. Wilson. All rights reserved.