To be efficient, the technical aspect of communication needs to be crafted and perfected on all its levels in the same way as the software code. It is not inherently bad, when the communication is fluffy and informal. It is likely to make it more warm in the human sense. However, seeing communication as a soft skill without structure or method has a high price tag: excessively long discussions, confusion, misunderstandings, echo chambers. Some companies can afford it and some decide they cannot.
In this note, I collect some patterns or rather little technical disciplines that I have found helpful over years.
If I receive an e-mail asking me to do something, I resist the urge to get back straightaway with a confirmation that I will fulfil the request soon. Instead, if possible, I take a practical step of fixing things and write back about what has been done, not what will be done.
If I need to discuss things in writing, before writing any e-email, I first ask myself: can it be done on Confluence (that's what we use; substitute your own collaboration framework for it). A a wiki page creates a single point of reference for a discussion, instead of a trail of e-mails sent to a varying list of recipients that easily digresses and creates confusion. A structured face-to-face meeting is much better most of the time - and even better to take notes on a wiki page during the meeting.
I always re-read my e-mails before sending, trying to take the recipient's point of view and speak her/his language. I try to craft every word to make my e-mail as short, clear, and structured as possible. It does not take long and saves time of sorting out confusion created by long or imprecise letters. I use nested bullet point lists a lot.
I try to totally exclude demonstrative pronouns like 'this', 'that', 'these', etc from my speech and ask others to do so, when appropriate. For example, if during a daily standup, one reports, pointing to an item on the backlog: "Yesterday, I was working on this", others may not see clearly to what he points. More importantly, he does not articulate for himself what he was working on. He was doing something, but does not make an effort to promptly express what he was doing, which is a typical pitfall at all the levels of software development from day-to-day coding to high-level business analysis: a conscious practice of always naming things consistently at the right semantic level (in the language to which other engineers, or managers, or clients, or users could relate) is a key to articulate designs and good processes.