editione1.0.3
Updated March 23, 2023You’re reading an excerpt of The Holloway Guide to Remote Work, a book by Katie Wilde, Juan Pablo Buriticá, and over 50 other contributors. It is the most comprehensive resource on building, managing, and adapting to working with distributed teams. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, 800 links and references, a library of tools for remote-friendly work, commentary and future updates, and a high-quality PDF download.
Consider the following versions of feedback on a proposal:
This is a terrible idea.
This is a terrible idea!
This is a terrible idea 😉
Now, think about each statement as it relates to the key communication concepts above:
Presence. How quickly do you think you should respond to this feedback?
Friction. How much effort would it take to figure out a response and where that response should be sent?
Intent vs. impact. Can you quickly identify if the statement has good or bad intentions?
Tone. Which tone does each take? Could each be interpreted differently by different people?
You can try to infer meaning from them, but ultimately they’re all ambiguous statements. If one of those statements came from your boss,* or from someone with whom you don’t have a relationship, you may even stop sharing ideas with them because their feedback wasn’t actionable and was even potentially hurtful (but you’re not sure!). And, unless you’re in an environment of high trust, you may take that criticism as a threat to your psychological safety.*
Now, evaluate this response instead:
Have you considered any alternatives?
This statement communicates that you’re not sold on the proposal, while avoiding passing judgment on whether the idea is bad or not. This aligns with the goal of helping your team make the right decision. The idea may indeed be a bad one, but saying so in a blunt way can be hurtful, out of line, or cause defensiveness. When it comes to communication, sometimes you have to choose between being effective or being right.
importantThe underlying principle of mindful communication is empathy. By thinking about and understanding what others are thinking and feeling, you’re better able to assess how your words will be received and formulate communication that is positive, helpful, and constructive (even if it contains disagreement or criticism).
Amy Ciavolino wrote a useful guide for software engineers that illustrates how to practice mindful communication while giving feedback to each other during code reviews. Much of her advice translates to other teams or disciplines. In the guide, Amy proposes tips for reviewers and authors with the purpose of improving the experience of giving and receiving feedback of written code, by considering each other’s perspectives. For example, she encourages reviewers to leave out nitpicking comments over stylistic preferences that can be subjective and are better handled by automated tools (called linters) to improve consistency and reduce fruitless arguments over programming style.
Mindful communication takes work and ongoing effort. Teams that develop mindful written communication practice the following:
Avoid sarcasm. This helps avoid ambiguity in your communication, and steers clear of potentially upsetting or harmful wording.
Proofread. Effective communication incorporates the habit of reviewing everything before you hit send or save. For particularly sensitive topics, you might even want to recruit someone you trust to review for tone and clarity before you send, to help make sure nothing you write will be taken the wrong way.
Use clarifying questions. Communicating curiosity can be less threatening than making statements, and asking thoughtful, more open-ended questions gives the recipient an opportunity to further explain or clarify their response as well.
Use emoji carefully. Emoji can help inject emotion and a casual tone when you want it, but be aware that they can also be ambiguous across ages and cultures, and their overuse can be considered unprofessional.
Don’t feign surprise. Saying things like “I can’t believe you didn’t know that!” puts the other person on the defensive and might discourage them from asking you for advice or getting your feedback in the future. This is a close cousin to the “Well, actually” phenomenon, which amounts to offering unsolicited advice (often in the form of criticism), talking down to someone, and not listening to what they have to say—or write—in response.
Don’t type angry. Never respond to messages when you’re upset. The best thing to do is to hit pause, take a break, and allow your emotions to lessen and your thoughts to clarify before returning to your keyboard.*
When building a distributed team, you may be tempted to require every member to write everything down. But an overabundance of information can be as problematic as the lack of it—overabundance makes it harder for remote teams to filter what is signal and what is noise.
Instead of writing everything down, an effective distributed team will focus on how to write what matters.
The clarity of information isn’t directly related to the quantity of information, but rather the quality, and surrounding context for it. As you determine the ways in which you will communicate as a distributed team, you’ll want to create a collective understanding of what to communicate, and how to communicate it in a way that shortens or eliminates physical, temporal, and cultural distances.