God, grant me the serenity to accept the things I cannot change,
courage to change the things I can,
and wisdom to know the difference.
— Reinhold Niebuhr, The Serenity Prayer
I’d like to modify that into….
God, grant me the serenity to mute Slack notifications, courage to reject meetings I didn’t schedule, and wisdom to differentiate:
– calls that should be emails, and emails that should be calls
– Zoom that should be phone calls, and phone calls that should be Zooms
– emails that should be chat, and chats that should be email
– chat that should be on Jira, and Jira comments that should be chats
— Knowledge Worker’s Prayer…, from the Remote Working Hymn, 2020
We parkour around emails, calls, video calls, Slack messages these days.
We meet, we interact, we communicate.
How can we make sure we communicate effectively and efficiently? Are we using the best medium? How can we minimise miscommunication? How to remove friction and bottlenecks? How can we reduce cognitive load?
We will look at Forms, Types, Modalities, Stages, and Lifecycle involved in communication architecture. From them we derived some Factors and Guide.
Information science, communication architecture, and knowledge management. My jam. Let’s get to it.
Note: If you’re short on time, jump ahead to “So? Give me some Tactics!” for practical takeaways before going back up to “Dissecting Communication” to geek out on the frameworks and principles.
Let’s first look at the different Forms of communication:
Then Types of communication:
- Documentation (one way. AKA: “you don’t need meeting for these, folks”)
- Info dissemination -> “Please confirm if received / understood / agreed to pledge your soul to this.“
- Tracking / evaluating progress -> “Please keep your CRM clean and up to date. CRM flossing!”
- Conversation (two ways). The two directions:
- Managing actions and progress (setting context, unblocking)
- Presenting ideas (workshop, training, introducing changes)
- Developing ideas (brainstorming)
And the types of Modalities:
- Synchronous (near real-time)
- Phone calls / audio meeting
- Face to face / conference calls / video meeting
- Asynchronous (non real-time)
- Chat / instant messaging (E.g. Slack, WhatsApp, Telegram, Signal, Twist)
- Project management systems (Jira, Asana, Basecamp)
- Documentation systems (Coda, Notion, Confluence)
Let’s now define these Stages of Data to Wisdom (loosely taking this DIKW framework for now):
- Data (facts, as neutral and atomic as possible)
- Information (interpreted Data — or conceptualised Data? structured Data? idk, still need to think about this)
- Knowledge (contextualised Information or applied Information?)
- Wisdom (actualised Knowledge?)
If we defined communication as transfer of explicit information (EI), I think an EI goes through this Lifecyle:
- First we capture it (sometimes involve transforming between tacit to explicit and vice versa)
- Then we process it
- And finally document it
Putting the Systems together
Now we bring them together into these Factors (Have refined these further in part 3 in this series):
Why do we need to communicate? Goal and purpose of the communication.
- To Document (converging. one way)
- To Converse (diverging. two ways)
Who are communicating? Human aspect.
- Nature of the communication (The proportion of logic and emotion involved. The more human, the richer the medium the better)
- Size of group
- The people involved (their styles and preferences)
What are we trying to communicate? Message aspect.
- Direction (one way, two ways) — relates to Goal of communication
- Density (Length, amount of detail, granularity. Determines level of preparation needed)
- Level of maturity of the message. The level of context and content (idea, topic, info) shared among the group.
- Impact (no need to converse about everything but probably need to document everything? still need to think about this)
So? Give me some Tactics!
High Level Guide (First attempt. Have refined these further in part 2 and part 5 in this series)
- Assign ONE tool for each part of the lifecycle.
- Keep your current workflow in mind. Always try and reduce friction and cognitive load / context switching. Have a commonplace book — single entrypoint and destination. E.g. if your team capture things on Slack, then don’t send an email if you need another thing captured. If you process things on Jira, don’t pop a task into Trello or Asana and hope it’s being handled. If you document on Confluence, don’t… you get the idea.
- Calls are appropriate when you need immediate response. Best when there is maximum shared context (no preparation needed), else you’ll risk wasting time giving context during the call / less effective.
- Something that can wait: email. But emails can easily be overlooked or forgotten.
- Text is good for tracking and controlling flow, keeping things on track
- Message is less than three sentences: chat. More than that: Email.
- Need threading and branching? Don’t use email.
- Emails need to be structured clearly and persuasively, or no one will read them.
- Emails are not for documentation.
- IM / chat: getting a quick confirmation (Y/N), following up. OK when there is only moderate shared context. The participants can provide extra context / clarify / prepare.
- PM tools are appropriate when:
- Level of urgency is up to the receiver, not the reporter
- Clear trace of documentation is needed
- Ticket comments should be related to / explains the state of the ticket. Why something is moved to Backlog for example
- A conversation is going to naturally provide deeper context, easier to absorb / interactive, pull and push.
- Audio is OK for simple exchange of information / clarification. Or when multitasking is OK (mind the Zoom fatigue).
- Video is better if need to gauge reactions or discuss difficult or challenging topics (emotion involved).
- Calls best practice: Start with an agenda. This makes it easier to take note and document the outcome. Else, have a scriber to keep track of what’s been discussed, asked, answered, agreed upon.
- If still developing / exploratory, calls are better than email / other linear forms (real-time conversations are more branching-friendly, can diverge / accommodates questions and tangents).
These are not hard rules. Combine, use your instinct, improvise.
And going back to the theme of this publication: “Getting things into, out of, and across heads”. I realised I am essentially trying to capture, explore, and describe the processes of:
- Transforming between explicit to tacit (“into heads”)
- Transforming between tacit to explicit (“out of heads”)
- Efficiently transferring the explicit in a form that allows effective transformation (“across heads”)
( TODO. For now, imagine a circle with arrows here 🙂 )
Also published on Medium.