[PragmaticPulp]

I've managed multiple remote, asynchronous teams across multiple countries. When people work in opposite time zones, asynchronous communication is mandatory.

When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-time conversation rather than 3 days of back-and-forth e-mails. If the team is willing to fall back to synchronous comms when necessary, then defaulting to async communication for the other 95% of communication can work.

In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs, no matter how slow and inefficient it becomes for everyone else. All team members must be willing to recognize when synchronous communication is necessary and carve out 15 minutes to an hour a couple times a week for those important, synchronous conversations.

Efficient communication is everyone's responsibility, and asynchronous communication is only a win if it doesn't create unnecessary extra work for everyone else.

[bloopernova]

I think that there is a tragedy-of-the-commons issue here that some teams or organizations just aren't very good at tackling.

Everyone's time is a valuable resource. It's quick and easy to demand synced communication, but that depletes the time people can dedicate to longer tasks that should not be interrupted.

Now take the team's collective time. That's the commons, and poor work discipline drains that shared resource. It takes discipline to write procedures, policies, boring documentation, or to make sure that the authoritative source of truth for your project still reflects reality.

Those 3 days of back and forth emails, or the 15 minute working session, may need to exist for some situations. However I've found that people can work to reduce those 3 days to several hours as long as the answers to some questions are available in up to date documentation.

I have a couple of team members right now who don't want to write certain documentation, or don't feel they need to edit existing documentation to improve its legibility. The most often heard excuse has been "it only takes me 15 minutes on a call to do the task". Which may seem fine from that perspective. That person doesn't realize that they've spent multiple days worth of hours spending 15 minutes on something when if they had spent 2 hours writing the documentation, they'd be saving precious time and priceless context switching.

(I'm a new team lead. I'm enjoying it greatly, and find these sorts of inefficiencies both fascinating and revolting)

[pacaro]

This is exactly where writing docs epitomises Larry Wall's "laziness" virtue.

http://threevirtues.com/

[xsmasher]

I know this is quoting a classic text, but "Hubris" bugs me here; it seems like the virtue being describe here is pride or ego, not hubris.

Hubris implies excessive pride and ambition; pride that is oversized when compared to your ability. It has a negative connotation.

[pacaro]

IIRC the camel book cautions about excesses in each of these "virtues.

I've always been amused by the concept of "excessive hubris"

[bloopernova]

A lot of my "formative years" in IT were spent in several Perl environments, but it's been a while since I heard those 3 virtues so succinctly put. Thank you :)

[pacaro]

Thank whoever put the website up!

The text is pulled verbatim from the camel book[1].

I somehow assume that "everyone" has used or had access to a well thumbed copy of the camel book, but realize that it's a product of place and time

[1] Programming Perl https://g.co/kgs/ZnNHTJ

[coldtea]

>When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-time conversation rather than 3 days of back-and-forth e-mails.

I always hated "15 minutes of real-time conversation", not because of being an introvert or anything, but because it's fuzzy, nobody remembers what it was exactly said, and usually ends up with people wasting each others time (like Diltert-style meetings).

I'd much rather people knew how to communicate effectively on chat.

But people don't, so you get messages like:

"The service is broken!"

"[panicked] What do you mean? Is it down?"

"It doesn't show anything"

[still panicked] Really? Let me see... Hmm, I see it working properly, loaded the first page and everything. What do you see?"

"I don't see anything"

"[???] On the first page? On some specific panel? Have you entered something?"

"Entered? I clicked and got nothing"

... and after 20 more minutes you realize they are on the third tab of a particular page, which nobody ever uses, have entered some search term people seldom enter, and got no results there, and everything else is working fine...

[jerf]

"I always hated "15 minutes of real-time conversation", not because of being an introvert or anything, but because it's fuzzy, nobody remembers what it was exactly said, and usually ends up with people wasting each others time (like Diltert-style meetings)."

I'd say the solution is to attack those problems directly.

There are some things that just work poorly asynchronously. I find heavy-duty explanations of something, where you need the highly-interactive back-and-forth is necessary, and honestly, even just trying to type something is wasting minutes vs. saying it, is a common use case for me. Getting 4 half-distracted managers who are lobbing emails at each other into a quick conference to resolve the matter is sometimes a really good idea, too, because the "lobbing emails at each other" is a political minefield. A lot of potential for hurt feelings and miscommunication that can be avoided just getting everyone in live voice chat, with their full attention, for even just 5 minutes sometimes.

[serpix]

4 managers to one dev is a ratio that warrants a very quick change of jobs.

[jerf]

No, I mean, some sort of cross-team functionality where you need broad agreement, not four managers all trying to manage literally the same thing.

I probably do more cross-team stuff than the average dev, but in anything beyond a trivially-sized organization, managers are doing it all the time.

[xboxnolifes]

> I'd much rather people knew how to communicate effectively on chat.

> But people don't, so you get messages like:

So what you're saying is that you don't actually mind the 15 minutes of real-time chat, what you mind is that some people don't know how to effectively communicate.

[organsnyder]

I actually enjoy real-time meetings, as long as a few conditions are met:

1. A concise, realistic agenda is distributed to all attendees beforehand, and actually followed 2. A single person takes concise notes, with a heavy focus on action items and official decisions; the notes are distributed promptly at the end of the meeting (or better yet, real-time via a shared document) 3. Each action item is given a single assignee and realistic deadline

Your chat example seems like it could be solved with a 5-minute screenshare.

[thrower123]

This is one of those cases where a picture is worth a thousand words. It's amazing to me sometimes how many support requests I get where there is no information about what is wrong, no screenshots, no log files, not even a couple sentences about what they were trying to do and what they expected to happen.

Although it's almost worse when they send along a JPEG screenshot that has been downsampled >50%, so all the details are too blurred to make out.

It's especially frustrating when you're dealing with timezone shifts that make the average time to get a round-trip email reply from the other person take a dozen hours or more

[meowface]

"Hi"

[says they're typing, work on something while I wait]

[6 minute pause]

"Are you there?"

"Yes"

"I'm getting an error when using [tool]"

"What's the error?"

[2 vague barely related lines in a long error message or traceback]

"Could you show me the full error message and the command you tried to run, please?"

By the time the full troubleshooting process is over (which usually amounts to "follow the instructions in the error message"), I've lost track of whatever I was doing and wasted who knows how much time.

[rgoulter]

This is the thesis of http://www.nohello.com/

[alexandercrohde]

Better to figure that out in a 15-minute sync up than to get a pager duty alert from a Blocker level ticket that your "service is broken"

[manifestsilence]

I think the chat in this example still basically counts as synchronous, and the issue is more to do with people being poor at organizing their ideas in text vs. spoken conversation.

Truly asynchronous communication would force them to put their whole thought down on paper at once and perhaps organize it better, or at least allow you to skim. But then of course, async is poor for time sensitive issues anyway.

[DoreenMichele]

Many years ago, I did some volunteer work at a homeless shelter. The second highest person there was not tech savvy but had to fill out a lot of their paperwork.

She once thought she had "lost" her entire spreadsheet because she scrolled too far down to a blank section of the spreadsheet.

[k__]

"In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs,"

In my experience, the biggest pitfall is when non-developers try to force 100% synchronous communication at all costs.

I always had the experience that there is a struggle to get people to accept async work because everyone thinks it's normal to call everyone all the time.

[t34543]

I couldn’t agree with this more. My org is full of people who love meetings. On average it’s 30 hours of meetings per week, absolutely insane. I’ve been training people to not invite me so it’s down to 10, but still higher than I would like.

[k__]

This.

I don't think 100% async is the way, but I think it's easier to end up with too much sync than with too much async.

[openthc]

Balance. Chat on mattermost for all day noise, dm and open webconf for the Swarm on the problem, combined notes on ticket for historical.

[k__]

Most is also cultural fit.

Some peole need three calls until they understand what I'm telling them.

For others it's three slack messages a week and we are all good.

[marcelo_lebre]

Agreed. Async communication doesn't belong in sync situations nor vice-versa. Trying to solve everything with one strategy is indeed an anti-pattern.

[lukethomas]

Here's a helpful rule of thumb for when to use synchronous communication:

Is the conversation ambiguous and is there a high likelihood that you will be misunderstood?

An obvious tell for this is when you go back-and-forth over Slack/chat for a few minutes and people still feel like they are on another page.

I strongly recommend checking out media richness theory. It presents a helpful way to think about what communication medium is most appropriate for a given scenario.

https://en.wikipedia.org/wiki/Media_richness_theory

[hanniabu]

This has 100% been my experience as well. All too often it's seen as an all or nothing thing, and it's the parts where discussions should be handled on calls that give it a bad image.

[albertzeyer]

How exactly would you identify such a situation when a real-time conversation is more productive? And do you think that everyone involved agrees in the same way on this?

It would be interesting to analyse such situations further, and maybe there are actually ways to resolve it in a more productive and efficient way which does not require real-time conversation.