[HN Gopher] Written communication is remote work super power
___________________________________________________________________
Written communication is remote work super power
Author : snird
Score : 340 points
Date : 2020-06-19 18:08 UTC (4 hours ago)
(HTM) web link (snir.dev)
(TXT) w3m dump (snir.dev)
| joe8756438 wrote:
| I also find keeping a log of work helps provide the right
| communication at the right time. Especially when remote I find it
| is easy to forget all the things I've worked on in a given week.
| It doesn't always make sense to interrupt somebody with updates
| on something the moment it is done. Colocation provides so many
| more cues to communicate progress, ideas, etc. in the collocation
| context the work log is less important as a communication tool.
|
| It so happens, (shameless plug alert) I built a tool [0] that
| asks me what I did on a daily basis via sms, the responses are
| organized in my work notes folder. I use this for keeping track
| of long-running projects that depend on lots of other people for
| input. I also use it to build a monthly description of work to
| include with my clients' invoices.
|
| 0. https://www.tatatap.com
| rogerkirkness wrote:
| Fundamentally, it's faster to write and type than it is to talk
| and listen.
| nine_k wrote:
| It hugely depends on one's competence in writing, and one's
| style of thinking.
| tomplayford wrote:
| I personally find it much faster to talk and / or draw than to
| write or type.
| devxpy wrote:
| Written communication will also give you RSI though
| watwut wrote:
| We found it faster to call and speak
| tomplayford wrote:
| Not everyone finds written comms as easy as everyone else.
|
| absolutely +1 to keeping records, but as a form of communication
| it's not terribly equal.
| Benjammer wrote:
| I don't know how to phrase this without sounding like a
| somewhat pedantic asshole, but I cannot understand this
| reasoning. Are we really saying there is less variability in
| people's spoken communication abilities than written? This
| concept is _baffling_ to me. Who in the world talks better than
| they write?
|
| Also, in my experience, written comms is immensely more
| accessible and accommodating to diverse teams with people who
| may have variable levels of expertise with English.
| tomplayford wrote:
| I was referring to dyslexia. About 5-15% of the US population
| have some form of dyslexia. Probably should have spelled that
| out.
|
| I do agree that for non native english speakers, the written
| word is more accessible.
| Benjammer wrote:
| I worked with a guy who was legally blind, but could
| function with a physical screen overlay device that
| magnified things up to pretty absurd proportions. He was
| one of the better communicators (in writing) in the entire
| engineering org. I think we should work on individual cases
| to make writing more accessible to people for whom it's a
| struggle. But we shouldn't just throw out writing and it's
| overall effectiveness. That's not a solution, it's avoiding
| a hard problem.
|
| We don't just decide to only build one story buildings
| because of physical accessibility, because we don't want to
| throw out the efficiencies of multi-story structures.
| Instead we install ramps, automatic doors, elevators, etc.
| And we have legal standards for door widths and hallway
| widths, etc, etc.
| tomplayford wrote:
| Totally agree - not suggesting we throw out writing, we
| would all be doomed.
|
| I'm sure your blind colleague wrote well - so do many of
| my dyslexic colleagues. Doesn't mean it was easy or fast
| For them though.
|
| I suppose what I'm saying is that there's no one-size-
| fits all or one thing for all tasks. This article
| highlights the advantages of writing. And I agree. But it
| isn't the right work from home comms tool for all
| combinations of people and tasks.
| Benjammer wrote:
| Sure, that makes sense. Also I can for sure acknowledge
| that you answered my initial question. There are
| definitely people who speak better than they write, when
| it comes to certain conditions and disabilities that make
| writing harder than it is for the average person.
| RHSeeger wrote:
| I'm not sure I follow that statement. I can see an argument
| that text is not strictly better than verbal communication but,
| at worst, I'd say it's equal (for people as a whole, not for
| one person in particular). Some people are better at written
| communication while some are better at verbal.
| tomplayford wrote:
| For most people, I'll happily agree with you. From a
| dyslexic's perspective, being forced to only ever present
| one's ideas and thoughts in text is pretty restricive.
| RHSeeger wrote:
| And that's fair.. for a dyslexic, written communication is
| worse. I wasn't trying to imply that, for all people, which
| medium is better varies for each individual. I was trying
| to say that, over the set of all people, which medium is
| better tends to vary by person. That neither medium is
| "better" for everyone.
| [deleted]
| baron816 wrote:
| How do you get your coworkers to start proofreading what they
| write?
| _curious_ wrote:
| _Effective_ written communication is remote work super power
| ggurgone wrote:
| that! I wrote something on the same lines
| https://giuseppegurgone.com/remote-work-communication/
| jaakl wrote:
| Video calls are like single-room IRC 20 years ago, before PM,
| threads etc within same room were added. Probably just matter of
| months when we will see subrooms, side-channel whisper, history
| of transcribed logs and many other additions also in video calls.
| Just current software limitations.
| giglamesh wrote:
| "Breakout Rooms" is already a feature of Zoom.
| djrogers wrote:
| Pretty much all of those features you call out are available in
| modern video chat software - at least the one I have to use
| daily (Zoom).
| krm01 wrote:
| In our business, async communication is at the core of how we
| deal with clients. We design UI/UX for tech companies
| (http://fairpixels.pro) and in the 10+ years of trying out a
| dozen of ways to work, async email conversations were by far the
| most effective for us.
|
| Email over Slack, why? Slack and other chat environments still
| create the expectation of realtime responses. Also, messages you
| type there are short and often of a lower quality.
|
| Email is usually more longform. This forces us and clients to
| think first, write second.
|
| The quality of feedback and communication is just so much better.
| timwaagh wrote:
| In my team if someone needs to pick up the kids he just says it
| in chat or even in a video meeting and gets them. I think webex
| meetings work better than real live ones. If they are tiring
| that's positive because meetings last too long. If only one
| person can speak at a time it prevents people from interrupting
| and makes them conscious not to hog the mic. Async communication?
| How would you do that? If you have a question and can't find an
| answer, what do you do? Make a jira user story to document this
| specific scenario and put yourself as the reporting too? Then
| assign to a colleague and hope he does something with it? I mean
| it could possibly work if everyone is accustomed to it, is of a
| very high level and is also a high level technical writer. But it
| just seems to me that in practice junior might be too dumb to
| understand seniors writing. Or senior just writes something
| that's not legible. Or senior ignores his new assigned story
| because junior created it and not the product owner. Or scrum
| master sees the story and thinks: that's not part of sprint goals
| and throws it out of the board. It seems really slow to work this
| way.
| eXpl0it3r wrote:
| I think it really depends on the project size and the kind of
| work. If you're more in a waterfall model, where the specs are
| clear and you just got to do it, I can understand how being
| able to work uninterrupted is a nice-to-have.
|
| But if you work very closely with the business and often run
| into things that could be done or understood in different ways,
| having to wait a day or more to get a clarifying response would
| not work. And this is know-how that can't be written down
| easily if at all, since a lot of decisions are purely based on
| experience and historical knowledge.
|
| I used to have this illusionary vision of how everything should
| be neatly documented, but if you operate on a constantly
| changing code base, it's really hard to find a good balance.
| Documentation gets outdated every few weeks and sometimes days,
| plus most of the time, you don't even know that said
| documentation has been written. As such, you can't fully trust
| the documentation and you always have to check out at least
| part of the code.
|
| What seems to work for me, is documentation that gives a broad
| overview of a topic and then gives certain pointers into the
| code. That way you capture the essence of functionality that is
| likely to remain for a longer time and the transition from
| documentation to code is made easier.
|
| And finally, if someone is stuck or doesn't understand
| something, I find it problematic to have the expectation that
| nobody may be available to read your message for the next few
| hours or whole day. What is more efficient, someone spending a
| couple of minutes to provide assistance or someone
| googling/search Jira/wiki/Confluence for half a day and not
| making any progress?
| VectorLock wrote:
| I've noticed the biggest difference between junior developers and
| more experienced individuals is their written communication
| abilities. This has led me down the path of trying to find
| resources to help teach communications to those that I mentor but
| since this isn't my area of expertise (teaching communications)
| I'd love if anybody had resources to share.
| cborenstein wrote:
| A strength (and weakness) of async is that it comes with a higher
| expectation of writing quality.
|
| When the expectations are too high, it's likely that people won't
| get things down in the first place.
|
| My team has noticed an unintuitive approach to communication that
| seems to work better than alternatives. Write better private
| notes.
|
| Private notes are low-friction. You know what's worth writing.
| You don't need to worry as much about if it's a mess.
|
| Our approach is to help you make your private notes a little
| better organized. And to make it fast to share these notes when
| they might be helpful to someone else too.
|
| It's bytebase.io. Would love the community's feedback.
| lbotos wrote:
| I gave a talk on this idea few years ago, that even just the
| _metadata_ of slack messages was enough to make improvements to
| process. As a support engineer it was useful for us to see when
| we were asking questions in slack, what the patterns were to
| improve our team training:
|
| Ticket comes in -> we don't know -> we link to ticket in X
| channel. Tally the channel links, look at chart, identify
| patterns.
|
| In an office, this would require me to be an EXTREME micro
| manager, whereas remotely, I just paid attention and used the
| meta data to drive our training.
|
| In an office, you could ask the team to keep track, or to tell
| you what they noticed, but by having a direct tap into the data
| stream, the team just does the work.
|
| (This requires a high degree of trust, and we were looking
| _inward_ so it wasn't something that was met with disdain. If we
| were using this to compare what teams were more responsive and
| being outwardly critical, well, I don't think that will go over
| well anywhere.)
| techbio wrote:
| The discoverability of written thought decreases with its
| quantity.
|
| It comes down to knowing your sources, not relying on some Bacon
| number of reinforced echoes.
| MattGaiser wrote:
| I have a day where everyone else in on flex (basically their day
| off every two weeks).
|
| I have already cleared two large tickets because I can address
| the comments they left when I am done another task (because they
| wrote out their entire thought instead of waiting for a
| conversation).
|
| I would bet I am 2-3x as productive as I now have hours of
| uninterrupted time.
| sabujp wrote:
| i find that i spend 3x more time explaining something through
| writing than through a quick chat
| Buttons840 wrote:
| > participants need to be competent at writing and reading prose
| (it's harder than it sounds)
|
| In my experience, around 1/3rd of developers are not good
| typists. Writing code isn't really about typing, so it's OK, but
| when participating in an active conversation in a chat room with
| multiple people, not being able to type well hurts.
| zawaideh wrote:
| would be nice to use "they" or alternate between "he" and "she"
| in the post. Otherwise, it's a great post
| satvikpendem wrote:
| If I were to ever hire, I'd optimize first for clear, written,
| long-form asynchronous communication, second for ability for the
| job at hand, and anything else third.
|
| Having hired some freelancers recently, I've found that there is
| a world of difference between those who can communicate clearly
| and those who can't.
| oDot wrote:
| I wrote Emergency Remote[0] for companies thrown into remote due
| to the situation.
|
| From my experience, it seems that the reason companies use sync
| communication and "emulating" an office is not because they don't
| understand the benefits of async, but because of the required
| discipline.
|
| Fortunately, that discipline is required vastly more of the
| initiator of the conversation. This allows the recipient to quite
| easily refuse sync communication. This way employees can help
| each other out and get used to async.
|
| [0]: https://www.emergencyremote.com/EmergencyRemote.pdf
| DenisM wrote:
| We're finding it quite effective to record short 2-minute videos
| and circulate those. Everyone can talk and point things on the
| screen, not everyone can write or even read attentively.
| chinigo wrote:
| Are these screen recordings with narration or video recordings
| from a webcam?
|
| Personal preference of course, but I'd be less able to express
| myself in a video recording than in an audio recording or
| written document, out of pure self-consciousness.
| DenisM wrote:
| They are all screens. Rarely I record a design on the
| whiteboard and I end up in the frame, but I'm fine with it.
| BTW this also works much better than any spec.
|
| Self consciousness is an interesting problem. I prefer seeing
| faces on the screen during the stand-up (such as it is in the
| days of COVID), but I was told many hesitate to be on camera.
|
| Did you ever find a way out of this? Join.me has very small
| video size, I imagine this is one way to lessen the stress.
| Alas it doesn't work for me - I need to see the facial
| expressions because I need to know when I lost the audience,
| and because I find it hard to pay attention to a disembodied
| (and heavily compressed) voice.
| gav wrote:
| > Self consciousness is an interesting problem. I prefer
| seeing faces on the screen during the stand-up (such as it
| is in the days of COVID), but I was told many hesitate to
| be on camera.
|
| Getting people to turn on their cameras has always seemed
| to be a challenge in my experience, but it does seem
| contagious, once a few people do, everyone starts to over
| time.
|
| It makes a huge difference to see peoples faces over
| talking into a void. I think empathy is a bit part of it.
| sytse wrote:
| When writing you are not getting feedback (give more context, go
| faster, what concerns to address). A back and forth can be a much
| faster way (both in total time elapsed and time spend) to resolve
| something. At GitLab we recommend async by default and jump to
| sync when you start going back and forth.
| https://about.gitlab.com/company/culture/all-remote/asynchro...
| nine_k wrote:
| Real-time, spoken communication is on-site work super power.
|
| When uncertainty is high, and an intense discussion is needed,
| spoken word is much more efficient, from my experience. People
| are fundamentally better at speaking quickly and taking proper
| turns. This all is much slower and more cumbersome in video call,
| phone call, or a text chat. The perceived sequence breaks, the
| turn-taking protocol breaks (unless enforced by a moderator, at
| the expense of speed), and the communication become slower, less
| efficient, and more tiresome.
|
| I _love_ neatly written logically organized texts. But to produce
| such a text, a lot of the questions it answers should be already
| understood, answered, and arranged in a easy-to-consume order.
| There are situations when this is not possible, and _finding out_
| the scope of the problem and its structure is exactly the task.
| Here 's where face-to-face verbal communication rules.
|
| Of course, providing some written output after such a meeting is
| important, too, be it nicely written minutiae (a shared document
| on a large screen works well), or just a photo of the whiteboard.
|
| So, _both_ written and face-to-face types of communication are
| important. None can efficiently replace the other.
| marcosdumay wrote:
| Latency is the video-call superweakness.
|
| But with text there are tools to overcome this problem. Text
| scales into larger groups, and accepts days long latency.
| People adapt quite well to hierarchical chat and shared co-
| authored documents. Any group larger than half a dozen people
| will organize better around text. But any large group is also
| composed of smaller ones, that can always benefit from on-site
| talking.
|
| My impression, after some time of forced remote-only
| interaction is that both modes are very important, but spoken
| on-site communication is ideal for a very small share of the
| total communication.
| e40 wrote:
| I agree with you partially. I found something interesting, with
| this everyone work from home: I'm able to communicate with
| certain people more effectively via zoom.
|
| I think it boils down to with zoom, you are literally in
| someone's face, and it's very obvious when you aren't fully
| focused on them.
|
| Perhaps the new way, with zoom, gave some people an opportunity
| to reset their manners? Not clear what the real reason behind
| it is, but I noticed it immediately.
|
| What a great bonus it was.
| danielovichdk wrote:
| Actually funny this question. Because come to think about it,
| text is by far my preffered way to communicate.
|
| That goes for work and for serious-private matters.
|
| The absolute strengt with text is that it gives you history by
| default - you can save it.
|
| While you can save text it's also eaiser to the search.
|
| The mental model around writing and communicating is the mental
| proces that goes into it, and which is also the reason i disagree
| with people that believe you should be good at writing - if you
| haven't thought about what you want to communicate you can't
| write it nor speak about it. Why would you be better at
| communicating by speech rather than text? Sure it's faster to
| speak or video, but does that give a better result? I say no way
| Gibbon1 wrote:
| I spent about ten years with field service as part of my job.
|
| What that taught me is every form of communication has it's
| uses. For full effect you often need multiple types. Talk on
| the phone. Send a follow up email. Then talk on the phone
| again. Update the original email into a formal doc. Two
| engineers with a whiteboard can solve some problems in a few
| minutes that would take days of back and forth over text.
|
| Formal text though is usually very good. Especially if the
| author can produce high quality output quickly. This is my
| particular failing.
| EvanAnderson wrote:
| It's worth noting that some people specifically see verbal
| communication's undocumented-by-default nature as a feature.
|
| When I was younger I found that idea very offensive. I
| considered people who held that viewpoint to be suspect
| (engaging in political machinations, or using fluid
| recollections of conversations to their advantage). I still
| think there's a grain of truth to my suspicions, but I've
| learned to recognize that there are acceptable reasons for
| undocumented conversations.
| Buttons840 wrote:
| There's still phone calls. Any co-worker you trust enough to
| have an "off the record" conversation with wouldn't turn down
| a "hey, can I call you?" request. They might think it's weird
| at first, but would understand later I'm sure.
| RHSeeger wrote:
| I've called coworkers literally just to rant to someone
| before. Sometimes, you need to complain, but having a
| record of that is not helpful in any way.
| jugg1es wrote:
| In my experience, the people most averse to writing stuff down
| are usually the remote engineers. Remote workers don't typically
| have the same cultural influence as local employees, so they tend
| to be somewhat alienated and therefore have fewer expectations
| put on them. I think this disincentivizes remote workers from
| fully assimilating into the culture and leads to less interest in
| communication. Inevitably, this ends up affecting their
| willingness to properly document.
|
| Just my opinion built on my anecdotal experience.
| Benjammer wrote:
| I have the exact opposite anecdotal experience. Remote
| engineers I've worked with have put a lot more effort into
| their writing because they understand that it's one of their
| only avenues to participate in the company communication
| culture.
| siculars wrote:
| People ask me what do they need to be good at to work at Google.
| I jokingly (but kind of seriously) tell them it's just like grade
| school - reading and writing. 80% of the job is reading, editing
| and commenting on docs people wrote or writing docs people will
| read.
| [deleted]
| rakoo wrote:
| Interestingly, I've been thinking about organization at work and
| I feel like there are many forms of async communications that
| should or could be merged, because of how common they are. We
| need to communicate announcements, ask for opinions on changes,
| document a process, list relevant steps to a change that is
| happening, ...
|
| In my mind there are multiple goals a perfect system should have:
|
| - Must be easy to create a new "conversation" - Must be possible
| to write long form content in a "post", where "post" is the first
| item in a conversation - Must be able to have a meaningful
| conversation with replies to specific points - Must be able to
| change the content of the "post" based on the discussion that
| happened (such that a "post" can be a poll, participants discuss
| options, and the final decision is summarized) - Must be able to
| easily enter and exit the full conversation - Must be able to
| easily link the full conversation, for referencing - Must be able
| to set metadata (dates, relevant people, status, stuff like that)
|
| We have many systems, but none really fits the bill:
|
| - Email is probably the worst, because you can't modify the
| original message, you can't link to it and you can't
| transparently enter the conversation if you weren't part of it
| initially. We've all seen the "adding XYZ to the loop" that
| provide 0 content to the conversation. There's also the whole
| issue about top-posting and lack of proper threading that make
| having a conversation difficult. Probably just a client issue
| rather than a protocol issue though - NNTP is a step above, but
| ironically because it has remained niche the clients and the
| etiquette help having a proper conversation. Still doesn't fill
| the bill - Ticket systems are paradoxically pretty good for this
| situation. They do contain the necessary structure for
| incorporating metadata, in all the various forms ingenuity can
| come up with.... sometimes too much ingenuity, such as the labels
| and fields and knobs that were needed for that project years ago
| are still here, cluttering a lot of space because most aren't
| actually needed anyway. Imagine using such a mess - A wiki is
| nice, but the emphasis on structuring is detrimental for flows
| that go outside of documenting. Sometimes you just want a linear
| list of conversations ordered by date - Google docs and
| associated are good for really long forms for the initial "post",
| but are not very good at structured conversation
|
| Perhaps the best software, for all those use cases, is a forum
| software. I'm partial to the (old) reddit UX or the HN UX; remove
| the useless voting and it's almost the perfect way to
| communicate. The interface gives you the space to actually take
| time about what you want to say and properly articulate it. HN is
| a bit terse here, reddit gives you formatting helps to nicely
| present your ideas and makes reading it easier.
|
| Only drawback is that they are text only, and sometimes you need
| to include non-text (a screenshot of the planned changes, a video
| of the flow to document, a map of the place you're discussing
| about, ...)
|
| (If it is not clear already, I'm still sad at the death of Google
| Wave. 10 years later and it's still the future:
| https://www.youtube.com/watch?v=p6pgxLaDdQw)
| jka wrote:
| Yep, this article rings true on a number of levels, particularly
| regarding asynchronous work and lack of interrupts.
|
| Anecdotally, I'm working on a software project at the moment with
| a small team of volunteers.
|
| To explain some context: I'm the sole developer currently, and
| I'm treating communications to the team as high-value for us, now
| and in future - the same way that I'd like to think that I treat
| the code (I write this with the awareness I've recently cut some
| corners; but cleanup is on the cards).
|
| One observation is that I'm _really enjoying_ only using email
| for that communication.
|
| Sometimes I code for a couple of days before checking or
| answering emails, simply based on what feels most productive or
| compelling at the time.
|
| As a result I never get distracted by pings while working, and
| feel much more comfortable taking time while writing messages and
| replies, generally allowing me to be a bit more thoughtful.
|
| And there's only one communication platform. My attention's not
| split between instant messages, emails, and other organizational
| tools.
|
| This situation's probably an edge case based on the small team
| size and my personal preferences, but it's been an interesting
| experience.
|
| I don't know how well this approach would scale* -- and an open
| question based on my experience and also raised by the article
| is: how and where do you organize that content so that it can be
| discovered by newcomers to the team?
|
| *Example: crisis moments, such as technical outages, would be
| tricky to manage for a multi-person operations team
| jgilias wrote:
| I was lucky enough to be able to use the Twist app for team
| communications for some time. I highly recommend it to people
| willing to go the async way. It feels like a perfect cross
| between e-mail, forum and slack.
| karussell wrote:
| Yeah, I really liked the concept, but when we tried it 2
| years ago or so it had several bugs regarding never getting a
| notification although it should and showing me that I have a
| new message although everything was read. We reported them
| but nothing changed. And all team members had these problems.
| Probably they have fixed them now but we unfortunately we
| switched to slack and now it is very unlikely we switch back
| due to these serious problems.
| vasco wrote:
| I like flow as much as anyone but find the thought of working
| multiple days without speaking to my team to be crazy, I'd feel
| like none of us would be able to move as fast alone as we do
| together, and half the time would end up following rabbitholes,
| or spending too much time on the wrong things because we'd
| never check in for an opinion. The only way I'd see a full or
| more days of work without communicating working well is if we'd
| work on larger amounts of releasable code at once, but then
| there's more chances of conflicts, reviews get longer and
| harder to do and there's more risk releasing.
|
| I think having a team with 1 rotating person responsible to
| handle all external requests per week, and everyone else being
| focused on their work but still being able to pair when needed,
| ask questions provide guidance, etc to be really cool. All of
| this remote, of course.
| joe8756438 wrote:
| That's an interesting idea regarding rotating external
| request handling. Do the team members not currently on call
| forward requests to those on call? How do you manage
| continuity of communication once the rotation has shifted?
| jka wrote:
| Thanks, yep, those are all legitimate concerns about whether
| this would scale.
|
| It's occurred to me that Stripe's email transparency[1] could
| help (although they discovered limitations with that approach
| too, and have been good about publishing those).
|
| We're lucky (in some ways) not to have a large inbound
| feedback load, which is surely also a factor. Thanks for the
| external-request rotation suggestion; that's a good idea to
| provide a refresher from focus work when the burden starts to
| affect the team.
|
| Honestly though, I have to re-state that it's been _so_
| refreshing and enabling to work this way that I wonder
| whether there 'd be ways to scale up and solve the consensus,
| conflict and opinion problems you mention.
|
| Despite that, I'd add another problem to the pile: not
| everyone is going to be able to contribute at equal pace at
| all times (for various completely valid reasons) in a large
| enough team - and there needs to be genuine cultural
| understanding and acceptance of that which I believe is
| frequently absent from high-intensity startup environments.
|
| [1] - https://stripe.com/blog/email-transparency
| u801e wrote:
| > One observation is that I'm really enjoying only using email
| for that communication.
|
| If it were up to me, I would use a self-hosted NNTP server as
| an internal forum for communication and reserve email for one-
| on-one private communication.
|
| > As a result I never get distracted by pings while working
|
| I actually disable notifications from chat applications and
| email and just make sure I check them periodically throughout
| the day. No one has ever complained that I took 10 to 20
| minutes to respond to a question. Though if there's an active
| discussion going on, I will participate as needed.
|
| > how and where do you organize that content so that it can be
| discovered by newcomers to the team?
|
| Newsgroups would typically have a monthly group FAQ post. While
| that could be done via email, newcomers wouldn't be able to see
| emails sent before they started.
|
| > crisis moments, such as technical outages, would be tricky to
| manage for a multi-person operations team
|
| The monthly post with the up-to-date operation procedures to
| follow for technical issues could work and could be checked for
| out-of-date information before posting (which is something that
| wiki documents don't handle well).
| jackjeff wrote:
| Async communication is suitable to resolve some kind of issues.
| But it has two drawbacks: participants need to be competent at
| writing and reading prose (it's harder than it sounds) and even
| with the best of care your ideas can easily be misinterpreted
| resulting in the loss of an async cycle.
|
| For problems which are not well defined, and where a lot of
| decisions need to be taken, especially when they verge toward the
| arbitrary, it's a lot easier to have people in a room and hash it
| out. A remote meeting can work too.
|
| The problem with meetings are those which are not well prepared.
| There shall be an agenda and proper minutes should be produced.
|
| For most complicated matters actions/investigations are supposed
| to be followed up. In a way that's how you mix async with sync
| communication.
| codingdave wrote:
| > misinterpreted resulting in the loss of an async cycle.
|
| True, but readily fixed with "Can we talk about this when you
| have a minute?"
|
| Also, losing "an async cycle" is a completely alien concept to
| me. I've been working remotely for a decade, never heard that
| phrase, and not entirely sure why it matters. Does a
| conversation that takes 14 Slack messages make the business
| less efficient than one that only took 11?
|
| Honestly, I'm not trying to just nitpick, but why would a room
| full of people be beneficial to decisions "when they verge
| toward the arbitrary"? Wouldn't that be the perfect time for
| everyone to send their async opinions, and let a single
| decision-maker just decide? Large calls/meetings work when you
| don't know what you don't know - to get all the information on
| the table, and have all the knowledge in the same place at the
| same time. You talk, give answers where needed, assign some
| action items to people, and go back to your async lives.
|
| As far as the initial statement that you must be competent at
| writing and reading prose... I'd love to hear more about that
| than "it's harder than it sounds". I've worked remotely with
| people with dyslexia and reading disabilities and C-level
| personalities that refused to get in-depth in any single
| communication. And one guy who had all those traits - the
| CEO... and it worked fine. None of that stopped us from doing
| our jobs effectively. You did need to learn how your co-workers
| communicated, but let me assure you - we were not excellent
| writers, we just knew our co-workers well enough to know their
| communication styles.
|
| That is what remote work comes down to, at the end of it all.
| Not communication frameworks and rules of when to use what
| communication channel - but getting to know your team well
| enough that you know how to work together. If you do that, you
| succeed, whether remote or in an office.
| Benjammer wrote:
| >For problems which are not well defined, and where a lot of
| decisions need to be taken, especially when they verge toward
| the arbitrary, it's a lot easier to have people in a room and
| hash it out
|
| Easier in what way? I think it makes people less frustrated by
| having to think hard about a hard problem, and feels "better"
| when everyone is saying what they think without any barriers,
| but I would guess it's much worse at arriving at good solutions
| to challenging business problems. Especially in the case you
| describe, with many decision points. I cannot fathom how a
| group of people chatting can efficiently work through many
| decisions at once, without laying it all out on paper anyway,
| whether it's before or after the fact. None of the meeting
| conversation matters unless you have someone taking good notes
| and summarizing decisions. Which makes me think, why not just
| start with the writing part? How is one person's notes about
| what a bunch of people said during a real-time conversation
| going to be even remotely on the same level as the people
| themselves composing their thoughts in writing? The in person
| meeting just seems like a space to share emotions and make
| shows of power in front of others.
|
| I think async writing is much better (obviously nothing's
| perfect) for removing emotions from the discussion and forcing
| people to spend time thinking through their thoughts. The act
| of composing a written email, or composing a one-page spec
| document can do wonders for people ironing out their own
| thoughts and ideas.
|
| And CC (+BCC) is, imo, the greatest business tool being dropped
| nowadays in favor of synchronous comms. CC keeps people
| informed without wasting time or disrupting schedules. It also
| allows the bosses to keep a much better handle on the comms
| culture of the company, since they obviously cannot sit in on
| or observe every meeting.
|
| In person meetings have plenty of specific use cases, but I
| don't really understand the drive to make critical decisions
| synchronously in the moment during a meeting. Meetings are
| great for presentations, Q&A, gathering feedback, etc.
| BeetleB wrote:
| > and feels "better" when everyone is saying what they think
| without any barriers
|
| Except there are barriers: People can tell you immediately
| that they don't understand you before you go off and speak
| for too long. Whereas with asynchronous, you could write a
| large amount and people won't be able to comprehend it
| because you made a mistake early on.
|
| > I think async writing is much better (obviously nothing's
| perfect) for removing emotions from the discussion and
| forcing people to spend time thinking through their thoughts.
|
| I agree on the latter, and disagree on the former. Rarely
| have I seen an important decision being discussed async that
| is devoid of emotion. With async, emotions are harder to
| gauge. This does not lead to people giving others the benefit
| of the doubt. It more often leads to people misreading
| emotions.
|
| > And CC (+BCC) is, imo, the greatest business tool being
| dropped nowadays in favor of synchronous comms. CC keeps
| people informed without wasting time or disrupting schedules.
| It also allows the bosses to keep a much better handle on the
| comms culture of the company, since they obviously cannot sit
| in on or observe every meeting.
|
| "You know how many emails I get every day? Do you think I
| have time to read every email I get?" spoken by every
| manager/senior engineer in my company.
|
| (Although I'll admit, I prefer email to all other async comms
| I've seen. Pseudo-IM stuff is the worst).
|
| There are, for sure, problems with both forms of
| communications. Conducting good "live" discussions in a room
| is a skill, and most of the participants have to be
| proficient at it. The same will go for async communications.
|
| I think if there are serious, technical/tough issues to
| discuss, it is best to have it written up, with proper
| "counter" documents, and _then_ get into a room to make the
| final decision, with everyone already well informed. It 's a
| rare workplace where that will happen. People will respond to
| something well written with a one line objection on one minor
| aspect of the proposal, etc.
|
| I
| duxup wrote:
| Recently, I was so frustrated with some folks poor reading
| comprehension that I was thinking about an imaginary
| communication system that would allow for decision making where
| there were some rules:
|
| - No responding from mobile devices. The poor response rate is
| just too high.
|
| - The reader is quizzed on the the contents of the
| communication before they can respond (randomly generated
| quizzes might be amusing).
|
| - The reader has to retype the original communication
| themselves before they can respond....
|
| - Timeout value, if no responses that pass the above tests in a
| given time frame, whomever asked gets to complete the task with
| no input and nobody can change the outcome for ... a week or so
| and everyone has to live with it.
|
| - Anyone who wants to change it after the timeout value better
| explain why they didn't ask before hand... no idea how this
| would work, yeah we're getting into the weeds here.
|
| Of course, these are all unworkable in a modern business
| environment but man ... I can dream that some folks would who
| make demands or provide input at least put a minimum amount of
| effort into things before they throw their given wrench into
| the works.
| yazaddaruvala wrote:
| FWIW, it doesn't have to be a "new communication channel",
| you just documented some best practices for email.
|
| > No responding from mobile devices. The poor response rate
| is just too high.
|
| If something was left implicit or de facto re-ask for it to
| be explicit or de jure.
|
| > The reader is quizzed on the the contents of the
| communication before they can respond (randomly generated
| quizzes might be amusing). > The reader has to retype the
| original communication themselves before they can respond....
|
| A simple "What's you're rationale?" or if you're less
| confident "Sorry, I understand the action items and can
| execute them but I didn't follow the motivation. So I can do
| an even better job (or so I can make this decision without
| you next time), could you walk me through your thought
| process?"
|
| > Timeout value, if no responses that pass the above tests in
| a given time frame, whomever asked gets to complete the task
| with no input and nobody can change the outcome for ... a
| week or so and everyone has to live with it. > Anyone who
| wants to change it after the timeout value better explain why
| they didn't ask before hand... no idea how this would work,
| yeah we're getting into the weeds here.
|
| This is the most important email best practice that trips up
| junior workers. Make the default of your email your desired
| outcome.
|
| Instead of: "Does everyone approve?" then if people respond
| asking "Ok, when should I do it? Thursday?".
|
| Try it like this: "I'll make the change on Thursday. Please
| let me know if there are any concerns.".
|
| 1. Make the default response (i.e. no response) in your
| benefit.
|
| 2. Ensure there is a timeout value attached.
|
| None of this is difficult or theoretical, its just a set of
| best practices you can get your self and others used to.
| freedomben wrote:
| Oh man, I hear you. The amount of sad encounters (especially
| lately) that I've had as a result of people not understanding
| what I'm saying because they don't actually read what I wrote
| are enraging. I almost quit one client over it because their
| IT guy is the worst. He will decide ahead of time what your
| email probably says, and that's what he reads into it even if
| I wrote the opposite.
|
| I try to blame myself first for poor communication, but I
| asked some mostly independent people to help mediate and they
| basically came back and told him to read better and review
| past messages if he couldn't properly remember the context.
| cperrine wrote:
| "I know that you believe you understand what you think I
| said, but I'm not sure you realize that what you heard is
| not what I meant."
| ponker wrote:
| You could only have such a system in an environment with a
| huge power imbalance between the sender and recipient, like
| Tim Cook sending a message to an Apple IC engineer. But with
| that kind of power imbalance all of these things happen
| anyways -- if an individual engineer gets an email from Tim
| Cook he definitely isn't firing off a poorly-thought-out
| reply from a mobile device.
| kubanczyk wrote:
| No, actually the opposite is true. The whole idea of any
| policy is to give artificial "power" to one side to
| straighten out the situations where the balance of power is
| unclear.
|
| An exec (the remote-only version of Tim Cook if you like)
| can use their leverage to change the existing email flows
| between all managers and all engineers. Because it's more
| scalable than micromanaging one engineer.
|
| In other words, some people are good at organizing through
| setting policies (the better sort of politics) and it's a
| good place to discuss such ideas.
|
| Parent's formulation doesn't look convincing though :)
| BeetleB wrote:
| Bullets 2 and 3 combined are actually recommended for spoken
| communications as well. As the listener, before responding,
| it's a good habit to say "This is what I understand about
| your proposal" and proceed to summarize and give the original
| speaker an opportunity to correct you.
|
| Probably over half of the communications problems I've seen
| at work are because people don't follow this basic practice.
| They respond based on what they understood, not based on what
| the speaker was saying.
|
| As one book I read put it: You should be able to reflect
| their world view back to them as if you yourself are
| advocating for it (even if you completely disagree). When you
| do this, they'll believe you understand them. For many
| people, only then will they listen to your critiques.
| dmos62 wrote:
| There's also a subtlety where if you focus too much on what
| someone said, you might lose why he said it and how it
| pertains to the situation. I've gotten through some
| communication problems by focusing on how I understood the
| person's position, instead of what the arguments he brought
| forth. When you do that you get this funny situation where
| it almost seems like each person is participating in
| different conversations, but at the same time the
| discussion is progressing effortlessly. I think of it as
| letting yourself be free to frame and reframe the issue at
| hand however you like.
| infogulch wrote:
| > They respond based on what they understood, not based on
| what the speaker was saying.
|
| Lets say there are three main steps in responding to
| communication: 1. Comprehension of the original
| communication. 2. Mapping that communication onto the
| reader's priors. 3. Crafting a response that communicates
| the results of that mapping.
|
| The problem seems to be that the first two steps are
| typically left implicit indefinitely. As a result, there
| can be discontinuities lurking hidden in or between any of
| those three steps and it's a hell of a lot of work to pry
| those discontinuities up to the surface.
| BeetleB wrote:
| Well, the whole point of repeating back their world view
| is to prevent implicitness and reduce hidden
| misunderstandings.
|
| It's really not hard to do. You'll never get there 100%,
| but getting to 80%? It's easy.
| SJetKaran wrote:
| > - No responding from mobile devices. The poor response rate
| is just too high.
|
| For me, the tendency of slack to let users write very short
| sentences/phrases is the issue. Etiquette for slack allows
| very IM like messages, whereas Emails are generally required
| to be more verbose.
| asjw wrote:
| How can you trust someone's spoken words if they can't write?
|
| And what's the problem in your opinion with written iterations?
|
| I usually attend meetings, hours a day, when I have to repeat
| the same concepts over and over, multiple times, to the same
| people, because they just forget what we established hours
| before.
|
| There are people at my job setting up meetings just to "recap",
| which is a poor excuse for "we didn't take notes and/or we
| weren't listening and just said yes"
|
| At least emails are searchable...
| tluyben2 wrote:
| It is my problem with meetings & calls; I have no issue with
| effective meetings, however, a lot of people I work with (but
| ofcourse not all), treat meetings and voice calls just as a
| reminder/recap. They basically do not remember most of
| anything and don't read/write anything either. So the people
| who take notes, read the minutes and read the docs have to
| sit through hours or rehash per week.
|
| I cannot imagine how much time/money is lost by this in the
| world.
| Traster wrote:
| I think a big part of this article is that the author doesn't
| like being interrupted and therefore has defined this as the
| problem. I don't like being interrupted either - but often the
| interruptions I experience are the best opportunities I have to
| communicate ideas, have creative back and forth, and importantly,
| communicate the details that are going to get me shouted at for
| saying on the wiki.
|
| The problem with asynchronous communication is that I need to
| predict what information you're going to need, before you need
| it. The result is huge amounts of documentation work going on -
| 90% of which is useless, and the other 10% is either
| undiscoverable or could as just as easily be solved with "has
| anyone touched the db" in chat.
|
| The example is great - because it's absolutely something that
| I've seen happen. You post on the group chat "did anyone touch
| the db" and someone replies, "Oh Johnny mentioned something about
| it the other day". Suddenly you're not searching through
| thousands of jira tickets and wiki pages, and most likely not
| finding what you want anyway - since no one can predict how
| they'll scre up. You just ping Johnny, and if Johnny isn't there?
| Well he'll reply when it's back. It's fine. _That_ is part of
| flexible working. Flexible working isn 't "I get to pick up my
| kids at 12" it's about everyone having flexibility, and everyone
| giving flexibility.
|
| To me, this asynchronous communication plan sets an unacheivable
| goal, because you're never going to know what it is other people
| are going to need to know, and documenting everything
| exhaustively is an uneconomical.
| ChrisMarshallNY wrote:
| My biggest issue (and it is an issue that has been brought to my
| attention), is the old "Emperor Joseph" issue:
|
| _" Too many words."_
|
| I trend prolix. In my essays, this can be corrected by post-edit,
| but it is not so easy to do that in realtime.
| cmarschner wrote:
| Peter F. Drucker, influential author of countless books on
| management, once made a very simple argument: there are reader
| types, and there are listener types. If you are dealing with a
| partner you better know which type they are.
|
| It doesn't make sense to hand a listener type a manuscript
| without talking about the subject, and it doesn't make sense to
| set up meetings with a reader type before you hand off the
| written argument.
|
| We should perhaps just accept that an tolerate each other where
| our strengths are.
|
| [1] Peter F. Drucker: Managing Oneself.
| https://www.amazon.com/Managing-Oneself-Harvard-Business-Cla...
|
| Edit: Online:
| http://academic.udayton.edu/lawrenceulrich/LeaderArticles/Dr...
___________________________________________________________________
(page generated 2020-06-19 23:00 UTC)