In other words--don't assume people have full context or share assumptions. Write emails that lay out assumptions explicitly and detail problems completely. As a manager I sometimes feel like a Habsburg bureaucrat buried in the Chancery offices sending painstaking messages to a far flung empire. Come to think of it, remote work is not that different.
As an IC, people rarely read my emails if it doesn't fit in their screen (so 3 paragraphs is the max).
The only thing I've found that works is to send details, and then probe the recipient on each important item in there to make sure they understood what I wrote. If I'm too detailed, they will get lost. If I'm very concise (but still complete), they'll misinterpret.
Getting people to reflect back to you what they understood is encouraged in most communications books. You can write the perfect email, and it will still get misunderstood.
Edit:
It is amusing that people are responding giving me writing advice. Equally amusing is the implicit tone in some of the comments that I'm doing it wrong and implying I don't follow what they are suggesting - especially when I didn't even discuss how I write my emails!
As I said: You can write the perfect email, and there will always be someone who will misinterpret it. The problem is not merely in the content, but in the other (including their worldview, culture, social status, etc). The solution isn't to try to become a more perfect writer, but to understand the dynamics involved in communication (written or verbal).
To paraphrase one of the books: People will interpret what you say based on their worldview - something that you often do not have access to. It's their worldview that will often make them misinterpret something that is very clear and unambiguous in what you say. Accept that reality and work around it.
That makes a difference in focus/readability.
Try it.
When you're remote you miss a lot of context. Overcommunicating in writing helps address that. Eliminating information or not expecting people to fully read and engage with what they read is going in the wrong direction of the fundamental problem.
> But a year after surgical teams at eight hospitals adopted a 19-item checklist, the average patient death rate fell more than 40 percent and the rate of complications fell by about a third, the researchers reported.
https://web.archive.org/web/20151103232100/http://www.nytime...
PRs don’t need checklists IMO. If they do maybe your team is too large.
When asking a question, lead with the question, and put only the bits you need to clarify your question underneath. For these communications, the shorter you can make it, the better.
When writing documentation, you're writing for the future, and should aim for completeness rather than full comprehension immediately -- you want something people can look back at later when they're not clear on something, rather than something that your reader will read in one sitting and remember flawlessly. Your reader isn't going to be able to retain that much stuff.
If you absolutely need your reader to understand some points, I recommend keeping the points as short as possible, and also to your point, asking a question that requires them to have understood what you wrote (e.g. "people who signed up before this date will be grandfathered in, so may see different rates than new customers. Are you aware of any marketing material which might give conflicting information? " -- the answer is probably "no", but in the course of answering that question, they had to understand what you were saying, and as a bonus if the answer is "yes" you've avoided a problem before it happened).
You need to learn how to restructure your writing. Most logical people naturally write in a way where it’s premise, premise, premise, conclusion. Instead, you need to write conclusion, premise, premise, premise.
One way I’ve found to help my team learn to write this way is to institute a rule that any writing longer than 3 paragraphs has to have a TL;DR at the top that is no more than 3 sentences. This gets people over the hump of putting the big ask up front and then after a few weeks, they start naturally writing that way.
Cultural bias is very much a thing.
How could you read anything without knowing the point in the beginning. Even research papers start off with an abstract.
> How could you read anything without knowing the point in the beginning. Even research papers start off with an abstract.
It is pretty easy to read email or argument without knowing the conclusion up front. You just read on. Research papers are specific writing with specific rules. I dont really think they are in general example of good or persuasive writing.
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?
That argument does not make sense.
> 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.
And it does not make sense for you to look down at writing that puts conclusion to the end going with arguments first. It is just an habit and meaningless difference, that is all.
> 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?
Researchers and their papers are not effective at communicating. That a thing that researches complain about periodically.
In any case, corporate mail is not research paper. Among other things, it is supposed to be significantly shorter. Just like it is not newspaper article.
This is a non-argument. In the US, writing is considered effective if you put the bottom line up front. GP wrote that BLUFfing is considered offensive in their culture. Now you respond that lots of people like BLUFfing.
Now you say it's not culture-dependent but a universal truth that BLUF is better.
Well, other cultures disagree.
The post that I responded to suggested having an intro with a summary of what's to follow is offensive
Interesting book on this topic: The culture map, by Erin Meyer. (https://www.amazon.com/Culture-Map-INTL-ED-Decoding/dp/16103...)
It has a whole chapter on this topic: 3 - Why versus How, the art of persuasion in the multicultural world.
Anything you write will always have a first sentence or paragraph. Your saying it's offensive to use that to give an overview of what's to come and to set the tone of the writing?
The difference according to the book is that if you want to convice an audience of something, e.g, result of a study, americans are more interested in the results and how to apply it. Germans want to understand how you got to the results, what the process was behind it so they can understand that your results are correct.
I would like to understand why the reverse is "jumping the gun". I am assuming the arguments have not changed, the reasoning remains the same. Why is a mere change of order "jumping the gun"?
The remaining arguments are more likely to be accepted or rejected based on what you know conclusion is. So instead of asking "is this true", people will start either with "I am looking for nitpick cause I see this is going toward bad conclusion" or with "yeah sure, it shows what I think".
However, they will still feel like they evaluated arguments on merit. If the conclusion is last, people can and some will go back to arguments to bias them, but it is easier to see what they are doing.
By articulating the reasons, methods, and considerations that went into a decision, you're slowly and softly building an argument. Individuals are less likely to have an instinctive reaction to something this way. At the very least, it's proven (yes, as in measured) to be the case here.
It's like having an abstract or a blurb to briefly summarize for management.
Similarly, if you need someone to take action based on the result, you don't put it at the end where nobody's going to read it. You put it at the beginning, first thing, and then build up the background.
Can I ask what culture you're referring to?
I think this is the case unless the problem is very relevant to what you are working on at the moment. Normally what I would do, if I were writing an email to explain a problem, is create that explanation in depth on a wiki or other knowledge repository somewhere. Write the email referencing the url of this wiki, and explain the main points in the email.
This is as a general rule if I am explaining something important for tech team to know, if I am explaining something that is important for product owner to know I write it in as verbose an email as is required to explain everything. That's up to the product owner to follow. Generally after receiving an email like this they will want a meeting where I can explain in person and draw stuff on the whiteboard.
Wiio's laws are always relevant: https://en.wikipedia.org/wiki/Wiio%27s_laws
The main thesis being "Communication usually fails, except by accident".
You need add enough context for the event to be processed but you can’t know what will happen when it is...
Suprisingly effective, especially if you are open about it. Of course it applies only for those with 1000 unread (after filters).
(But I read it anyway.)
I guess the effect of following this rule depends a lot on formatting, size of hands and monitor and how long your arms are and how far away you are standing.
It's one of those things you apply only when it suits you, and ignore when it doesn't work to your benefit.
Jokes aside: I wrote this because it's both sad and interesting how people cope with huge amounts of communication that waits for their action.
What changed my perspective though is the book "Comedy Writing Secrets". It's a very different topic, but the general aspects of writing fun an engaging texts translate quite well.
One example I've seen it done brilliantly is the re-frame docs https://day8.github.io/re-frame/re-frame/ - I often point it to people as an example of technical writing so good, that its fun to read just for the sheer pleasure of it, regardless of whether one writes Clojure or not.
_why's (Poignant) Guide to Ruby is also a famous example of this.
Without a doubt the first sentence is true. Successful written communication requires properly encoding the information (writing) and properly decoding it (reading). A flawed reading of an email means communication breaks down independent of the quality of the writing.
The second is also true, but incomplete. In many cases, there is a failure to read (either because of laziness or "I already know what he's going to say") or a language issue - even for native English speakers. It's not at all uncommon for someone to miss a "not", think "and" rather than "or", interpret "weeks" as "days" and so on.
Edit: One story that comes to mind is related to a policy our department was implementing a number of years ago. I sent an email with what I thought was minor supporting information. I got an angry reply of six paragraphs, totally irate that I would suggest something so crazy, listing all the ways I was wrong. I responded to say "I think you read my first sentence wrong." The response: "Oops!"
Quickly reading and understanding almost everything I can find—code, plans, schedules, calendars, strategy, memos—is how I excel in remote environments. It's not a huge time commitment, 20 minutes a day, but I have the organization's "state" modeled in my head, which helps me identify dependencies and potential bottlenecks before they're surprises.
There are are advantages to the "quick call", and some people definitely work better that way. But I much prefer written communication: not only do I get to refer back to it, but it's more asynchronous, freeing me up considerably.
"Let's talk" often seems like a barbarous imposition on my time, that I have to hear it right now and make any decisions while you're staring at me. I try to keep in mind that they just have a different communications style, but that's not always easy.
One thing that may not work very well is depending on Slack channels or other chat systems for context. It's fine for an on-going issue but does not work for general information. Important topics are just too hard to find later.
I like to lay out the decisions I'm going to make if I don't get feedback, if possible. That seems to prompt feedback when feedback is required -- it seems the human desire to fix mistakes is stronger then it is to answer open ended questions. It likely gives the reader some context as to why you need the information as well.
I’m sorry, an IC having time?
Good on you for communicating. Personally I've found that details are great, but being able to distill that core message down to a quick code really helps. Call it an elevator pitch, sound bite or whatever but it is really transformative. So much communication seems to be just passing along a historically linear repeat of facts rather than helping reader by distilling down.
I am interested in trying out Asana and Facebook Workplace to see if they have solved this in a more natural way.
It's a lot easier to casually interrupt someone with half a thought than to write a poorly thought out email.
You don't have to read the message when it arrives just because it instantly arrived.
> Hey I have a question
People are too lazy to type the rest of their request until they see a response from me indicating I’m listening.
No, "overcommunicating", by definition, means giving more information than what is needed.
There are times and places where overcommunicating works, but email is almost never one of them. You simply can't get away with more than a few sentences in an email unless the recipients are specifically expecting that from you.
When "an essay" lands in someone's inbox unexpectedly, at best, you can expect recipients to skim it for whatever concerns them directly. If you have critical points or conditions embedded in a paragraph in the middle, those are probably going fly past the recipients' attention completely unnoticed.
Slack, which has nonfunctional search and is miserable to navigate?
Github readmes?
Atlassian's wiki, which has even more broken search, and follows management's whims?
Google docs, which vary widely in format, is not easily searchable, and has no index?
Team documentation, which follows managements whims, gets moved around, deprecated and eventually stowed in unused lavatories?
Internal stackoverflow, which is piloted and then slowly abandoned after an intial big push my managers, who get promoted and then leave the company?
Facebook workplace, which suffers a similar fate to stackoverflow?
The problem is there is no global index or search- think Sourcegraph, and management keeps changing products/documentation/comms strategy every 6 months.
Are you saying that Sourcegraph's management keeps changing products/documentation/comms strategy every 6 months? (Just not sure how to parse this sentence.)
A tool like Sourcegraph but for finding documentation could be useful, but it doesn't show you the amount of "dead" documentation that's floating out there, or give you a way to browse everything.
To prevent dozens of wasted work hours, we can't be afraid to ask specific questions, even if they might make us look dumb!
It helps on several levels to ensure understanding is aligned vs emailing back 'I got it' and off to work.
I started doing this because I received so many short and incomprehensible or long and incomprehensible responses that rarely included the information I asked for.
Most people will skim the title. Some will read the abstract. Few will read a specific paragraph or two of details. Yet, the writer doesn't know who's going to read what. Could be the writer himself, 6 months down the line. Often times those details are pure gold.
Honestly, I have seen this happen so many times that I rather suspect it is fairly common.
It works better when team has mechanism for knowledge sharing and core developers fix their own bugs.
Speaking from experience, when there's multiple people trying to take over the same bit, they only create conflicting changes all over the place and deadlock the project. It's worse than if no work was not done. Now somebody needs to take the lead and remerge things manually and discard what cannot be merged.
Regarding maintenance, the later army of maintainers is typically a bunch of contractors mostly sitting idle billing for time. The size of the maintenance team has little correlation to the workload.
My favorite feedback is when someone replies to a 1000+ word newsletter with “Wow, short and to the point! Thanks”.
This is bordering on the No True Scotsman fallacy.
In these situations it's more important to share "what is the problem" than how to solve it.
I write a lot. In fact “prolix” is not a bad word to use for my writing.
The biggest complaints I received were always about the lengths of my missives.
This was a legitimate complaint. It took a long time for people to translate my messages, and to translate the responses.
I learned to write emails with every sentence as a separate line, a clear abstract, and a clear conclusion/question.
Bullets were important, as was careful wording. Fifty-cent words were OK, as long as they were accurate and relevant, but jargon was harmful.
High Level Summary: 1-3 sentences that cover the main ideas, kind of an executive summary.
Details: the nitty gritty, full context, screenshots, etc.
People seem to really like this, each reader has the option to dive as deep as they need/want.
Edit: In my experience, a lot of people can't even bother to think of an appropriate subject line that summarizes the content effectively. "URGENT: please read" is the worst offender.
My email body has everything the "optimal" reader (i.e., someone who is already familiar with the topic item) needs to |action_verb| regarding what I've written.
Then I "conclude" with my usual sign-off (e.g., Cheers, [CRLF] "/Aceyman").
BELOW that—but above my default signature/contact info block—I place all the deeper-dive / expository / rationalization narrative which provides that level of detail for anyone who needs more than my main body provides.
I've been using this pattern for about a year or so with good results.
/Acey
At the start of the supplementary section—and depending on the topic & audience—I'll sometimes use the 'section title' Extra-credit reading, because everyone loves a chance for some extra-credit, right? That's my little psych ploy to entice readers to take a look at the nominally 'optional' expository stuff.
If you can't read and write long emails (or voice/video chat), you're going to have miscommunication. Experience and knowledge can only be used so far to interpolate and extrapolate. No matter how skilled you are at this, clarification will be needed in some form or another.
In cases where whoever you're working with doesn't know exactly what they want and give you what is essentially artistic liberty to fill those voids, you can reduce communication some but be warned, you may create the wrong thing and have to double back or worse, you may find out much later when its not viable to fix something was off.
I'm a fan of long emails or conversations to be certain I understand what's needed.
The key to success is focusing on a small number of messages that you really want to get to people and then overcommunicating them.
On the other hand some teams, usually startups that move too fast and can't communicate everything, stress the importance of independence.
Both are needed, when you can say as much as you can, I am totally for overcommunication. Sometimes unexpected things happen, or there is just not enough time for proper communications, so a proper judgement is needed.
I've spent the majority of my career at large companies with multiple offices. My experience is that non-remote work is no different unless everyone in the company is in the same building. Even then, if different functions or teams are sufficiently siloed it still requires that level of over-communication.
If those things aren't true, "overtransmitting" (because you are not in fact communicating) will just lead to unread email, incomprehension, sidelining and getting ignored. That goes double if what you're trying to do is already against the corporate culture (in the conventions and accepted quality level sense).
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.
One tip for communicating at work: keep your message brief and concise. Add too many details and your mail won't be read or just half of it.
I generally tell people looking for my advice, engineering is a reading job. Until humanity figures out how to transfer ideas with something other than characters, you're going to have to read. A lot.
For example, one quick tip I give is just read the entirety of anything you encounter. The whole error message + stack trace. The whole document (page) about the package that contains the function you're after... the whole type and its functions.
It's also how I often mark people a "No" for interview -- when they obviously are not reading the error (with line number!) of their non-compiling code...