How to embrace asynchronous communication for remote work
handbook.gitlab.com
handbook.gitlab.com
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.
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.
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.
Back in the day, the phone rang--if not constantly--very frequently.
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’ve been wfh for about a decade now)
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 have also seen people camp their email and use it as chat. Some of them don’t like Slack.
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.
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 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 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"
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.
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.
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.
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.
Hi, bye, and thank you are implied. No need to say them in the course of business.
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)
https://handbook.gitlab.com/handbook/company/culture/all-rem...
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)
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.
In my experience getting competing offers remotely is not easy, but gets easier once you landed a well paying job.
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.
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 :)
Enough employers paying by location indicates that they have not bought into your assumptions here. What data do you have to convince them?
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.
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.
How big is your team?
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.
For the record, I struggle with timezone differences too. The non-async moments tend to always suck for someone.
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.
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?
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.
But the video meetings did seem cool.
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'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.
- 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.
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.
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.
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.
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.
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 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'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.
What we really need are something like internal podcasts.
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.
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 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.