[HN Gopher] How to embrace asynchronous communication for remote...
___________________________________________________________________
How to embrace asynchronous communication for remote work
Author : serial_dev
Score : 72 points
Date : 2024-03-14 07:54 UTC (1 days ago)
(HTM) web link (handbook.gitlab.com)
(TXT) w3m dump (handbook.gitlab.com)
| ergonaught wrote:
| I love their apparent documentation culture, however, "the
| advantages of asynchronous work" and "how to embrace asynchronous
| communication" are separate topics that warrant separate
| documents.
| VectorLock wrote:
| Its hilarious how much people still cling to synchronous
| meetings, even in an increasingly "Remote", globally distributed
| company.
|
| Far too often "this could have been an email" meetings end up
| forcing some people in some other time zone (usually the people
| in APAC people) to stay up late. I just can't figure out what the
| fixation is. Maybe they just like talking better than typing.
| Perhaps getting people to embrace dictation software (call it AI
| and they'll jump all over) could get them to break this habit.
| OmarShehata wrote:
| > I just can't figure out what the fixation is
|
| I see this happen over and over: there's a new system change,
| some things don't work as well, so people revert & try to cling
| to the old system.
|
| This is a bit of a fallacy that comes from looking at only what
| is lost, and not the total tradeoff of what is gained & lost. I
| think it's not unreasonable to fixate on sync meetings, because
| your procedures & culture have been built around it. But I
| think it'd be more productive to "roll forward" and figure out
| how to make the best use of the new system, and plug in any
| gaps it has.
| djaouen wrote:
| They do it because they are (generally) not as interested in
| the success of the company (or even themselves) as they are in
| the look of success for themselves. You are overestimating
| people here.
| mwigdahl wrote:
| My experience is that for some people, the physical act of
| speaking is required for them to think through an issue. Think
| rubber-duck debugging, but applied to most aspects of their
| lives.
|
| For whatever reason, typing does not seem to serve the same
| purpose for these people, or doesn't serve it nearly as well. I
| don't know if the important part is the actual verbalization or
| if it's the direct, low-latency synchronous conversation with
| another person, but folks like this strongly prefer and are
| much more productive in meeting settings.
|
| They are also often frustrating to interact with, but that's
| orthogonal...
| wrs wrote:
| I wonder if using a low-latency conversation with a
| reasonably effective LLM as a "front end" for documentation
| will be a big productivity boost for folks like this.
|
| I have been using ChatGPT as a rubber duck (who is also a
| pathological liar!) for working through code issues with good
| success. What if you just ramble on for five minutes and ask
| it to summarize what you just said in README form? (Hmm, I'm
| going to try it!)
| mwigdahl wrote:
| LLMs already make amazing rubber ducks! I would bet you're
| right -- when we have really good voice UIs for LLMs so
| it's even more like having a real conversation there are a
| lot of people who are going to start unlocking considerably
| more value from them.
|
| I've had some success using Gemini 1.5 to take a recorded
| Teams meeting of a debugging session (with screen share),
| extract an audio transcript with Whisper, upload _both_ the
| video and the transcript, and get a summary of what was
| done. I'm still working on how to get the right amount of
| detail and organization without losing the high level flow,
| but even in a basic state it's better than anything I've
| had previously.
| jodrellblank wrote:
| It's ridiculous how a few hundred millisecond lag can make
| communication difficult and frustrating but certain people on
| the internet pretend an unpredictable lag between minutes and
| days for every step of a conversation is exactly the same as an
| in person chat. It so obviously isn't.
| s1artibartfast wrote:
| Yeah. It is basically impossible for 3 thoroughly confused
| people to align on a topic they don't fully understand
| asynchronously. There can be dozens of questions, unknowns,
| clarifications, ect.
|
| Email is great for instructions to do X with Y requirements.
|
| It is terrible to figure out what needs to be done and what
| the requirements are.
|
| I wish there were a better way, but I havent found it. As a
| result, I spend probably half my day in cross functional
| meetings with 10-15 people.
| VectorLock wrote:
| Now would you describe that as synchronous or asynchronous?
| JamesLeonis wrote:
| It isn't just remote work. I worked with an engineering manager
| that took a mandatory engineering-wide meeting, including
| hardware engineers and honest-to-god tradesmen, every two
| weeks. Each team lead sent a bulleted list of pre/post Scrum
| goals, with those goals read out from Microsoft Word on a
| projector. Imagine an hour long standup where only team leads
| talked and you get the idea.
| ipaddr wrote:
| We have that weekly. I don't go but we do that. It gives
| management a summary. It wastes everyone else's time
| thih9 wrote:
| I like the idea, but not the execution. A public, excessively
| long company handbook filled with corporate jargon does not seem
| a helpful to me. Perhaps the saying should be: "This could have
| been a short email".
| mocmoc wrote:
| I've been working like that for years. I can't come back from it
| karaterobot wrote:
| Gitlab has great remote work guides. I took a Coursera course
| about remote work from them. Generally it was good, but one of
| the things that bothered me about their justification for remote
| work--which I notably do not see listed here--is that they argue
| it's great because you can pay people less when they work in
| different geographic areas. Yes, this is fairly common, but I
| still don't think it's ethical. I don't think it's even desirable
| in the long run, as it will filter out sought-after candidates
| who happen to live elsewhere, which _should_ be one of the big
| advantages of being fully remote.
|
| https://handbook.gitlab.com/handbook/company/culture/all-rem...
| roland35 wrote:
| Supply and demand, baby! If a company really likes you, they
| can always scale up your pay even if you are in a low cost of
| living place.
|
| As a remote engineer in the Midwest, I still make over double
| what local rates are, despite the remote adjustment. So it
| stinks but it still works for me since moving to NY or SF would
| be much worse (financially at least, they are lovely places)
| ip26 wrote:
| If you don't pay by location, how should you pay? If you pay
| flat rate and are fully remote, why would you peg your rate to
| SFBay?
| karaterobot wrote:
| Good question, why would you peg your rate to the bay area? I
| wouldn't. It's not sustainable, or even rational in a world
| where money isn't cheap. The argument goes: I have to pay Bay
| Area salaries, because that's where the best people live, and
| the best people live near the Bay Area because that's where
| the money is. But in a world where you can recruit from
| anywhere, I'm not sure that's true, or that it will be true
| on a medium to long timeline, as people disperse to
| decentralized, remote jobs. So, I'd pay the same amount,
| irrespective of geography, based on the value the employee
| brings to the company and the difficulty of filling that
| position with the marginal next employee. That makes most
| sense to me, would likely select for happier employees
| (because living the bay area isn't ideal for many), less
| turnover, and a wider (ultimately better) pool of candidates.
| elondaits wrote:
| Agree. Also, I live in a "cheap" country... so cheap for
| food and rent. Expensive for clothes, very expensive for
| tech, rather expensive to travel, etc. So anyone paying me
| in relation to the cost of buying food is abusing the
| asymmetry.
| pizzafeelsright wrote:
| Ultimately this is a culture that requires leadership to
| establish and maintain.
|
| I have tried without success as I was not seen as a leader in the
| area.
|
| What I have done successfully is boil down my requests to allow
| async responses that do not require an exchange.
|
| The template is generically: * Set context (what/when)
|
| * Establish reasoning (what/why)
|
| * Describe desired outcome (what/when)
|
| * Request binary response (what/who) fulfill request or direct me
| to whom can.
|
| _Mx. Password Resetter, I got locked out of my account after 3
| attempts, the self password resetter is currently down. I need to
| have my password reset by tomorrow morning. I am requesting
| either a reset of my account, let me know when the self reset
| will be online, or in the event you cannot please direct me to
| who can. My contact info is below in the event you want to verify
| my identity. Thank you_
|
| With enough context, an ability for them to tell me to gtfo or
| fix it, or pass the buck, the responses is generally < 20 minutes
| for most requests.
| ninkendo wrote:
| It's funny because your sample communication reads exactly like
| an email.
|
| Normally when it comes to remote work we like to talk about
| chat (slack, etc) and how to communicate in a way that lends
| itself well to asynchronous replies, but when you think about
| it, email is already perfect for this:
|
| - Email generally doesn't carry the expectation that the
| recipient will reply immediately
|
| - Nobody emails with just "Hi" and waits for a response
|
| - People already know how to craft email in a way that is self
| contained and doesn't require a ton of back and forth
|
| - Major open source projects, particularly the Linux kernel,
| are done entirely over email to great success.
|
| Sometimes I wish typical remote companies would embrace email
| (with a searchable web archive) instead of chat. Mailing lists
| replace channels, you can always reply directly to take things
| off-thread, mail is an open protocol where you can use your own
| client... the advantages are enormous.
| digging wrote:
| Chat apps like Teams, Slack _should_ be used as essentially
| internal email with the option to drop into real-time
| synchronous chat. The main difference is that you have to be
| on the same instance so there are cases where email is still
| more appropriate, though.
| out-of-ideas wrote:
| sort of; the idea of having a phone and 'instant message' to
| always grab attention is ridiculous; text-chat all the same
| to me; if i have an emergency, blow me up with an audible
| alert ( a call of some sort, a mention with particular rules
| in place to not get over-mentioned ).
|
| Email is crap-tier for internal communications IMO in that
| companies have 1 email for folks and it allows external
| entities to spam users (even if its internal spam). internal
| communication should be separated from external
| communication, this will help lower the phishing attack
| surface.
|
| i'd argue people should treat "IM" like emails; get a
| response eventually; if you want immediate attention,
| schedule a calendar/meeting with somebody.
|
| The biggest problem i see with chat-software is the
| attention-grabbing-notifications; silence all that stuff, and
| check on IM's every hour or so - set it up so that @mentions
| _might_ notify you in select channels.
|
| I find it sad when doing a paired programing session, on a
| scheduled-meeting, that folks get _so_ distracted by the
| pings, popups, ect of notifications for queries that are not
| urgent. They need to practice 1) patience and 2) diligence in
| responding to things they've been directly mentioned or have
| knowledge about
| dheera wrote:
| > My contact info is below in the event you want to verify my
| identity
|
| You could take this a step further by proving who you are and a
| hash of the password you would like your password reset to.
| Like for example supplying a Yubikey TOTP as of the time of the
| e-mail should theoretically be sufficient; the IT people should
| be able to match that code against the e-mail time.
|
| Unfortunately they may not be competent enough to know how to
| reset your password given the hash.
| digging wrote:
| I've had almost the exact situation at my work. I eventually
| even put nohello.net in my status message and forced it to show
| up whenever someone messages me (which felt rude! but
| important). Wrote up a pros/cons document of async standup
| which referenced many of the benefits of properly practiced
| async communication, with the implication that we could adopt
| those principles in our regular communications.
|
| I still get a "Hi" at least once a week. I've completely
| stopped responding to those. The cycle of grueling standups
| growing longer week by week until some form of reorganization
| cuts them back down continues.
|
| If leadership says they're remote-first but doesn't understand
| the practice of async communication, I don't believe a job at
| that org can be good.
| robertclaus wrote:
| At a previous company we successfully implemented most of the
| ideas in the article (and stayed remote) while encouraging as
| much synchronous work as we could. I personally find that there
| are a lot of benefits to synchronous work for junior engineers.
|
| Some examples of the balance we found:
|
| > (async) We required agendas and public documentation of
| meetings so folks would be comfortable skipping them if they
| weren't relevant.
|
| > (sync) We pushed for live pair programming when reasonable to
| encourage learning skills from each other.
|
| > (async) We allowed folks to skip standups if they sent their
| daily updates out before the meeting.
|
| > (sync) We had virtual office hours so junior engineers had an
| easy place to get help.
| jerebear wrote:
| This sounds pretty great tbh. I'm essentially a junior, and I
| can see this format helping juniors get used to having good
| habits in regards to thinking forward about what needs to be
| done with the stand-ups, while giving them enough options for
| support in the office hours.
| psunavy03 wrote:
| > We allowed folks to skip standups if they sent their daily
| updates out before the meeting.
|
| Once again assuming the purpose of a standup is to "give
| updates." It's not. It's for the team to collectively look at
| what they got done in the last 24 hours, and make a better plan
| as to what they're going to get done in the next 24 hours as a
| group.
|
| It's not a status update; it's a mini inspect-and-adapt cycle.
| tkiolp4 wrote:
| We have dashboards for that. We know exactly what our
| colleagues have been working on in the last 24h (column In
| Progress), what has been done (column Done). What needs to be
| done in the future is discussed in planning meetings. With
| modern tooling (even Jira helps here), daily standups have
| zero value.
| cdchn wrote:
| Gitlab's entire "TeamOps" philosophy resonates with me heavily.
|
| https://university.gitlab.com/learn/course/teamops/introduct...
|
| Default to transparency, shared reality (operating from a single-
| source-of-truth), bias for action, so much of it just makes
| sense.
| wwarner wrote:
| Interesting read but pushes its agenda very hard. Six benefits to
| asynchronous work but zero costs?
| lifeisstillgood wrote:
| I am reminded of the Asimov books where the robot detective
| investigates murders happening amoung people who live totally
| isolated lives on some planet, they never meet another human in
| real life, only holograms and interact with robots.
|
| Asimov of course came down on the side of messy dirty human
| contact
|
| Much of what is said here _can also be done in a busy office_.
| It's about what's priority, it's about personality conflicts and
| managing them well. Bad relationships are waaaay harder to fix
| remotely - and waaaay easier to start.
| zeroonetwothree wrote:
| I love remote work but when it's async I find things go a lot
| slower. Sometimes you need someone to quickly accept your PR and
| if they just went to bed because of TZ differences your project
| is delayed a full day.
| ajb wrote:
| Ideally, someone accepting your PR shouldn't gate working on
| the next one. I would be more interesting in figuring out what
| process issue means you can't start work on the next item than
| in making everyone respond to PRs in real time.
| TheRealWatson wrote:
| Bur this is not an async problem. It's a TZ problem, right? .
| OTOH you can avoid being paged in the middle of your sleep id
| your team has people in far time zones.
|
| For the record, I struggle with timezone differences too. The
| non-async moments tend to always suck for someone.
___________________________________________________________________
(page generated 2024-03-15 23:00 UTC)