Do you hate messaging someone for a quick clarification,
and waiting and praying that they see the message,
and then anxiously staring at "X is typing..." for several minutes ?
Do you find it irritating to setup calls/meetings just to explain a tiny detail?
In modern teams that believe in "Agile" and "Open Communication",
a common trope is...
When someone gets stuck or needs help,
then quick in-person discussions are so much nicer
and get the job done instantly.
While this sounds great at first sight, closer inspection reveals the massive overheads such an approach introduces. Imagine you are being invited for "quick discussions" by 3-4 people in your team whenever they get blocked every couple of times a day. Some of which often require multiple extended back-n-forth discussions. Your entire day is spent catering to their interruptions (though not "constant interruptions" for any of them individually, but a constant stream of interruptions for you.)
In such a scenario, a common technique to avoid being a bottleneck, is to have such discussions in written down form, in wider/public chats, bug-trackers, task-trackers, wikis (not direct-messages, not voice/video-calls, not face-to-face in-person chats).
...so that the folks who get stuck,
- ...can first search for previously "asked-and-answered" stuff
in the above wider/public channels of communication. - ...and even if someone misses a previous discussion and approaches you,
you can now quickly point them to previous written down notes/comments/guides from your memory (or using search features of the communication tools).
An added bonus of this approach is often you can find your own notes/guides in search results and thank your past self for saving 2 days of breaking your head trying to find a workaround for a weird corner-case which you have previously encountered and solved.
 |
| (least-expensive) A < B < C < D (most-expensive) |
Meetings, Calls, Chats, Emails, Wikis, Documentation, ...
Various communication modes vary in their costs they impose on the participants.
Costs include time and effort in the form of...
- duplicated/recurring communication that can be avoided.
- disrupting the participants' schedule/flow.
- fragmenting the participants' calendar
- reducing slots for deep/heads-down work.
Common pitfalls that prevent efficient communication are:
- Using mode-D when mode-B or mode-C would suffice.
- Not investing time upfront regularly to develop sufficient mode-B.
- Not establishing clear expectations about "what is mode-C in the team".
- Not teaching/learning how to be great at mode-A.
the principles and best-practices of asynchronous communication,
checkout Gitlab's guide to Asynchronous Communication.