Communication is an essential part of leadership, and written communication is particularly crucial.
It’s tempting as leaders to declare intention only in meetings, but without a written document explaining larger initiatives, it becomes very challenging to express intent consistently and widely across time.
There is an issue with written documentation, though: it feels fundamentally different to write a document than to read it.
When writing, you own the material. It’s a thinking exercise as much as a writing exercise. It forces you to work through the problem as you attempt to translate the information in your head onto paper.
The act of reading, on the other hand, is an entirely different experience. A person shifts context from whatever they were doing into parsing the document, and needs to spend time understanding the intent of the writer, using formatting and their style as cues along the way. They do not ‘own’ the material, they are adjusting their own mental position to try to accommodate the stance of the writer, often skimming quickly as they do so.
It can be tempting to assume that once you’ve written something down and someone has read it, the two of you have effectively communicated. In an ideal state, that would be true. However, in day-to-day life, this is not always what occurs.
There are ways to think about and approach the writing process that allow for an even flow of information. Today, we’ll talk about some ways to write documents so that they are easier to read and we can enjoy better communication across our teams.
Read it from someone else’s perspective
The single most important thing we can do to write better documents is to write them first, and then reread them, positioning ourselves from the reader’s perspective. It seems like such an obvious thing to do, but doesn’t happen enough in practice.
This act is slightly different than rereading your own doc before sharing it. This act requires a shift in our own perspective while reading: what would I think if I was reading through this quickly and had never seen the material before? What would I need to know right away? What are the key questions I might have in that case and how can I quickly resolve that for the reader?
Does the reader need to know who is involved? Do they need a roadmap? Do they need justifications? How can you communicate everything that they need to know (not just what you want to say) with as much clarity as possible?
When you are doing this, it’s pertinent that you edit diligently. Restructure your draft, let go of things if they are crowding your message. Rewrite anything that is potentially confusing.
Don’t blather
On the subject of clarity, when you’re writing a document it’s important to get to the point. Blather includes any kind of overstated, corporate jargon that sounds official but means very little. For some reason, it’s quite popular, and completely gets in the way of communication. It’s tempting to use overcomplicated language so that you sound official, but try your best to steer clear of this.
Speaking plainly and with clarity is actually quite hard, so you’ll have to hold yourself accountable to it. There is particular risk with any document that affects the lives of many people (one that expresses organizational change, agreement, or any technical design document).
I would even go so far as to say that sometimes people write this way in order to be less transparent in these high-risk situations. Speaking clearly can be an act of courage because you make intentions clear.
Conversely, if you blather, it’s possible to be so unclear that multiple people reading your doc come away thinking that they agree when they’re in fact imagining different things. Try your absolute best to write for clarity, not for status. The purpose of the document is to communicate your ideas, not to show off your vocabulary.
Format your document clearly
Your reader’s attention is valuable; the chances that your audience is reading quickly so that they can understand something and move on is high. This means that formatting is extremely important. Take a moment to structure the document so that the headings and outline are expressing the most important points, and if someone needs to jump to a section they can get the information they need quickly.
It’s a good idea to put the author and last edited date on the document as well. This allows anyone who comes upon the doc without you to gain a sense of who you are and when this document was important. The best-case scenario is that the document either stays relevant over time or is an important indicator of past context.
Reflections
As engineering leaders, our jobs become less and less about writing code, and more about writing the expression of large strategies or sets of ideas. The more you write with clarity and with respect for your readers’ time, the easier this becomes. Taking a step back to think through the act of writing itself can pay dividends when it comes to communicating with your peers and team.
