As a manager, you can probably get away with this.

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.

I've found it useful to distinguish between the times I'm asking for something, and the times I'm documenting something.

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).

One of the hidden assumptions in "hire people that write well" is that people who write well would also likely have high reading comprehension skills. Or, the inverse—I find that the ones who want to jump on a quick call vs. writing out their request are the same people who seemingly don't read the documents I produce.

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.

Different people have different communications styles, and resolving that is always tough. But there are definitely those who communicate poorly in any medium -- and I find that often they're the ones who like media where they don't leave a trail that can be pinned on them.

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.

> 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).

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!"

Put your ask at the top, don't be afraid to use bullet points, keep things short and sweet. Most things can be effectively communicated in 2 or 3 paragraphs - if you need to communicate more than this, send it in a follow-up email after they respond. If you need to communicate more than this, you should really set up a quick call to communicate the thing and ensure they understand, then send the long email afterward.

Using checkboxes in GitHub issues is my secret weapon. There is no way to mark an issue as done or glaze over the details that way. Checklists in general are a great thing. I wish there was a startup that made community sourced checklists for common tasks like opening up a PR or writing an email asking for a raise.

Checklists also save lives!

> 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...

on the flip side of this, there’s those of us who hate the superfluous (opinion) processes that seem only to slow down, not speed up.

PRs don’t need checklists IMO. If they do maybe your team is too large.

I think a little checklist would help me remember things that are easy to forget, like updating documentation or making sure that a test exists to reproduce the issue. That said, at the end of the day tools exist to help us, not slow us down. If they is a small PR that fixes a typo then I want to be trusted to skip the checklist completely.

Have you tried putting each important sentence on it's own paragraph? Just the important ones.

That makes a difference in focus/readability.

Try it.

Take this too far and you end up writing broetry.

After enough years in a corporate setting I can guarantee that this has the opposite effect, because it makes it even less likely for your email to fit on a screen so it just gets skipped.

Many of the suggestions I'm seeing are the polar opposite of how this thread started.

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.

If an email is too long, then some will just ignore it. So overcommunicating can lead to people ignoring your essays for a simple point. Then there’s the time aspect. With everybody overcommunicating how will work get done with everybody overcommunicating to discuss a bug? Some of the most productive teams I’ve been around and on barely needed any communication outside of quick alignment meetings. Seems this is very opinionated, rather than fact.

As an IC you probably have more time to fully read emails, esp. those from your management chain.

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.

> As an IC you probably have more time to fully read emails, esp. those from your management chain.

I’m sorry, an IC having time?

You're totally right that you have to know your audience and cater to it. Technical writing still requires it.

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.

> 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).

Wiio's laws are always relevant: https://en.wikipedia.org/wiki/Wiio%27s_laws

The main thesis being "Communication usually fails, except by accident".

It’s a bit like sending events to an unknown state machine.

You need add enough context for the event to be processed but you can’t know what will happen when it is...

>people rarely read my emails if it doesn't fit in their screen

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.

The One Palm Rule. I know a few people that promote this :) If it's larger then your palm, when you streach a hand towards screen, you are not obliged to read it.

Suprisingly effective, especially if you are open about it. Of course it applies only for those with 1000 unread (after filters).

I can't fit your comment with my palm on my current monitor.

(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.

You are holding your palm flat towards screen, right? :)

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.

I was working a pretty big screen at the time.

You are right, of course, though this may seem to conflict with my original comment. One way to reduce email size is to put context information into reference documentation. (Or other substitutes, like Github issues, JIRA, design docs, requirements, operational run books, etc.)

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.

Be mindful of how Outlook displays messages. Subject should be the topic, and the first line should be the ask. That way busy people see everything they need in the preview, without ever opening the email.

Have you considered refactoring info into wiki webpages and hyperlinking between them? Then your email can link to that.

> As an IC, people rarely read my emails if it doesn't fit in their screen (so 3 paragraphs is the max).

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.

This echoes OPs point about culture. One absolutely should not do what you've mentioned in my location. Here we lay out the arguments, and the conclusion at the end. The reverse is seen as jumping the gun, and not being well reasoned. It is looked down upon, and frequently discounted immediately.

Cultural bias is very much a thing.

> One absolutely should not do what you've mentioned in my location. Here we lay out the arguments, and the conclusion at the end. The reverse is seen as jumping the gun, and not being well reasoned. It is looked down upon, and frequently discounted immediately.

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"?

Theory: If people read conclusion first, then people tend to evaluate whether they agree or not after reading conclusion. Emotional reaction toward conclusion will bias interpretation of arguments.

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.

While the solution may be valuable, there's more value in reading the work to get there. Rarely is the value a decision, inasmuch as the path to the decision. By first declaring a solution to a problem, you're priming the other individual. Depending on their personality you're priming them to be for, or against your decision.

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.

I have experience at several companies with many different cultures, and I don't know of anyone who likes to slog through the details before getting to what the final problem or solution is. People just don't have time for that. Putting the important part first serves the dual purpose of quickly informing people who aren't interested in the details, and telling them up front why they might care about reading the details.

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.

How is that cultural? Even through elementary school we were taught to have an intro with what your point is, follow up with supporting arguments, then conclude by reiterating the point the you made.

How could you read anything without knowing the point in the beginning. Even research papers start off with an abstract.

The fact that you was taught that in elementary school and thus literally concluded that it is impossible to read something without knowing conclusion first is what makes it cultural. The fact that he and everyone around him sees conclusion up front as jumping the gun and likely was taught that structure in school, is what makes it cultural.

> 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 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?

> 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.

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.

Bluf seems to be a specific thing, no one mentioned that in the thread I'm commenting on.

The post that I responded to suggested having an intro with a summary of what's to follow is offensive

> 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.

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.

Can you show me something written that doesn't have an introduction that includes a summary of what's to come

You could still totally just read the ending first if it's that big of a deal for you.

This approach depends very much on culture. For example, US culture is very much, get to the point, start with the conclusion. German culture requires you to outline how you got to the conclusion.

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.

German culture requires no introduction in any writing? Am I talking about the same thing as everyone else commenting?

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?

Looks like i wasn't very clear.

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.

That's a really interesting counter-example to what I've learned as the best way to write.

Can I ask what culture you're referring to?

We called this BLUF: Bottom line up front.

pick up the phone

Please write a collaborative doc instead of an email if you have that much detail. Having an effective discussion over email is actively painful and worse yet no one can refer back to your detailed documentation later.

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.

Email is the worst but a close contender are Slack messages and threads .... Confluence is somewhat better but comments are not handled well with respect to the source document. Add in Smart sheet and the rest as kludges and I have 10 different things to check for a single project with dependencies.. it's nuts. I am not sure if anyone has really figured the information based workflow out yet. There needs to be some auto association and project based aggregation (maybe tags?) .. that and a personal workspace of things you need to do in each system.. right now everything is asynchronously propagated by slack or email.

I am interested in trying out Asana and Facebook Workplace to see if they have solved this in a more natural way.

The other thing working remote forces me to do is to actually think before I assign a task to someone or ask a question.

It's a lot easier to casually interrupt someone with half a thought than to write a poorly thought out email.

Wow, that’s pretty interesting. In real life, I might blurt out a comment or question, but when I find myself doing the same even with a long slack message — by the time I write two or three sentences, and maybe go back to reword something, I’ve already started thinking about how I can solve the problem myself, and I cancel the message.

This is my general take on "remote doesn't work for X": Did your existing process actually work, or did you use the ability to interrupt people as a crutch in order to make it not totally fail?

That is also the main advantage of email over IM. Email kind of forces some effect of the remoteness you described even when everyone is in the same office.

On the other hand, in a colocated workspace it is infuriating when a high effort, carefully crafted email is met by recipients interrupting you at your desk with, "Hey, about that email, can you just quickly run through it with me now please?"

One of the rules I tried to enforce on a prior team was to minimize context conversation medium changes. Following a conversation as it freely moves from email to chat to in person is exhausting.

You're using IM wrong :)

You don't have to read the message when it arrives just because it instantly arrived.

Sometimes it’s my colleagues that are using IM wrong.

> 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.

Ignore it until they ask the question. Eventually they'll learn.

> The key to success is overcommunicating.

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.

As a corollary, if your org is dependent on email for communication, you likely have some inefficiency and room for improvement.

In all seriousness, please enlighten me. Email isn't the best, but the other options are equally or more shit:

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.

Quote: "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.)

No, I'm saying that management keeps changing internal documentation/comms strategy, and that without a central index to search, it's impossible to know where things are, or what's even going on.

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.

I strongly relate to your comment! I was recently brought into a project where my company was working with a vendor to use their platform to reduce tedious work. Only by repeatedly emailing the vendor specific questions was I able to discover that the internal team had made some significant incorrect assumptions about what the vendor's product does.

To prevent dozens of wasted work hours, we can't be afraid to ask specific questions, even if they might make us look dumb!

With some of my clients, I go even further. Where possible, I figure out what the possible answers to my question might be and write them in a concise numbered list (with a “something else” option at the end”). Ideally, the response is a number with a little context. At the very least, it prompts a response that challenges my assumptions, which is useful too.

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.

In marketing world a common way of ensuring good communication is the client will write a brief of what they want, then the agency will reply with a 'response to brief'. Here they basically write the same thing in their words back to you.

It helps on several levels to ensure understanding is aligned vs emailing back 'I got it' and off to work.

I've also worked remotely for 15+ years. I constantly ask dumb questions. It's amazing how much comes out of the woodwork doing that. Doesn't seem to have hurt career progression either.

But, when it's that long, do people read it? It seems like a great CYB tactic, but maybe a poor communication tactic. I'm a voracious reader, but when it comes to most corporate communication I won't really read anything over a paragraph long. I might skim it if it is from my manager. Maybe.

Title. Abstract. Details.

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.

If everyone in a corporation is unwilling to read more than a paragraph of a colleague's thoughts, it's amazing anything of any remote complexity is able to be produced by collaborative software organizations. Unless it's one guy in a corner, talking to nobody.

> it's amazing anything of any remote complexity is able to be produced by collaborative software organizations. Unless it's one guy in a corner, talking to nobody.

Honestly, I have seen this happen so many times that I rather suspect it is fairly common.

Agree. It's usually one or two people building all core features and then an army of so-so skilled maintainers.

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.

It's hard to have more than 2 developers working on the core of something. Development is a very non-concurrent activity.

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.

People read if it’s written well. Don’t make it long to be long, make it long because it needs to be long.

My favorite feedback is when someone replies to a 1000+ word newsletter with “Wow, short and to the point! Thanks”.

> People read if it’s written well.

This is bordering on the No True Scotsman fallacy.

It's a lot harder to write something short and concise that efficiently communicates to team members than something long and wordy that requires a lot of reading.

"I didn’t have time to write a short letter, so I wrote a long one instead."

I work on distributed teams that are spread across 10 to 12 time zones. We depend on people making local decisions that are approximately right, because confirming a decision may mean a 24 to 48 hour cycle of back and forth communications.

In these situations it's more important to share "what is the problem" than how to solve it.

I managed a team for 25 years at a Japanese corporation. We had team members in many different timezones, and scheduling videoconferences was always a fraught process.

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.

One thing I often do is split an email into two parts, I'll even label them.

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.

I've started using an equivalent pattern and my implementation has generally been a success, so I'll share:

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.

I have started to question the value of sign-off text. It seems that is just wastes screen space. The only time it would be useful is when you are emailing someone who might not know who you are. What value do you see in it?

It's a signal that you're in the "in" group of the cultural norms, like shaking hands or the superfluous "Hi" in text chats. The value is social signaling and emotional, not informational.

Good on you for thinking about the user experience of the person receiving the communication. It's a skill to know how to do this well. It requires practice and effort that many people don't bother with – because of a lack empathy, they're too busy, or they realize the recipient(s) won't recognize (or even read) the results.

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.

Communication is a weak point in the entire software industry. It permeates everything from emails to variable names. I wonder if it's the same in other industries.

The issue people fail to realize is that language is quite lossy in terms of information. The way you make up for that to clarify ambiguity is through verbosity.

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.

That is only working if you are the only one doing this. If everybody in the team starts repeating everything very detailed, this soon becomes completely unproductive and ignored. Think one information mail from one system might be a good idea, but when you start getting 1000 automated mails every day like I get right now you are actually not informed at all.

The key to success is focusing on a small number of messages that you really want to get to people and then overcommunicating them.

Some teams focus on communicating as much as possible and I as a developer am in favor of this, since it makes my job easier.

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.

A good maxim from safety critical industry: patronised is better than dead.

> Come to think of it, remote work is not that different.

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.

That is good if you are working in a team that is comfortable reading and writing a lot of English, and cares about what you're writing.

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).

While I agree that the key to success is _a lot_ of communication, there is much more to the management of remote teams than that: you should treat them like the on-site teams; communicate a lot but prefer video conferencing; try to give your remote teams the overall context; stick to as few means of communication as possible (if it's email, then stick to email).

The key to success doesn't have much to do with communicating. Recognizing people respond to different behavior in different ways will be much more productive. I for example, rarely spend more than a few seconds reading an email so if you have a point to make it better be in a succinct mini paragraph.

I believe that you should be fired for that.

We need to explicitly communicate Requirements + Expectations

Nobody seems to read long emails.

In a properly collaborative environment, work is performative. When the work is not face to face, this is doubly true.

Looks like a wiki would help

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.

>This means no 5000 esseys.

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...

TL;DR ;)

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.