Knowledge Worker’s Communication Guide: Applying the Rules (part 5)

Perfect communication is HARD. We can only make it less bad. We can communicate better by fixing one bad practice at a time.

In the first part of this series, we dissected the belly of modern communication and got to know the Pieces. Then in the second part, I looked at how they relate with each other and what Rules we can derive from them. In part three, we mapped out some Steps we can take to ensure we are communicating as efficiently and effectively. In part four we wrote ourselves a Script to foolproof our outwards communication.

Now let’s step into the land of the concrete and attempt to distil everything we’ve learned so far into a list of practical Guides on how to navigate the world of Modern Communication.

We’ll answer questions such as: What apps do I need? For what purpose? How to select the best tool? What information should each document or piece of communication have? Which tool and medium is best for each Form? When would text suffice, when to do video? Do I Slack or do I Email?

Think of part 2 as the blueprint design and this as the implementation spec — the expanded version of the preliminary tactics we saw in part 1. In terms of Stages of communication (brain to brain data transfer), the things we talk about in this comm guide pertains more on the Explicit. We transact on / work with the Explicit (Data and Information) but cannot really measure or control the Tacit (Knowledge, Insight, Wisdom, and other related semantics).

First and above all: these are not hard rules. Keep your current workflow and team in mind. Experiment, pick what works, drop what doesn’t.


High level

  • Go out of your way to deliberately design workflow and tools to facilitate a) thinking and b) communicating.
  • Have a shared language to talk about these activities. Build that awareness on organisational level.
  • Be aware of whether you are thinking or communicating.
  • Be precise in your thinking.
  • Goal: the right amount of information for the right people, in the right form, in an adequate frequency. Give people what they need to know / do / feel, not everything you have.

Tools and Apps

gtioa-5-tools

  • Have a go-to / designated tool for each point in the Lifecycle (see part 1). Have a commonplace book — single entrypoint and destination. Make sure the tool supports (or you have the tool / process for)
    • Scheduling sync sessions (calendar apps, appointment slots)
    • The different methods of Documenting and Conversing (our Types) as needed. E.g. broadcasts, decisions, documents, discussions, process and progress.
    • The different levels of Urgency. Urgent communication usually mean it’s urgent to get the message out, but not all require immediate follow up action from the recipient, if any.
    • Acknowledging reception of high Impact communication.
    • Each direction
      • Converging. Anything with clear agenda and objectives. E.g. clarifying, deciding, managing ongoing tasks, actions, and progress, aligning, setting context, unblocking.
      • Diverging. Exploring, giving space for open ended discussions
        • Presenting ideas e.g. workshops, introducing changes
        • Developing ideas e.g. brainstorming
        • Watercoolers
    • Each atomic entity on the tool (e.g. comment, ticket, task, file) ideally has attributes such as Validity (revision history, replaced by, etc), Relevance (for whom), Context (description), State (In Progress, Completed, etc). These help document and determine the Impact (Duration, Depth, Breadth). See part 2 for more details.
  • If you have inefficient workflow and problems around communication right now, probably you have gaps in either:
    • a) availability of appropriate tool. Analye what is missing right now? Experiment with tools, then commit to using them.
    • b) usage best practices. See “Defining workflow and guidelines for tools usage” below.
    • c) data & tool hygiene. The biggest trap we all fall into. Everyone need to 1) agree on the tools, 2) how to use the tools, and 3) keep them up to date, accurate, and comprehensive. Floss your data and tools.
  • Always try and reduce friction and cognitive load / context switching. 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.

Defining workflow and guidelines for tools usage

“This is how we do it around here.”

  • Communication reception.
  • How to signal availability for appointments (have call slots, agreed upon overlapping working hours, etc).
  • Where to share the Content and Context (any documentation / artefacts) before doing the sync bits.
  • Design the incentives (why, what’s the consequences) for following the workflow.
  • Cultural sensitivity.
  • What topic is on and off limit.

On Project Management tools

  • Project Management tools are appropriate when level of urgency is up to the receiver, not the reporter.
  • Clear trace of documentation / proof is needed.
  • Ticket comments should be related to / explains the state of the ticket. Why something is moved to Backlog for example.

Forms and Medium

General

  • Text is less synchronous than speaking. It’s quicker to talk than type / write.
  • Text is good for keeping things on track and controlling the flow.
  • Image grabs attention. Image gives nuance. One image is worth 1000 ASCII chars.
  • Audio: humanity detected.
  • Video: more trust established. Allows distribution of non verbal cues.

Text

  • Message is less than three sentences: chat. More than that: Email.
  • IM / chat: getting a quick confirmation (Y/N), following up. OK to use even when there is only moderate shared context because it’s asynchronous. The participants can provide extra context / clarify / prepare in their own time.
  • Keep one text as atomic as possible. self containing. Replace implicit pronouns. “Did you ask him if what the results were?” -> “Did you ask Jim what the results of the 2019 Survey are?
  • Something that can wait: email. But emails can easily be overlooked or forgotten.
  • Need threading and branching? Don’t use email. Email is linear.
  • If the idea is still developing or is in exploratory stage, then a non-linear forms like calls are better than email. Real-time conversations are more branching-friendly, can accommodate questions and tangents. Can push and pull in a more frictionless way.
  • Emails need to be structured clearly and persuasively, or no one will read them.
  • Use email if
    • you have clear purpose or call to action.
    • you need to announce something.
    • you make less than 3 asks that can be fulfilled by an attachment or answered with less than 3 sentences each.
  • Indicates a bad email: “somebody should…”, “does anybody know…” (requires further decisions, opens up debates and some clarifications might be required)

Audio & Video

  • It’s generally quicker to talk compared to writing or externalising thoughts into tools (more interfaces to jump through hoops for. extra layers of processes and actions).
  • Calls are appropriate when you need immediate response. Best when there is maximum shared Context (no preparation needed), else you’ll risk wasting time communicating Context during the call (less efficient).
  • 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).

Type

  • Conversing: facilitates thinking. Prompting, patching context gaps, push and pull.
  • Documenting: (some) thinking done.
  • Some people prefer text (async comm.) than phone call (sync comm.). One possible reason is because they think of phone calls as documenting while it’s often conversing. They process their thoughts better asynchronously and are uncomfortable with idea of thinking out loud in real time conversations, sharing unfinished thoughts.
  • Rubber ducking: socially acceptable form of “speaking to process“. Thinking out loud, verbalising your thought process, debugging your mind.

Lifecycle

  • Capture
    • Have sync sessions to facilitate ideation (more effective. prompting, diverging, pull).
    • Have a solid workflow and tool to persist what came out of the sync sessions.
  • Process
    • Most Content and Context already captured in a shared tool / storage and acknowledged by the participants.
    • Can mostly be done asynchronously if all participants commit to using the tools and are aligned on the goals.
    • Don’t we need to meet occasionally and check in? Check part 8 for that.
  • Document and distribute (content and context)
    • Capture these in the tools.
    • Decide if there are other groups that need to be involved, plan and produce the communication accordingly (check part 3 for the steps to take).

You can do magic by weaving different Modes together appropriately (arguably, you need to). The key is to be mindful of all these tools and modes you can play with. In most real-world scenarios, you’ll probably go through all different stages:

  1. Voice and/or audio conversations: to get participants to a certain shared context. Conversations are best way to have non linear communication (can push and pull info more easily, handle branching off / diverging)
  2. Slack / instant messaging: to discuss where participants have a certain shared context established.
  3. Email: to broadcast decisions and agreements.
  4. Knowledge management systems: when we need to document the decision as policy or knowledge base item. This is then treated as the single source of truth (emails for example are more difficult to retrieve, reference, and distribute).

Let’s look at an example. Let’s say you want to kick off a new initiative. First you draft the high level proposal (Content and Context). You pitch the high level idea to your manager in your 1:1, then you engage your team who will help you in building the prototype in a team call. Your team will coordinate on Slack till the implementation is done. Then you released it to the stakeholders via email and a workshop session. Once done, you create the project documentation on Confluence.


Hi there. This post is part of Knowledge Worker’s Communication Guide series (need a more sticky name, any idea / suggestion on what to call this lens?)

Having a way to think about our communication will keep us stay mindful and communicate more successfully.

My working outline:

Leave a Reply

Your email address will not be published. Required fields are marked *