I have an objection to the author's blanket disregard for "pings" in chat - while the request could/should be worded a bit more clearly than just "ping", IMHO they're a valid way of requesting if an opportunity for synchronous communication is available in the (not that rare!) cases where asynchronous communication would be worthless.
If someone's blocking on some unclear thing which requires external input for progress, making an asynchronous request (i.e. writing the question directly) is not helpful since in such a case an answer is valuable if and only if it's synchronous. Writing a chat question that gets answered the next day has negative value, since it has the extra cost of the answerer reading the question and preparing the (now useless) answer.
If the other person is available for synchronous communication, that's great, there's an opportunity for a useful communication.
If the other person is not available for synchronous communication right now, that's fine as well, but then the replacement is not asynchronous communication with that person but instead something else that can actually be done right now - contacting someone else who is available, or doing some redundant experimentation/research, or just proceeding with an assumption that may later be falsified, etc, all of which aren't optimal but still clearly preferable to blocking until an asynchronous response arrives.
Sure, things can be done 100% asynchronously eventually, but that's not an optimal flow, going 100% async requires giving up many opportunities for helpful communication. Especially in international organizations I've far too often seen things delayed by days or even weeks where literal ten minutes of a synchronous comms (no matter if it's a phone call or chat or video) was completely sufficient.
Perhaps I'm looking at 100% async as an optimization on allocating time for communication that has some benefit of throughput - having more efficient schedules for people working - at a horrific sacrifice of latency - having much less effective schedules for resolving individual tasks.
Pings would be useless (and I'd concede that even harmful) in a world where status indicators in a chat app reasonably match actual availability for synchronous communication right now, but I don't live in such a world, people are routinely marked as "active" while they're working in meetings or deep work and don't want to be disturbed, and the opposite way around; so there needs to be some protocol of requesting synchronous communication - are there any ways that are substantially better than "pings"?
Even in the case where the explanation of the question is quite long, I think the onus is still on the asker to give information for the reciever to prioritise it. Because sometimes my availability for the discussion depends on how important that is versus my current task.
Need help debugging your CI build while I'm just churning out unit tests for my run of the mill work? Sure, I'll take up that discussion.
But hey, what if I'm working on a gethering data for a presentation to stakeholders tomorrow? Then your CI build has to wait.
But wait, what if you're debugging production being down? Well then you know what, my feature can wait.
So "I need help with <X> so that I can <Y>, are you around for a chat?" is ok. I can make a judgement call here and give you an answer.
"Ping"/"yt"/"Can we talk?" is not. You give me no information to prioritise your request.
Okay, that's a good point, a "ping" with sufficient context about the priority is a clear improvement.
I saw the original article's recommendation to add "no urgency" when appropriate, but the type of requests I was thinking about are those that actually are urgent but not that important, where it's no big deal if you can't answer right now, but then we'll proceed without your input at all instead of waiting for it.
If someone's blocking on some unclear thing which requires external input for progress, making an asynchronous request (i.e. writing the question directly) is not helpful since in such a case an answer is valuable if and only if it's synchronous. Writing a chat question that gets answered the next day has negative value, since it has the extra cost of the answerer reading the question and preparing the (now useless) answer.
If the other person is available for synchronous communication, that's great, there's an opportunity for a useful communication.
If the other person is not available for synchronous communication right now, that's fine as well, but then the replacement is not asynchronous communication with that person but instead something else that can actually be done right now - contacting someone else who is available, or doing some redundant experimentation/research, or just proceeding with an assumption that may later be falsified, etc, all of which aren't optimal but still clearly preferable to blocking until an asynchronous response arrives.
Sure, things can be done 100% asynchronously eventually, but that's not an optimal flow, going 100% async requires giving up many opportunities for helpful communication. Especially in international organizations I've far too often seen things delayed by days or even weeks where literal ten minutes of a synchronous comms (no matter if it's a phone call or chat or video) was completely sufficient.
Perhaps I'm looking at 100% async as an optimization on allocating time for communication that has some benefit of throughput - having more efficient schedules for people working - at a horrific sacrifice of latency - having much less effective schedules for resolving individual tasks.
Pings would be useless (and I'd concede that even harmful) in a world where status indicators in a chat app reasonably match actual availability for synchronous communication right now, but I don't live in such a world, people are routinely marked as "active" while they're working in meetings or deep work and don't want to be disturbed, and the opposite way around; so there needs to be some protocol of requesting synchronous communication - are there any ways that are substantially better than "pings"?