How to embrace asynchronous communication for remote work

https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/

by serial_dev • 2 years ago

189 93 2 years ago

handbook.gitlab.com

ergonaught• 2 years 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.

VectorLock2• 2 years 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• 2 years 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• 2 years 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.

mwigdahl2• 2 years 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• 2 years 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!)

teeray• 2 years 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.

jodrellblank2• 2 years 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• 2 years 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.

VectorLock2• 2 years ago

Now would you describe that as synchronous or asynchronous?

JamesLeonis• 2 years 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• 2 years ago

We have that weekly. I don't go but we do that. It gives management a summary. It wastes everyone else's time

ryandrake2• 2 years 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• 2 years 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.

thih92• 2 years 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”.

mocmoc• 2 years ago

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

karaterobot2• 2 years 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-rem...

roland352• 2 years 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)

laserlight4• 2 years 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.

ip26• 2 years ago

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?

karaterobot2• 2 years ago

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.

ambicapter• 2 years ago

Paying people way more than market rate in their area is a great way to trigger inflation in their area.

pizzafeelsright3• 2 years 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• 2 years 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.

digging2• 2 years 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.

out-of-ideas• 2 years ago

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

pizzafeelsright3• 2 years ago

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.

chrisweekly2• 2 years ago

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

kylestlb• 2 years ago

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

dheera• 2 years ago

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.

digging2• 2 years ago

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.

laserlight4• 2 years ago

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.

sublinear• 2 years ago

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)

robertclaus2• 2 years 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• 2 years 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• 2 years 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• 2 years 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.

robertclaus2• 2 years ago

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.

cdchn• 2 years ago

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• 2 years ago

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

lifeisstillgood• 2 years 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• 2 years 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• 2 years 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.

ajb• 2 years 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.

deprecative2• 2 years 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.

TheRealWatson• 2 years 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• 2 years 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).

SamuelAdams• 2 years ago

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.

Rohansi• 2 years ago

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.

guhcampos• 2 years ago

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.

Izkata• 2 years ago

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

laserlight4• 2 years ago

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?

ggm2• 2 years 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• 2 years 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.

ggm2• 2 years ago

That's the engine room which goes to "you decide" and its one person's opinion.

shepardrtc• 2 years 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.

gilbetron2• 2 years 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• 2 years 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.

48864w6ui2• 2 years ago

Pro tip: for software, async is usually better, even among colleagues who share a physical office.

gilbetron2• 2 years 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• 2 years 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• 2 years 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• 2 years ago

The desire to maintain control (or the illusion thereof) over its employees.

thih92• 2 years 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.

48864w6ui2• 2 years 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• 2 years 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.

How to embrace asynchronous communication for remote work

Related Stories