To find great remote employees, prioritize candidates with strong writing skills

Good writing is a business and career advantage. Try to be clear, concise, and get to the point real quick.

Here are some of my learnings and anecdotal incidents I have experienced so far. Still learning and recalibrating as I go on.

Try following BLUF[1], a military communications acronym — “Bottom Line Up Front” — designed to enforce speed and clarity in reports and emails.

We, especially in the eastern culture, tend to weave stories and try to form a connection before hitting the point. When it comes to team communication, either in emails and other forms of communication, it is better to reverse it -- start with the important points and then, if needed, weave the stories to make it clearer and empathetic.

However, just knowing the tips/tricks isn't enough, communication (more aptly writing) is a habit that becomes better with more practice.

One common suggestion I advise my team is, "I cannot read your mind, you have to tell me. The same goes with the client/customer -- ask them, talk to them unless you can read their mind."

If you work for a Startup or any Company for that matter, how do you think the founder or the C-Suites know what you did. Make it a habit to write weekly, bi-weekly, or monthly reports and email them. I guarantee you that it will come to pay you with compound interest in the future.

Here is a scenario. You just joined a new company. You report to a few at the top and work with a few under you. You have to gain the trust of those below you and prove to the ones above. If you are someone who wants to "prove it", do beyond your call, and wants to go the extra mile, what would be an ideal step besides the usual work you have to do.

Try this (I think I read this on Seth Godin's Blog[2]). Write a regular report of the accomplishment of your team, and highlight the people under you -- include their names and what they did that help you, and the team. The tops know what's happening and can take decisions without having to read your mind or setting up "meetings" and "catch-ups" which most will forget as soon as they are over. When in writing, they will likely mark it and act on it appropriately.

For those Individual Contributors (IC), I would still suggest doing something similar. Others, including your managers, friends, colleagues cannot read your mind. You might be one of the best programmers and you can prove it with code but imagine supplementing that with some form of communication on your gotchas, tips, tricks -- people love to hear those.

I was once in a team, big enough, and we had just one DevOps. He was rather silent, talks to very few people, the corner guy. But I was intrigued by the short and clear emails he sent when things are going to go down, backup, etc. while maintaining everyone's DevOps needs without much sweat (or is it). I began talking to him often and he was friendly, eager to tell me interesting things. He was also a regular documenter and writes some of the best documentation of what he did, why he did and was pretty much future proof. Almost none knew about that but he continues the routine. That documentation soon became a way to onboard new recruits when a new account was started for DevOps for enterprise customers earning $100Ks in the first few months of operation. By the time he left or close to it, that department was pulling in close to millions.

If you are in the lower rung and believe no one listens to you, despite you being smart -- think again. You have writing as your weapon. One of my career advice is, “Imagine yourself already advanced in your careers a year or more, then start acting and doing the roles you would do by then.“ If you are asked why you do something better because that is above your pay grade, you are in the wrong company.

1. https://en.wikipedia.org/wiki/BLUF_(communication)

2. https://www.sethgodin.com

This however happen exactly when communication is bad. When two people monopolize core, won't explain what they meant by what and effectively make it impossible to split work and effectively work for others. The army of maintainers suggests that original people just move on to new functionality having others fixed their bugs.

It works better when team has mechanism for knowledge sharing and core developers fix their own bugs.

Exactly this. Assume nobody knows anything and explain everything 500 times.

Also quick 5 minute call on Slack can save 4 hours to 4 days of sending emails. So prioritize fast issue solving rather than "process".

Imho key things are:

* Communication. * Biz + Technical PoV from devs. * Ownership / ability to make decisions.

Full remote is not for control freaks. It is for people who wants to get shit done. If you can't trust anyone you can't do remote.

1. Communication is key

Ability to talk and exchange info in processable way is king. This means no 5000 esseys. But not 1 line 4 word summaries. Communication should assume 0 knowledge on the reader but start with easily digestable summary / TLDR so person reading it can skip explanations he already knows.

Your english doesn't have to be perfect, but when you speak you can't sound like a broken acordeon. If your english is on level of ability to laugh from a pun you are good. Always learn and never assume your english is perfect.

2. Biz + Technical PoV from devs

Developers should know entire domain, how the app works in a biz sense. What is important. IF you are selling voice services and birthday card generator services from which cards generate 3% of income. Dev should be aware where the focus must be. This might be simple example, but this knowledge lets developer asses damage in dire situation and help prioritize things.

I know it might be shocking but sometimes developers can generate a good biz idea that will propel more profits.

Technical pov from devs. This is trivial and i assume every dev has technical pov but it might not be 100% true always. Simply to put it. This means understanding code in platform and setup / deployment. Sometimes developer can spot some easy optimization in other areas that just code. For example in the deployment sense.

3. Ownership

Teams / Developers have to have decent level of ownership. Possibly 100%. The decision-feedback-loop should be fast and simple. It doesn't mean devs call all shots but if they need to do something or get info it shouldn't take 3 weeks to get response.

All questions not answered are waste, all meetings about follow up to this questions are waste, all emails without answer or with bad answer are waste.

Imagine this situation:

Your team has 3 devs in 3 different countries. Lets call them D1,D2 and Dave. There is a product owner in 4 time zones behind him. Dave asks a question "how do we want handle service deletion?" he has to wait 4 hours to get the response, if product owner don't have to ask higher up. If PO has to ask up the response might be after 2 days. The response might be "in a good way" which prompts another set of questions. etc...

ofc Dave can ask the question like this:

"How do we want to handle service deletion ? Option A: just remove everything. Option B: marked it as deleted and keep in archive"

This might prompt Product owner response

"Adding in Steve from finance and Karolina from GDPR department. What do you guys think ?" ^- this solo can freaking prompt a week of delay because Karolina will respond "we must delete it" and Steve "i'm on holidays until March" etc....

Short feedback loops are ideal even if solution isn't ideal. It will be ideal most of the time. but the key is that a lot of this comms was just useless waste of time. And when PO involves multiple people and they start to disagree it is full scale setting up money on fire.

ofc Karolina is correct about GDPR handling but Steve might say "no no, we never delete" xD classic Steve.

It doesn't make sense as being cultural because there plenty of real examples of effective writing that starts with what you are writing about. The only exception might be in story telling, but that only works because there is some kind of context assumed or it works as a tool.

It makes no sense for this "culture" to think less of research or any writing that intends to persuade because it starts with a introduction or summary. Anyone who starts with a summary of what is going to follow will be a more effective communicator. They would be missing out on lots of writing that is done this way.

Your first paragraph or sentence will always be an introduction. If you choose to not take advantage of it to set the context of what follows the writing will be more confusing or require a second read through. Its like wandering through a forest vs following a trail map. At work, writing something that needs automatically needs a second read through is a problem.

I guess i have hard time believing this culture exists the way is presented, and isn't being misinterpreted.

> It is pretty easy to read email or argument without knowing the conclusion up front.

Its not, that was the point of the thread were commenting on

> Research papers are specific writing with specific rules. I dont really think they are in general example of good or persuasive writing.

This is one example, it has rules because those are effective at communicating. How can you just write it off like that? With no reason other then you think it doesn't count?

> If you’re a strong writer and you can consume information in written formats really well

Most comments here are focused on the "write well" part, which is important, no doubt.

But let's not forget the "read well" part. When people cannot read more than a paragraph without losing focus, or are confused by the used of precise technical terms (like stacks and queues, lists and sets...), the idea that you want to communicate will at best not pass, at worst been reshaped to something else.