4 ms·

I've had similar experiences working with people and my big takeaway is that communication is fraught with such little challenges. Best way I've found to avoid

I've had similar experiences working with people and my big takeaway is that communication is fraught with such little challenges. Best way I've found to avoid this is to leave as little to assumption as is reasonable to. A part of me thinks that some of the pitfalls in communication comes from culture, where different groups of people have different expectations of how much to leave to assumption, etc. Hard to really put it clearly, but I would love to read some research around this.

informalo 3y ago
https://news.ycombinator.com/item?id=37176703 https://news.ycombinator.com/item?id=37176703
- wsgeorge 3y ago
  Yup, pretty much this. Thank you!
saiya-jin 3y ago
Yeah but you can't be consistently fully mathematically correct with people around you, its often the parts you don't even realize have some room for mis-interpretation that tend to bite back hardest IMHO
morsch 3y ago
The problem with leaving little to assumption is that this tends to be verbose and people tend not to like to listen to long speeches and will simply not read long text. So, as everything in engineering, it's a tradeoff.
- IggleSniggle 3y ago
  My spouse gets frustrated with me for being too verbose in my requests, and also frustrated with me for following instructions in "the wrong way" when those requests were under-specified in the first place. Knowing "the right level" to communicate requests can be challenging in any relationship, even one with 20 years of shared experience to fall back on.
- trashtester 3y ago
  I micromanager will work around that by splitting the requirements up in tiny jira tasks that cannot be ignore easily, and then follow up daily on every single task. This completely kills initiative, tough, and may reduce the value added by each team member by 50% or more. The only time to use such tactics is with someone who is acting in very bad faith and at risk of being fired. It can be done for a while to establish an example, while rewarding better behavior with more autonomy gradually. If they still ignore the instructions, then that's proper grounds for firing them (even in Europe), and if they chose to leave because of it, well, that's ok too.
Cthulhu_ 3y ago
Yeah but then you write out a spec that costs you a ton of time, that won't be read, or won't be followed to the letter, and you'll be known as someone who obsesses over specifying things. If you spend that much effort communicating what's needed, you might as well just do it yourself. (I have no idea what your generalized statement is in relation to btw, so I could be talking out of my ass as well, lol)
NhanH 3y ago
The other pitfall of trying to clarify all assumptions is that your message then becomes too long. Then the reader actually will skim over the main points, which makes it worse. So yeah, it takes a lot of works to communicate efficiency, no matter the length of the end results
trashtester 3y ago
I have the opposite takeaway. If I experience that people follow my input too literally, I try to figure out which of the following three applies: 1) I've been micromanaging them too much, and they stopped thinking for themselves. Possibly partly because they were lazy, or annoyed or because they thought it was ok. 2) They don't have the ability to see that my instructions did not make sense in the situation they're in. Maybe they didn't have the training, self confidence or initiative to realize that the instructions were assuming a situation that was different from the actual one. 3) There is real bad faith involved. Most cases fall roughly under 1). In that case, the proper response is to reduce the level of micromanagement, and let the people figure more things out on their own. That means that even when I spot that they're making minor mistakes, I need to keep my mouth shut. People need to make mistakes sometime so they can learn from them. If they want to discuss those topics with me, I will try to treat them as peers not subordinates. While doing this I also try to make it clear that I expect independent thought. Then there are the cases that fall under 2). In those cases, I try to give tasks or instructions that are either intrinsically easier, or if that is not possible, I may break the tasks down to more manageable units, while trying to actively provide training and mentoring. The rarest case is 3) If this is the case, I will provide some push back. Luckily, as a tech lead, I don't have direct reports, so I can refer such cases to the line manager if it gets too bad.
- JohnClark1337 3y ago
  [dead]

informalo 3y ago

https://news.ycombinator.com/item?id=37176703 https://news.ycombinator.com/item?id=37176703

wsgeorge 3y ago
Yup, pretty much this. Thank you!

saiya-jin 3y ago

Yeah but you can't be consistently fully mathematically correct with people around you, its often the parts you don't even realize have some room for mis-interpretation that tend to bite back hardest IMHO

morsch 3y ago

The problem with leaving little to assumption is that this tends to be verbose and people tend not to like to listen to long speeches and will simply not read long text. So, as everything in engineering, it's a tradeoff.

IggleSniggle 3y ago
My spouse gets frustrated with me for being too verbose in my requests, and also frustrated with me for following instructions in "the wrong way" when those requests were under-specified in the first place. Knowing "the right level" to communicate requests can be challenging in any relationship, even one with 20 years of shared experience to fall back on.
trashtester 3y ago
I micromanager will work around that by splitting the requirements up in tiny jira tasks that cannot be ignore easily, and then follow up daily on every single task. This completely kills initiative, tough, and may reduce the value added by each team member by 50% or more. The only time to use such tactics is with someone who is acting in very bad faith and at risk of being fired. It can be done for a while to establish an example, while rewarding better behavior with more autonomy gradually. If they still ignore the instructions, then that's proper grounds for firing them (even in Europe), and if they chose to leave because of it, well, that's ok too.

Cthulhu_ 3y ago

Yeah but then you write out a spec that costs you a ton of time, that won't be read, or won't be followed to the letter, and you'll be known as someone who obsesses over specifying things. If you spend that much effort communicating what's needed, you might as well just do it yourself. (I have no idea what your generalized statement is in relation to btw, so I could be talking out of my ass as well, lol)

NhanH 3y ago

The other pitfall of trying to clarify all assumptions is that your message then becomes too long. Then the reader actually will skim over the main points, which makes it worse. So yeah, it takes a lot of works to communicate efficiency, no matter the length of the end results

trashtester 3y ago

I have the opposite takeaway. If I experience that people follow my input too literally, I try to figure out which of the following three applies: 1) I've been micromanaging them too much, and they stopped thinking for themselves. Possibly partly because they were lazy, or annoyed or because they thought it was ok. 2) They don't have the ability to see that my instructions did not make sense in the situation they're in. Maybe they didn't have the training, self confidence or initiative to realize that the instructions were assuming a situation that was different from the actual one. 3) There is real bad faith involved. Most cases fall roughly under 1). In that case, the proper response is to reduce the level of micromanagement, and let the people figure more things out on their own. That means that even when I spot that they're making minor mistakes, I need to keep my mouth shut. People need to make mistakes sometime so they can learn from them. If they want to discuss those topics with me, I will try to treat them as peers not subordinates. While doing this I also try to make it clear that I expect independent thought. Then there are the cases that fall under 2). In those cases, I try to give tasks or instructions that are either intrinsically easier, or if that is not possible, I may break the tasks down to more manageable units, while trying to actively provide training and mentoring. The rarest case is 3) If this is the case, I will provide some push back. Luckily, as a tech lead, I don't have direct reports, so I can refer such cases to the line manager if it gets too bad.

JohnClark1337 3y ago
[dead]