19 ms·

How to embrace asynchronous communication for remote work

189 points by serial_dev 3y ago

mocmoc 3y ago
I’ve been working like that for years. I can’t come back from it
ergonaught 3y ago
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 3y ago
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 3y ago
  > 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 3y ago
  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.
- deleted 3y ago
  [deleted]
- mwigdahl 3y ago
  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 3y ago
    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 3y ago
      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.
  - teeray 3y ago
    This. Some people are just not great writers, but when you ask them “what do you want to say?” they say it well. The next step, “okay, just write that”, never happens. They just use the 50-person all-hands weekly sync to do the saying part. What we really need are something like internal podcasts.
- jodrellblank 3y ago
  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 3y ago
    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 3y ago
    Now would you describe that as synchronous or asynchronous?
    - jodrellblank 3y ago
      16 hour delay for me to reply "Would I describe what as syncronous or asynchronous?". If you have a point to make, make it. Better yet, you waste your time writing out a lot of detail so I can one-line ignore it with plausible deniability (because this "should be an email" stuff often turns out like a power play in that style).
- JamesLeonis 3y ago
  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 3y ago
    We have that weekly. I don't go but we do that. It gives management a summary. It wastes everyone else's time
- ryandrake 3y ago
  My retort to “this meeting could have been an e-mail” is usually “but do you read/respond to your e-mail?” I don’t default to synchronous. I prefer E-mail too, and I reach for that first. But if you’re ignoring me, I’m going to drag you into a synchronous session.
  - skipkey 3y ago
    And I’m probably going to decline future meeting requests from you. Your project probably is only incidentally related to mine. If you give me time, usually a few days, I can probably help, when I get some free time. But if you are pushy, well, your manager can talk to mine, who will probably tell you no.
thih9 3y ago
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”.
karaterobot 3y ago
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-remote/remote-compensation/ https://handbook.gitlab.com/handbook/company/culture/all-rem...
- roland35 3y ago
  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)
  - laserlight 3y ago
    > 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. I don't think it's that easy. When Person A who is living in a high-cost area asks for a raise, they will be perceived right. When Person B who is living in a low-cost area does the same, they will be perceived greedy. If the company thinks that cost-of-living has value, it will.
    - serial_dev 3y ago
      You need competing offers, then it doesn't matter if they think you are greedy (whatever the f that means in work context), because if they come back with that bs reasoning as to why they won't give you a raise, you can resign on the spot. In my experience getting competing offers remotely is not easy, but gets easier once you landed a well paying job.
pizzafeelsright 3y ago
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 3y ago
  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 3y ago
    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.
robertclaus 3y ago
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 3y ago
  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 3y ago
  > 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 3y ago
    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.
    - ryandrake 3y ago
      In order for this to work, the status updating needs to become part of everyone’s regular workflow. Otherwise the dashboards are never accurate. I worked in a place where people would set aside time weekly to “do JIRA” meaning all other times, JIRA was not an accurate reflection of where the project was. Totally useless.
cdchn 3y ago
Gitlab's entire "TeamOps" philosophy resonates with me heavily. https://university.gitlab.com/learn/course/teamops/introduction-to-teamops/introduction 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 3y ago
Interesting read but pushes its agenda very hard. Six benefits to asynchronous work but zero costs?
lifeisstillgood 3y ago
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.
- kaffekaka 3y ago
  Yes, the book "The Naked Sun". Ironically on that planet they were completely reliant on real time video meetings, no async communication was used at all. But the video meetings did seem cool.
zeroonetwothree 3y ago
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.
- TheRealWatson 3y ago
  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.
  - The_Colonel 3y ago
    This happens with remote teams even in the same timezone. Many people don't work 9-5 and you can get many hours of delay (often effectively a full business day).
- ajb 3y ago
  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.
  - deprecative 3y ago
    No, but I've seen folks get laid off as a result of this. Granted they were in a PIP but they'd met the conditions established within with exception for accepted PRs, y'know points. So when their PR wasn't approved before standup the following day (end of sprint) they were let go that afternoon despite having done their work to the satisfaction of the PIP such as they could.
    - viraptor 3y ago
      That's not an issue with remote work / TZ differences. That's an issue with stupid management. If the review was solved, they'd find some other system to abuse.
ggm 3y ago
Meetings which decide things are very hard asynchronously because they empower both not deciding, and veto by non attendance. I'm not saying it always happens but if a decision has to be made and it's Round Robin (which is what asynchronous work implies to caucus everyones sign off), it's going to take several orbits round to avoid toxic gaming of the mechanistic side, where a synchronised event would be one and done if the decision is a vote or consensus.
- TotalCrackpot 3y ago
  Non attendance should imply you don't count in the decision. You should have a deadline of 1 or 2 days for the vote, if someone doesn't vote they don't matter in the decision.
  - ggm 3y ago
    That's the engine room which goes to "you decide" and its one person's opinion.
shepardrtc 3y ago
I longed for more async communication when everything used to be synchronous. But now that everything is async, I miss being able to work with people in the same space. It just feels so lacking, and I often feel unmotivated. I guess it's the old saying of, be careful what you wish for, you just might get it.
gilbetron 3y ago
Remote work is great. Async work is generally slow and terrible, at least for the pace that you need to achieve to succeed. Many people equate remote work with async, when that isn't the case. Talking to people achieves results faster. Async work is ponderous and is the lowest common denominator when you can't do anything synchronous. Async can help synchronous work somewhat, and is an important component, but not the primary component.
- DinaCoder98 3y ago
  > Async work is generally slow and terrible, at least for the pace that you need to achieve to succeed. Really depends on the work that needs to get done. Sometimes it's just a matter of time and work that needs to be put in, and async work is perfectly suited to that.
- 48864w6ui 3y ago
  Pro tip: for software, async is usually better, even among colleagues who share a physical office.
  - gilbetron 3y ago
    Hard disagree. I've been doing this for 35+ years and pure async communication is the worst. A blend is the best, but you need sync to accelerate things.
- jjeaff 3y ago
  I feel that synchronous work is best for lots of small tasks that need to be completed urgently. Like putting out fires. But for large projects that need deep understanding and have long horizons, async is better.
StickyRibbs 3y ago
Genuine curiosity. What compels a company to write such an extensive handbook about remote work? The company I joined right after covid started was relatively small eng organization ~20 and we're up to 60-70 eng org but the company size is around ~300. There were lots of leadership meetings and communication but that's all we really needed to run a successful remote first company.
- userbinator 3y ago
  The desire to maintain control (or the illusion thereof) over its employees.
- thih9 3y ago
  I don’t know for sure. I’d guess: - Hiring, they want to show how they work for new hires - PR, they want to present themselves as experts - lack of trust, or a culture of micromanagement A side effect is: making the company less agile and its processes more bloated - now you have to read a 1000 page document before you can do anything. I also didn’t list transparency, if anything I believe the impact is negative: I’m sure some people can ignore the rules and it’s unclear who and when.
48864w6ui 3y ago
Upon reflection: it comes down to whether your colleagues have an oral or a literate communication style. In the former case, async won't work and will be avoided; in the latter case it will be preferred even given physical proximity.
_cenw 3y ago
I was in a team where this just worked, and I've missed it ever since. I had another team essentially bully me out (by withholding information and not inviting me to meetings with the justification that "I didn't want that") when I tried to bring some of that culture over (and that was in the same company). It was a security team without any feature pressure, so their idea of working together was sit in a meet and chit-chat for a considerable time of that. And anyone asking anything was always directed at everyone - worse than an office with headphones. It was not fun. But even almost elsewhere else, so much communication goes on in direct messages or ad-hoc calls you're not invited to, it's not my idea of good remote culture.

189 points by serial_dev 3y ago

I’ve been working like that for years. I can’t come back from it

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 3y ago

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 3y ago
> 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 3y ago
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.
deleted 3y ago
[deleted]
mwigdahl 3y ago
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 3y ago
  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 3y ago
    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.
- teeray 3y ago
  This. Some people are just not great writers, but when you ask them “what do you want to say?” they say it well. The next step, “okay, just write that”, never happens. They just use the 50-person all-hands weekly sync to do the saying part. What we really need are something like internal podcasts.
jodrellblank 3y ago
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 3y ago
  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 3y ago
  Now would you describe that as synchronous or asynchronous?
  - jodrellblank 3y ago
    16 hour delay for me to reply "Would I describe what as syncronous or asynchronous?". If you have a point to make, make it. Better yet, you waste your time writing out a lot of detail so I can one-line ignore it with plausible deniability (because this "should be an email" stuff often turns out like a power play in that style).
JamesLeonis 3y ago
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 3y ago
  We have that weekly. I don't go but we do that. It gives management a summary. It wastes everyone else's time
ryandrake 3y ago
My retort to “this meeting could have been an e-mail” is usually “but do you read/respond to your e-mail?” I don’t default to synchronous. I prefer E-mail too, and I reach for that first. But if you’re ignoring me, I’m going to drag you into a synchronous session.
- skipkey 3y ago
  And I’m probably going to decline future meeting requests from you. Your project probably is only incidentally related to mine. If you give me time, usually a few days, I can probably help, when I get some free time. But if you are pushy, well, your manager can talk to mine, who will probably tell you no.

thih9 3y ago

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

karaterobot 3y ago

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-remote/remote-compensation/ https://handbook.gitlab.com/handbook/company/culture/all-rem...

roland35 3y ago
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)
- laserlight 3y ago
  > 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. I don't think it's that easy. When Person A who is living in a high-cost area asks for a raise, they will be perceived right. When Person B who is living in a low-cost area does the same, they will be perceived greedy. If the company thinks that cost-of-living has value, it will.
  - serial_dev 3y ago
    You need competing offers, then it doesn't matter if they think you are greedy (whatever the f that means in work context), because if they come back with that bs reasoning as to why they won't give you a raise, you can resign on the spot. In my experience getting competing offers remotely is not easy, but gets easier once you landed a well paying job.

pizzafeelsright 3y ago

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 3y ago
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 3y ago
  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.

robertclaus 3y ago

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 3y ago
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 3y ago
> 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 3y ago
  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.
  - ryandrake 3y ago
    In order for this to work, the status updating needs to become part of everyone’s regular workflow. Otherwise the dashboards are never accurate. I worked in a place where people would set aside time weekly to “do JIRA” meaning all other times, JIRA was not an accurate reflection of where the project was. Totally useless.

cdchn 3y ago

Gitlab's entire "TeamOps" philosophy resonates with me heavily. https://university.gitlab.com/learn/course/teamops/introduction-to-teamops/introduction 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 3y ago

Interesting read but pushes its agenda very hard. Six benefits to asynchronous work but zero costs?

lifeisstillgood 3y ago

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.

kaffekaka 3y ago
Yes, the book "The Naked Sun". Ironically on that planet they were completely reliant on real time video meetings, no async communication was used at all. But the video meetings did seem cool.

zeroonetwothree 3y ago

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.

TheRealWatson 3y ago
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.
- The_Colonel 3y ago
  This happens with remote teams even in the same timezone. Many people don't work 9-5 and you can get many hours of delay (often effectively a full business day).
ajb 3y ago
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.
- deprecative 3y ago
  No, but I've seen folks get laid off as a result of this. Granted they were in a PIP but they'd met the conditions established within with exception for accepted PRs, y'know points. So when their PR wasn't approved before standup the following day (end of sprint) they were let go that afternoon despite having done their work to the satisfaction of the PIP such as they could.
  - viraptor 3y ago
    That's not an issue with remote work / TZ differences. That's an issue with stupid management. If the review was solved, they'd find some other system to abuse.

ggm 3y ago

Meetings which decide things are very hard asynchronously because they empower both not deciding, and veto by non attendance. I'm not saying it always happens but if a decision has to be made and it's Round Robin (which is what asynchronous work implies to caucus everyones sign off), it's going to take several orbits round to avoid toxic gaming of the mechanistic side, where a synchronised event would be one and done if the decision is a vote or consensus.

TotalCrackpot 3y ago
Non attendance should imply you don't count in the decision. You should have a deadline of 1 or 2 days for the vote, if someone doesn't vote they don't matter in the decision.
- ggm 3y ago
  That's the engine room which goes to "you decide" and its one person's opinion.

shepardrtc 3y ago

I longed for more async communication when everything used to be synchronous. But now that everything is async, I miss being able to work with people in the same space. It just feels so lacking, and I often feel unmotivated. I guess it's the old saying of, be careful what you wish for, you just might get it.

gilbetron 3y ago

Remote work is great. Async work is generally slow and terrible, at least for the pace that you need to achieve to succeed. Many people equate remote work with async, when that isn't the case. Talking to people achieves results faster. Async work is ponderous and is the lowest common denominator when you can't do anything synchronous. Async can help synchronous work somewhat, and is an important component, but not the primary component.

DinaCoder98 3y ago
> Async work is generally slow and terrible, at least for the pace that you need to achieve to succeed. Really depends on the work that needs to get done. Sometimes it's just a matter of time and work that needs to be put in, and async work is perfectly suited to that.
48864w6ui 3y ago
Pro tip: for software, async is usually better, even among colleagues who share a physical office.
- gilbetron 3y ago
  Hard disagree. I've been doing this for 35+ years and pure async communication is the worst. A blend is the best, but you need sync to accelerate things.
jjeaff 3y ago
I feel that synchronous work is best for lots of small tasks that need to be completed urgently. Like putting out fires. But for large projects that need deep understanding and have long horizons, async is better.

StickyRibbs 3y ago

Genuine curiosity. What compels a company to write such an extensive handbook about remote work? The company I joined right after covid started was relatively small eng organization ~20 and we're up to 60-70 eng org but the company size is around ~300. There were lots of leadership meetings and communication but that's all we really needed to run a successful remote first company.

userbinator 3y ago
The desire to maintain control (or the illusion thereof) over its employees.
thih9 3y ago
I don’t know for sure. I’d guess: - Hiring, they want to show how they work for new hires - PR, they want to present themselves as experts - lack of trust, or a culture of micromanagement A side effect is: making the company less agile and its processes more bloated - now you have to read a 1000 page document before you can do anything. I also didn’t list transparency, if anything I believe the impact is negative: I’m sure some people can ignore the rules and it’s unclear who and when.

48864w6ui 3y ago

Upon reflection: it comes down to whether your colleagues have an oral or a literate communication style. In the former case, async won't work and will be avoided; in the latter case it will be preferred even given physical proximity.

_cenw 3y ago

I was in a team where this just worked, and I've missed it ever since. I had another team essentially bully me out (by withholding information and not inviting me to meetings with the justification that "I didn't want that") when I tried to bring some of that culture over (and that was in the same company). It was a security team without any feature pressure, so their idea of working together was sit in a meet and chit-chat for a considerable time of that. And anyone asking anything was always directed at everyone - worse than an office with headphones. It was not fun. But even almost elsewhere else, so much communication goes on in direct messages or ad-hoc calls you're not invited to, it's not my idea of good remote culture.