How to embrace asynchronous communication for remote work(handbook.gitlab.com)
handbook.gitlab.com
How to embrace asynchronous communication for remote work
https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/
96 comments
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.
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.
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.
Is this something the folks at Microsoft or Slack are actually saying "this is how our product is intended to be used" or is this just you saying "I wish these apps were different?" I ask because approximately 0% of the people I've met have ever used Teams/Slack/etc. as email, and approximately 100% of them use it as real-time synchronous chat first, and archive of past real-time chats second, and asynchronous chat a distant third.
> Is this something the folks at Microsoft or Slack are actually saying "this is how our product is intended to be used"...
What those folks have to say on the topic is pretty irrelevant. What is relevant is how specific people (or groups of people) are using these text-based-communication tools.
> I ask because approximately 0% of the people I've met have ever used Teams/Slack/etc. as email
I've been working at a largeish company with employees all over the globe. It's very common for its employees to have to get information from someone who will be reporting to work 4->16 hours after the information requestor has clocked out for the day. Phrasing requests for information "as email" is one of the most (if not the most) correct ways to structure these requests.
When RTT for a reply is measured in hours rather than minutes, you tend to pack a bunch of useful information in to your request. (As an added bonus, future searchers often only have to read one or two messages to understand what was being sought and and why, and whether or not it was found.)
What those folks have to say on the topic is pretty irrelevant. What is relevant is how specific people (or groups of people) are using these text-based-communication tools.
> I ask because approximately 0% of the people I've met have ever used Teams/Slack/etc. as email
I've been working at a largeish company with employees all over the globe. It's very common for its employees to have to get information from someone who will be reporting to work 4->16 hours after the information requestor has clocked out for the day. Phrasing requests for information "as email" is one of the most (if not the most) correct ways to structure these requests.
When RTT for a reply is measured in hours rather than minutes, you tend to pack a bunch of useful information in to your request. (As an added bonus, future searchers often only have to read one or two messages to understand what was being sought and and why, and whether or not it was found.)
I, and nearly everyone I've worked with, use Teams/Slack as async comms. Most of my colleagues are incredibly busy, so there's no expectation that we'll get an immediate, real-time, response. Generally, if real-time comms is needed, and the other party didn't respond via chat immediately, we ask "Can you jump on a quick call?"
What I've seen over the past 2-3 years is (company) email increasingly devolve most, though not all of the time, into announcements, automated workflow, and other FYI. If you're actually looking for a personalized response, even not immediate, the channel is chat in some form.
I don't like it really. Email was a respond in a day medium. Chat is now at least same day/hours. In general, people don't call out of the blue any longer though so chat is inevitably repurposed for pretty soon. I'm having to readjust workflows to that.
>the other party didn't respond via chat immediately, we ask "Can you jump on a quick call?"
That still asssumes they're always monitoring chat in near-real-time.
I don't like it really. Email was a respond in a day medium. Chat is now at least same day/hours. In general, people don't call out of the blue any longer though so chat is inevitably repurposed for pretty soon. I'm having to readjust workflows to that.
>the other party didn't respond via chat immediately, we ask "Can you jump on a quick call?"
That still asssumes they're always monitoring chat in near-real-time.
Not exactly, the “can we call” is usually to create a space to have that sync communication with someone but doesn’t always need to be immediate.
Rarely, I get a "Is this a good time to call you on your cell?" More frequently, "can we set up a video call soonest?" My point was, I don't know the last time I've had someone from work just call me out of the blue on my phone. And, honestly, there are only a handful of people outside of doctors/service people/etc. who do.
Back in the day, the phone rang--if not constantly--very frequently.
Back in the day, the phone rang--if not constantly--very frequently.
I definitely prefer the current way of working
That’s how I work. Email is basically just there for things that need to be in “writing” like approvals or various requests. Teams is where I communicate, I get msgs like “approval is in your email” because I only check email when asked to. If it’s urgent or requires a real conversation then it’s a teams call otherwise it’s all done through chat.
(I’ve been wfh for about a decade now)
(I’ve been wfh for about a decade now)
Just throwing in some anecdata but this is how it has been used in the place I've worked at since the pandemic started.
Prior to remote work being basically the norm these tools were used more like traditional real-time chat in my personal experience (I'm sure it varies even still based on particular workplaces), but now its generally async with the possibility (but not expectation) of being synchronous if you happen to catch someone randomly available to be bothered at the specific time you send the message.
Prior to remote work being basically the norm these tools were used more like traditional real-time chat in my personal experience (I'm sure it varies even still based on particular workplaces), but now its generally async with the possibility (but not expectation) of being synchronous if you happen to catch someone randomly available to be bothered at the specific time you send the message.
I remember Slack themselves seeing it as an email replacement, and not intended for remote work. It struck me as weird because I was on remote teams using it differently, and it felt as if Slack was out of touch with their own product. This was all before Covid.
I have also seen people camp their email and use it as chat. Some of them don’t like Slack.
I have also seen people camp their email and use it as chat. Some of them don’t like Slack.
A properly worded slack message is indistinguishable from an email, and can pretty much be treated as such
I'm not sure if it's an option to drop into real-time synchronous chat. Lots of places assume it's instant messaging, stress on the instant.
Maybe if there was an email client that looked a bit more like slack it could help those people transition into writing more meaningful messages.
Maybe if there was an email client that looked a bit more like slack it could help those people transition into writing more meaningful messages.
> "Nobody emails with just “Hi” and waits for a response"
I have to say, the zero-context "hi" in a Teams message has to be one of the worst violations of what we used to call netiquette.
I have to say, the zero-context "hi" in a Teams message has to be one of the worst violations of what we used to call netiquette.
> > "Nobody emails with just “Hi” and waits for a response"
> I have to say, the zero-context "hi" in a Teams message has to be one of the worst violations of what we used to call netiquette.
I am guilty of this, but only on MS Teams. If you want to setup an audio call where Person A wants Persons B and C on a call together, you set up a new group chat. On MS Teams, the Start Call is disabled until the first message. So I will often put "hi" as a chat starter. MS Teams doesnt seem to see a chat as a bona fide chat until there is some spark of conversation, hence "hi"
I am guilty of this, but only on MS Teams. If you want to setup an audio call where Person A wants Persons B and C on a call together, you set up a new group chat. On MS Teams, the Start Call is disabled until the first message. So I will often put "hi" as a chat starter. MS Teams doesnt seem to see a chat as a bona fide chat until there is some spark of conversation, hence "hi"
Ok sure, but your use case doesn't necessarily imply that the "hi" message is sent without any surrounding context (ie, a previous message(s) preparing recipient for a call). My complaint was about a lone "hi", preceded by nothing, and followed by nothing (ie, putting the onus on recipient to respond to signal readiness to discuss... who knows what). It interrupts potential flowstate, creates an open loop, provides no hint as to priority, eliminates possibility of leveraging power of async comms to close a loop, and guarantees recipient comes into the future interaction unprepared. It only takes a few extra seconds to provide context ("hi, I could use help understanding X when you get a moment, ideally today"), so NOT doing that is, IMHO, either ignorant or rude.
What I do is call person B and then when the call is started add person C. Usually in a group chat if I hit the call everyone button it’s by mistake haha
"Major open source projects, particularly the Linux kernel, are done entirely over email to great success."
This is a good model of how to collaborate, but it's also a bit self selecting don't you think? Unfortunately the reality at most day jobs is that a lot of people you work with are simply trying to get by.
This is a good model of how to collaborate, but it's also a bit self selecting don't you think? Unfortunately the reality at most day jobs is that a lot of people you work with are simply trying to get by.
All Communications are this way. I have no expectation on response time because those generally do not exist.
I have my deadline and SLA. How is make sure that these are well defined prior to taking on any task.
The ability to say to any level of management, I can do X and I can do y but I cannot do them both within your time constraints, is the superpower I wish I learned many years ago.
Yelling and screaming will not get it done.
Let's discuss your priority and get it done.
I have my deadline and SLA. How is make sure that these are well defined prior to taking on any task.
The ability to say to any level of management, I can do X and I can do y but I cannot do them both within your time constraints, is the superpower I wish I learned many years ago.
Yelling and screaming will not get it done.
Let's discuss your priority and get it done.
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
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
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.
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.
> I still get a "Hi" at least once a week. I've completely stopped responding to those.
A funny behavior I observed from those only-“Hi” people is that they will write their request after they don't get a response for a long-enough time.
A funny behavior I observed from those only-“Hi” people is that they will write their request after they don't get a response for a long-enough time.
"If I am available or not, please include your request in future messages so that I may fully respond in the event you're also not available"
Hi, bye, and thank you are implied. No need to say them in the course of business.
Hi, bye, and thank you are implied. No need to say them in the course of business.
> 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.
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.
It goes both ways. Everyone is busy. Consider the following result:
Helpdesk is typing...
Helpdesk: "Hi"
(entitled to ignore you forever if you don't say hi back)
(... you finally do so more than 20 minutes later)
Helpdesk: "what's the servicenow ticket number?"
(you create a ticket and then after some lengthy amount of time getting escalated/reassigned your ticket status is blocked and you're asked to call the helpdesk number at hours that suit them and not you)
Helpdesk is typing...
Helpdesk: "Hi"
(entitled to ignore you forever if you don't say hi back)
(... you finally do so more than 20 minutes later)
Helpdesk: "what's the servicenow ticket number?"
(you create a ticket and then after some lengthy amount of time getting escalated/reassigned your ticket status is blocked and you're asked to call the helpdesk number at hours that suit them and not you)
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...
https://handbook.gitlab.com/handbook/company/culture/all-rem...
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)
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)
> 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.
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.
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.
In my experience getting competing offers remotely is not easy, but gets easier once you landed a well paying job.
> You need competing offers, then it doesn't matter if they think you are greedy
For sure. I gave the example of asking for a raise, because of the way parent comment was phrased: “If a company really likes you”. When you have competing offers, it's not a matter of liking.
Having a competing offer doesn't make your pay independent of where you live though. If enough companies make your pay a function of cost of living, you will have a tough time reaching Bay Area salaries.
> whatever the f that means in work context
Can't agree more. Having seen spectacular failures from those who are supposed to be business-minded, I've come to appreciate that humans have their biases.
For sure. I gave the example of asking for a raise, because of the way parent comment was phrased: “If a company really likes you”. When you have competing offers, it's not a matter of liking.
Having a competing offer doesn't make your pay independent of where you live though. If enough companies make your pay a function of cost of living, you will have a tough time reaching Bay Area salaries.
> whatever the f that means in work context
Can't agree more. Having seen spectacular failures from those who are supposed to be business-minded, I've come to appreciate that humans have their biases.
Honestly the best thing you can do is get alternative offers - that is what talks.
In my mind it's easier getting a raise in a lower cost location. If the budget for a role is $200k for SF and $150k for Corntown Iowa, I already have $50k of wiggle room before I even hit the existing budget. But I personally just ask for the SF rate :)
In my mind it's easier getting a raise in a lower cost location. If the budget for a role is $200k for SF and $150k for Corntown Iowa, I already have $50k of wiggle room before I even hit the existing budget. But I personally just ask for the SF rate :)
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?
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.
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.
[deleted]
> 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.
Enough employers paying by location indicates that they have not bought into your assumptions here. What data do you have to convince them?
Enough employers paying by location indicates that they have not bought into your assumptions here. What data do you have to convince them?
Paying people way more than market rate in their area is a great way to trigger inflation in their area.
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.
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.
> 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.
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.
This is a really good point. This should be a reminder at the top of every stand-up notes document. :)
To clarify why this worked for us: our daily inspect-adapt cycle focused on things that would affect our sprint plan, so if everything was going smoothly we wouldn't mess with the plan. Hence offline updates were ok if there were no changes necessary. Our more general inspect-adapt cycle occured on a weekly basis with sprint planning - which was required attendance. Not quite as agile, but worked in our environment.
To clarify why this worked for us: our daily inspect-adapt cycle focused on things that would affect our sprint plan, so if everything was going smoothly we wouldn't mess with the plan. Hence offline updates were ok if there were no changes necessary. Our more general inspect-adapt cycle occured on a weekly basis with sprint planning - which was required attendance. Not quite as agile, but worked in our environment.
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.
If you don't have standup how does the PM waste an hour of your workday talking about their pet? That seems to be what standups are for at every job I've had with standups.
Eesh, we cap stand ups at 15min and that's often too long...
How big is your team?
How big is your team?
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.
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.
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.
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.
For the record, I struggle with timezone differences too. The non-async moments tend to always suck for someone.
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).
You should avoid getting yourself into situations like this. Why is your PR blocking anything if it's pending for one day? It's not just communication which needs to be async but the work itself should be too. Nobody should be stuck waiting for that PR - they should do some other work while they wait. I've been working for nearly ten years with a team that is split across four continents and everything is smooth. It needs cooperation and understanding from everyone to work well.
That's not a problem, it's a feature, and the article states that.
Sometimes it may feel like you're blocked or stuck and can't progress as quickly, but the benefit of having every single decision in written form and most of the complexity thoroughly documented greatly outweighs that.
I've been working as the sole person in my timezone (GMT-3) for sometime while my whole team is on CET. That was only made possible because everytime I get stuck, I'll search the company knowledge base and/or Slack and have consistently been able to find the information I needed to progress. This benefits my use case, but also saves invaluable time during incidents, avoids redundancy, duplication, contributes to continuous improvement and shields the product against knowledge turnover.
That's a relatively low price to pay for waiting a day for a code review every now and then.
Sometimes it may feel like you're blocked or stuck and can't progress as quickly, but the benefit of having every single decision in written form and most of the complexity thoroughly documented greatly outweighs that.
I've been working as the sole person in my timezone (GMT-3) for sometime while my whole team is on CET. That was only made possible because everytime I get stuck, I'll search the company knowledge base and/or Slack and have consistently been able to find the information I needed to progress. This benefits my use case, but also saves invaluable time during incidents, avoids redundancy, duplication, contributes to continuous improvement and shields the product against knowledge turnover.
That's a relatively low price to pay for waiting a day for a code review every now and then.
This is my experience as well, but it only works if there are fluid or no deadlines. As long as things progressively move every 24 business hours my product owners don’t seem too worried about the time spent waiting for another person.
On the flipside, it gives the other person hours instead of minutes to look at it before you get online the next morning, so they have time to actually think about it instead of just skim it and go "yeah, that's probably fine".
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.
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.
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.
> 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.
Sounds to me like you missed your deadline. How is that situation different than not being able to finish your work until your colleagues in the same time zone go to bed?
Sounds to me like you missed your deadline. How is that situation different than not being able to finish your work until your colleagues in the same time zone go to bed?
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.
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.
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.
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.
But the video meetings did seem cool.
Interesting read but pushes its agenda very hard. Six benefits to asynchronous work but zero costs?
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.
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.
> 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.
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.
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”.
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.
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.
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.
That's the engine room which goes to "you decide" and its one person's opinion.
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.
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.
- 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.
The desire to maintain control (or the illusion thereof) over its employees.
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.
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.
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.
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.
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.
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.
I’ve been working like that for years. I can’t come back from it
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.
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.
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...
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...
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!)
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!)
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.
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.
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.
What we really need are something like internal podcasts.
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.
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.
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.
Now would you describe that as synchronous or asynchronous?
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).
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).
> 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.
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.
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.
We have that weekly. I don't go but we do that. It gives management a summary. It wastes everyone else's time
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.
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.
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.
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]
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.