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)

http://threevirtues.com/

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

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

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

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

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.

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.

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

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.

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

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

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.

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

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.

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.

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.

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

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.