11 ms·

I've been working on remote teams for almost 20 years. The key to success is overcommunicating. In other words--don't assume people have full context or share

I've been working on remote teams for almost 20 years. The key to success is overcommunicating. 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.

karlhughes 6y ago
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.
- ketzo 6y ago
  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.
- trhway 6y ago
  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.
  - mrslave 6y ago
    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?"
    - ashtonkem 6y ago
      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.
  - nottorp 6y ago
    You're using IM wrong :) You don't have to read the message when it arrives just because it instantly arrived.
    - alach11 6y ago
      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.
      - nottorp 6y ago
        Ignore it until they ask the question. Eventually they'll learn.
- ashtonkem 6y ago
  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?
alach11 6y ago
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!
- Gustomaximus 6y ago
  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.
- rorykoehler 6y ago
  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.
- Veen 6y ago
  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.
deleted 6y ago
[deleted]
irrational 6y ago
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.
- alquemist 6y ago
  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.
- JMTQp8lwXL 6y ago
  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.
  - irrational 6y ago
    > 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.
    - fxtentacle 6y ago
      Agree. It's usually one or two people building all core features and then an army of so-so skilled maintainers.
      - watwut 6y ago
        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.
BeetleB 6y ago
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.
- fn1 6y ago
  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.
  - zten 6y ago
    Take this too far and you end up writing broetry.
  - alxlaz 6y ago
    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.
hinkley 6y ago
In a properly collaborative environment, work is performative. When the work is not face to face, this is doubly true.
chuckcode 6y ago
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.
- sjg007 6y ago
  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.
jakuboboza 6y ago
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.
outsomnia 6y ago
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).
BenGosub 6y ago
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.
ChrisMarshallNY 6y ago
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.
yodelshady 6y ago
A good maxim from safety critical industry: patronised is better than dead.
_pmf_ 6y ago
Nobody seems to read long emails.
Frost1x 6y ago
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.
Consultant32452 6y ago
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.
- Nagyman 6y ago
  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.
  - Consultant32452 6y ago
    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.
- AceyMan 6y ago
  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.
cblconfederate 6y ago
Looks like a wiki would help
lmilcin 6y ago
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.
known 6y ago
We need to explicitly communicate Requirements + Expectations
vonmoltke 6y ago
> 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.
crispyambulance 6y ago
> 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.
- _greim_ 6y ago
  As a corollary, if your org is dependent on email for communication, you likely have some inefficiency and room for improvement.
  - medium_burrito 6y ago
    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.
    - sqs 6y ago
      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.)
mrits 6y ago
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.
- ilaksh 6y ago
  I believe that you should be fired for that.
valcker 6y ago
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).

karlhughes 6y ago

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.

ketzo 6y ago
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.
trhway 6y ago
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.
- mrslave 6y ago
  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?"
  - ashtonkem 6y ago
    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.
- nottorp 6y ago
  You're using IM wrong :) You don't have to read the message when it arrives just because it instantly arrived.
  - alach11 6y ago
    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.
    - nottorp 6y ago
      Ignore it until they ask the question. Eventually they'll learn.
ashtonkem 6y ago
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?

alach11 6y ago

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!

Gustomaximus 6y ago
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.
rorykoehler 6y ago
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.
Veen 6y ago
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.

deleted 6y ago

[deleted]

irrational 6y ago

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.

alquemist 6y ago
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.
JMTQp8lwXL 6y ago
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.
- irrational 6y ago
  > 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.
  - fxtentacle 6y ago
    Agree. It's usually one or two people building all core features and then an army of so-so skilled maintainers.
    - watwut 6y ago
      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.

BeetleB 6y ago

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.

fn1 6y ago
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.
- zten 6y ago
  Take this too far and you end up writing broetry.
- alxlaz 6y ago
  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.

hinkley 6y ago

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

chuckcode 6y ago

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.

sjg007 6y ago
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.

jakuboboza 6y ago

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.

outsomnia 6y ago

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

BenGosub 6y ago

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.

ChrisMarshallNY 6y ago

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.

yodelshady 6y ago

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

_pmf_ 6y ago

Nobody seems to read long emails.

Frost1x 6y ago

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.

Consultant32452 6y ago

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.

Nagyman 6y ago
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.
- Consultant32452 6y ago
  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.
AceyMan 6y ago
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.

cblconfederate 6y ago

Looks like a wiki would help

lmilcin 6y ago

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.

known 6y ago

We need to explicitly communicate Requirements + Expectations

vonmoltke 6y ago

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

crispyambulance 6y ago

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

_greim_ 6y ago
As a corollary, if your org is dependent on email for communication, you likely have some inefficiency and room for improvement.
- medium_burrito 6y ago
  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.
  - sqs 6y ago
    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.)

mrits 6y ago

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.

ilaksh 6y ago
I believe that you should be fired for that.

valcker 6y ago

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