Writing: Your Next Superpower

Suddenly, in 2020, most humans found themselves working from home. For many, it was a new experience. If you were one of them, you might have noticed something: writing is powerful.

We might have neglected this skill (or art, if you prefer) in the years after high school or college. Even though we all write a little every day. Maybe not - we rather text a lot more rather than actual writing. A chimp too can toss together a few words to deliver a message. But in a work context, that’s not enough.

The message we want to deliver is more complex than a mere “I’ll be late”. It needs to carry more information, and we don’t want the recipient to misunderstand it. Here’s another thing you might have noticed: writing is hard.

One last thing (and then I’ll close this wordy prologue) there is a prize that comes with writing. Some might have identified it, some others might only feel it. Written text is here to stay. You can rely on it.

The ancient Romans knew it already: Verba volant, scripta manent. This is such an ancient quote, that we’ve forgotten the source. It means that spoken words fly away, while written words remain. (It was probably used to highlight how a written contract has much more value than an oral contract; ancient Romans probably used to scam each other a lot, just like the modern ones).

Verba volant

Calls, with video or not, are good and stuff, but you lose more than what you get. Don’t get me wrong, there are cases when it would be silly not to have a call and keep writing instead. Like for demos.

In other cases, you don’t want to have a call. For example, if you are asking for help, a video call leaves you with no reference. If you want something to look at after the call, once you’re alone again, you’ll have to frantically take notes; and even with your notes, you’re left with partial knowledge, with gaps to fill.

I don’t know if it applies to other industries as well, but in computer programming, we use to say (and think) that writing code is easier than reading code. That’s why every piece of code you come across is “crap”, even if it was you who wrote it with the best intentions a couple of weeks before.

Similarly, talking is way easier than listening to someone. When talking (like we do on daily bases, not when giving speeches), we try to shape an idea on-the-go relying a lot on the ability of the listener to get what we mean. The words themselves have a marginal part in this exchange of information. It may seem that it’s a more efficient way to share information, while it’s just a quicker way to get it done, but not really quality-wise effective.

Scripta manent

For yourself

Keeping in mind that each direct message, comment, anything is a piece of documentation, you’ll find building the best knowledge collection your team has ever had.

Keeping in mind that each time you put your hands on the keyboard to reach for someone, at that moment you start enjoying the benefits of writing. If you do it right! Don’t just toss words to your colleagues.

Mindfully writing helps you to straighten your thoughts and crystallize them. For example, if you’re reaching for help, you might want to try first everything that is in your power and knowledge.

Writing a summary of what you’ve done, will help you to unwind your work and see clearer for other paths. It might help to foresee possible answers you might get and allow you to try that immediately instead of asking for help. If everything fails, you’ve got your nice summary to send to your expert for help.

This summary will also help them to picture in their minds what you’ve done and what you’ve been through and better give you an answer.

At the end of this process, whether you got to the solution by yourself, or with the help of your expert, you’ve got a nice piece of documentation where a scenario is well described and a working solution is provided.

That might help others in the future.

The same can be said for pitching ideas. Gathering your thoughts, processing them can firstly help you to see them better and only after to be discussed with others. In this case, you might want to have a collaborative document and aim to clarify what could be seen as a flaw in your idea.

The asynchronous discussion will lay the foundation of the documentation.

For the recipient

Don’t be DRY!

Who likes a dry sandwich? Or a dry slice of pizza? You wouldn’t wish it to your worst enemy either.

If you’re not familiar with the DRY concept, here it is. In computer programming, it’s a bad thing if parts of code are repeated. And DRY stands for Don’t Repeat Yourself. It’s OK for programming, but when writing we should be generous and sometimes repeat stuff.

If you’re trying to send a message, repeating parts helps to highlight important parts of the message. Parts that should not be overlooked. Presenting them to your reader several times in the same form, will help them to properly get them.

If you are receiving information or directives, you want to make sure that what you got from the message is actually what the sender meant. Repeating things with the same words does not help here, paraphrasing is what you should do. Putting the same message down with different words, helps the sender to understand that you understood the message.

This leads to the next paragraph.

State the obvious

This might sound stupid, but it isn’t. To state the obvious is underrated and very useful. What is obvious for you, might not be obvious for the others and vice versa.

I hear you asking “how do I know that something is obvious for me if for me is obvious”. You’ll get there, with practice. Putting yourself in the shoes of your recipient will help you to see what might not be obvious for them. And sometimes, let’s be honest, we know that something is obvious for us in the back of our mind and deliberately not write it because writing is hard.

Don’t rely on someone’s domain knowledge

If this paragraph seems redundant to you, please read again the previous one.

Beside direct messages, we deal a lot with tickets, regardless of what is your ticketing system. Sometimes it happens to deal with a ticket that it was written in such a rush, that one might think that it carries god-knows-what contagious disease and the reporter wanted to get rid of it as fast as possible.

In many cases, they glob together jargon terms, acronyms, math symbols. The ticket reporter, as their close teammates, can make sense of these texts, but most of the readers are left to decipher the content of the ticket before actually starting thinking. In these cases, one has to fish from a domain knowledge might not possess. How am I supposed to know what that weird acronym stands for? Can I ask? Will I look like a fool? No! Ask, ask, ask! They’ll be looking like fools for not being able to write more clearly.

To rely on someone’s domain knowledge is a bad habit. It frustrates the reader and kills productivity. To write a clearer ticket is easier and faster than trying to decipher one. And even if the recipients will think to have got the message right, they might have not.

Besides, with this contrived ticket, you lose the documentation. Even if after a while someone’s got the domain knowledge to understand the content and work on that. Tickets often remain as reference for the work done (for software development at least). So if one day a new team member has to dig into old tickets, they will face the same challenge in understanding their content.

Grammar, punctuation and formatting

Make the effort to use proper grammar. Grammar rules are good and help to write clearer messages. Punctuation is a big deal and you can compound it with formatting. Italic, bold, code, quotation, links - use them properly so that the final result is pleasing to read and the formatting meaningful.

Don’t paste humongous URL, format them as links with meaningful names. You might want to search for them in the future and it will be of no use to have named all the links link, here, this.

Bullet points don’t equal prose. They have their purpose, don’t use them otherwise.

Don’t write line by line

With the ellipsis function of basically any IM program, you nail a person on their chair when you write a long message line by line.

And besides, by doing so, you don’t allow yourself to think about what has been written, because it’s already gone (yeah, you can edit it in Slack, but it’s not the same).

Editing sent messages

Since we’ve mentioned this function, editing sent messages should be used very little.

First because you should have written, read, edited and rewritten your message a few times before sending it; and second because the recipient has not access to the unedited version.

Keep edits mostly for typos, but if you really need to edit a message, instead of deleting the edited part use meaningful formatting like the striker allowing the recipient to see the whole evolution of the message.

Be there

Sometimes the message we want to send is simple and its function ends after the first read. I’m thinking of greetings and “thank you messages”. These are usually very short, and by writing them in full we show that we care. Write “Thank you!” instead of “thanks”, write “yes sure!” instead of “k”. Use the exclamation mark to show sincerity (and emojis if they fit your personality).