The communication debugger
I use a checklist I call "the communication debugger" to clarify the main characteristics of a channel. The goal is to clarify how and when to use it. We want to reduce the risk of people not knowing if consuming a channel is required for their role and how to best use it to share information. Here is the checklist:
- Do we need to store the information we share via this channel?
- How relevant is contextual understanding?
- What's a good media for this channel?
The order in which you ask these questions is relevant. If you want to live by the principle share everything by default, you need to think of every channel as optional and accessible at the same time. A high level description of each channel that answers these questions gives people a clear indication of how to use them.
Nowadays, companies have so many ways of sharing information that people often feel overwhelmed. As a response, some cope by muting as many channels as possible. It's only human to react this way, but it comes with problems. People don't know what they're missing any more and have no chance of adjusting over time.
A practical example is error notification emails: the more your system grows, the more non-actionable emails people receive, so they start creating rules to reduce the noise in their inbox. One day something breaks and no one saw it coming, right? You could say it's an engineering problem, but it's not. It's a flaw of your communication infrastructure. Let me show you how I would use the communication debugger checklist for error notifications:
-
Do we need to store the information we share via this channel?
Do people know why these emails are relevant? Do you store the information anywhere? Can it be retrieved for later analysis?
-
How relevant is contextual understanding?
Do people understand the exceptions? Are they receiving messages they don't understand because they've never worked on that part of the system?
-
What's a good media for this channel?
Is an email with a stack trace the best media? Would graphs work better? Should we notify people of problems with different media depending on the severity of the problem?
Answering these question helps you design a good infrastructure for the channel "system failures". Depending on the size of your teams, their structure, and responsibilities you can choose the tooling, group exceptions, create new workflows, automate issue creation, and then solve them.
In the rest of the chapter, I use the communication debugger in many examples. It's useful to determine features and usages of different channels. The communication debugger may not help clarify the temporal aspect of channels. Developers spend a great part of the day dealing with the written word. They write code, discuss it in pull requests, write comments about features, describe a bug in an issue tracker, and many other activities. They write so much that it's hard to distinguish between written words that only matter right now and those that matter long term.
To cope with this, I group communication channels in volatile and permanent. Volatile channels concern the present or the immediate future. Permanent channels concern your long term communication.