Volatile channels
Volatile channels are trickier to discuss than permanent ones, so I start with them:
- They're the most used channels because that's where every-day communication happens. For this exact reason, they are often misused: communication that belongs to a permanent channel happens in the wrong place.
- Almost all of the volatile communication ends up in chat systems.
Misusing volatile channels is tragically common in our industry. Since most teams use chat systems for their day-to-day communication, chats tend to get the blame for the overall status of their communication infrastructure.
Instead of trying to come up with a sensible list of volatile channels that works for everyone, let me use the communication debugger to define the scope and goals of a volatile channel:
-
Do we need to store the information we share via a volatile channel?
There is no need to store any of this information. Pull requests are again a good example: many tools store it and it's a "nice to have". But the point to stress here is that the data going through this channel is relevant only at the time of sharing. The perfect segue for the next question.
-
How relevant is contextual understanding?
Everyday communication almost always requires contextual understanding. Are we shipping this feature today? What's your opinion on the candidate we interviewed this morning? Are we meeting this afternoon to discuss how to improve the performance of that system? These examples have two things in common: the information is relevant right now and contextual understanding is required. It's hard to discuss any of these topics if the information isn't fresh in people's minds.
-
What's a good media for this channel?
The media isn't relevant here. The only two requirements are: people are fine using it and everyone has access to it.
In short, everyday communication channels have the following properties:
- Storing data isn't relevant.
- High contextual understanding is OK, often required.
- The media doesn't matter as long as it's inclusive.
With this in mind, I strongly encourage you to debug your existing channels. Chances are your teams are already misusing one or more channels. Identifying these false positives can have a great impact. Team productivity increases if conversations happen in the right channel: less noise, more focused communication.
Status updates
Most product development teams follow an iterative approach to building products, so status updates are a relatively common practice. You may want to tell the rest of the company about the latest release or share how you solved a difficult challenge. These are just a few examples of a communication practice that has the following traits:
- It happens on a regular basis.
- Information is broadcasted.
- It's often a pain to maintain, mostly because of its cadence.
On the surface, it may not be obvious why this form of communication is an instance of volatile communication, so here comes the communication debugger checklist to the rescue:
-
Do we need to store the information we share via this channel?
The meaning of a status update is strictly connected to the time in which the update happens: it describes progress or the lack of it. That means long-term storage isn't a requirement. Sometimes, it helps to relive the progress the organisation has been making over time, so I would consider storage a "nice to have".
-
How relevant is contextual understanding?
It's fair to assume some contextual understanding of what's being shared. Updates would be unreasonably boring to read if they don't rely on prior knowledge. One thing I have seen working well is providing reference links: it's a way to enrich the new feature you are discussing with existing documentation and good examples. That way people with less context can dig into it if they need.
-
What's a good media for this channel?
Broadcasting is the only strict requirement, so it's tempting to use a public channel of your chat system. That can work but, if I had to choose, I would go for a newsletter. First of all, newsletters feel more asynchronous than a chat. That releases people from the pressure of immediate consumption. Most people want to stay up-to-date with what's going on in the company, so reducing the pressure sends the message that you care about their needs. Another interesting aspect that comes handy while you scale teams is the aggregated analytics data you can gather. It helps you understand how to get better at sharing updates and communication in general. More about this in The kaizen of communication.
Status updates are a great way of exploring the mismatch between:
- What team members think they need to know.
- What team leaders think team members need to know.
Of course the truth lies somewhere in between and finding a balance is the hardest part of getting communication right. Using the right kind of channel for your status updates can have a positive effect on the culture of your teams and their efficiency. Engaged team members help you debug the misunderstanding and misalignment in your updates. That's a great side-effect. Keeping people aligned is an important responsibility of leaders and doing it at scale without support isn't feasible.
Meeting notes
Meetings are non-inclusive by definition as they don't follow the share everything by default principle. Using meeting notes as a communication channel can be of great benefit. It's enough to share them using one of the media you use for everyday communication, so a chat system would be fine. I encourage, sometimes even require, note taking and sharing because it helps both ways:
- It's a great example of a volatile channel.
- It helps to ensure that people understand what the point of meetings is: to reach a shared agreement. The habit of writing down outcomes and sharing them helps the attendees as well because they go into meetings focused on the outcomes. It also helps people that didn't attend the meeting. They don't feel excluded and can check the outcomes.