As a geek, I love async communication. It allows an individual to focus on the immediate task in hand and only 'come up for air' once the focus is no longer required. As a manager, clients often demand realtime information on what's happening and want more synchronous communication. It's a difficult one to balance, but can be overcome via better expectation management from the start.

What is asynchronous communication?

Asynchronous communication is best explained by using a tangible example. Whatsapp and email don't require an immediate response for the information to be useful. As a sender, you get confirmation that the message has been received, but not necessarily acted upon until the receiver, but once the receiver has capacity to process it. The receiver, rather than the sender, decides in which priority order to parse the received messages.

What is synchronous communication?

In synchronous communication, the sender has complete control. They send the message effectively saying 'stop all tasks until you have an answer to X,' and everything stops whilst the message is processed and a suitable response given back to the sender.

How to choose what's right?

It's often a requirement to include both systems when dealing with computer systems.  AngularJS and many JavaScript frameworks rely on the former method to make sure that the application doesn't get 'blocked' on doing the important when the urgent requests come in.  This is of much practical use as the application knows that even if someone is asking for X, they still expect A,B,C,D,E,F,G... to happen as normal (you get the picture).

As a manager, I have to rely on the expertise of the people I manage to get the job done.  I like to think that I try and make sure that my communication methods enable the team to focus on the important, and that I can do the job of 'managing' the urgent on their behalf and acting as a buffer between them and the client.  In a quasi-agile environment this is enabled through developers providing high-level estimates of the tasks that they're undertaking, and a mutual understanding that whilst they are working within their estimates that they carry on uninterrupted, but as soon as an issue occurs that affects the accuracy of the estimate then they revert to me as quickly as possible so deadlines can be managed.

What about people?

People will always demand synchronous communication.  Despite the wonderful invention of email, slack and other online messaging systems - people will always want to pick up the phone or speak face-to-face for an immediate update on the task in hand.  To communicate correctly at this level you need to be focusing on outcomes, not tasks.  It's a tricky job to manage and I'm still getting plenty of experience in what works (and what doesn't) - but stick to your guns.  If you're managing developers they need protection to work on the important, not the urgent.  Keep this principle in mind and you'll end up with happier developers and a more stable releases.