Messaging-based communication tools such as Slack and Microsoft Teams are commonplace in development teams, often being the main platform for textual communication. “Channels” are a key concept in these tools for organising communication. How these are organised and used makes a big difference to their effectiveness and in turn the overall effectiveness of the team communication. In this post, I’ll share my thoughts on what makes a good approach, and provide some example channels based on what I’ve seen work well in projects of various natures and sizes.
This won’t be specific to any particular tool; the concepts and features I’ll be referring to mostly commonplace in all of them. Many or most teams will be using whichever tool their organisation provides. Although all serve the same basic need, some are certainly superior to others and better lend themselves to enabling effective communication and collaboration.
Why it’s worthwhile
If your channels are a mess, it will tax your productivity and sanity. Communication will become a time sink, you’ll always be distracted and overwhelmed by things to read, people will miss important things, you’ll be waiting for answers, … the list goes on. Left to be established, used, and evolved organically, that’s how it tends to become.
What works for different teams, team sizes, and contexts will vary. You’ll need to work out something to suit, taking ideas from the people around you and perhaps this and other blog posts. You don’t need to start with 20 channels. Keep it under review as time passes, the project grows, or things change. Delete dormant ones, create new ones, clarify/remind and refine purposes.
Desirable characteristics
Regardless of which channels you have specifically or how they’re used, there are a couple of outcomes you’ll want and others to avoid (essentially the opposite of the former). Some will depend on your context and your team’s preferences.
Signal to noise. Nobody should have to scan through lots of irrelevant messages to find what they want, or just in case they miss something important in the middle of it. We can divide channels with consideration to areas of interest and people, and can use threaded conversation for deeper specific conversations. We only add bots which add value without causing disproportionate noise, and we consider which channels they participate in and how they’re configured.
Focused work and concentration. We should be able to focus on deep work, without needing to constantly keep up with streams of messages and notifications. Not everything is urgent/important needing immediate reading or replying. We can separate channels so different people/roles can decide and configure what’s brought to their attention, and what can be caught up with once or twice daily (or rarely, or not at all).
Quick turnaround when it matters. When a problem needs urgent attention, or someone is stuck needing help or an answer, they should get it promptly. By keeping channels relevant and reducing noise, we can help ensure that when time is of the essence, someone does pick up quickly.
A place for everything, with a welcome. There should be somewhere to ask or talk about anything anyone wants to. If we have a dozen group chats with various similar combinations of people, or are using meeting chats as the go-to place to message each other, then maybe we’re missing a channel. There should be general places to post a message if someone’s not sure where/who to ask, and we don’t need to be sticklers for absolutely always using the ideal channel for everything lest we discourage their use.
Supporting practices and perspectives
Staying specifically on the topic of channels, setting up a good structure isn’t sufficient on its own.
Discovery and membership. People need to know the channels exist, and be members of the relevant ones. Some tools’ features and conceptual models better lend themselves to achieving this than others, so some documentation may be required. In any case, some effort when new people join the team or new channels are created. All this is a lot easier when channels are public, so I’d recommend only making channels private when it’s necessary (e.g. sensitive matters) or highly beneficial.
Expectations and protocol. Establishing some do’s and don’ts helps achieve the desirable characteristics I mentioned earlier, and avoids things descending into unhelpful practices. One helpful starter is agreeing to read and respond in certain key channels, i.e. not to ignore them – which can lead to it seeming necessary to tag/mention (@) everyone on every message that’s posted. Some channels (e.g. team) may be higher priority than others. You can also establish conventions of using emoji reactions to give others quick at-a-glance visibility of if something’s being looked (eyes) at or has been resolved (tick) without needing to read lots of messages.
Education and keeping on track. For all this to work well in a busy environment, people need to know about it and adhere to it. New joiners to the team will need to have it explained, and counter-optimal practices need to be nudged to use better ways or places. Documentation may be beneficial. Evolve it as things change over time, by e.g. creating new channels to supersede group chats. Explore and share tips on how to configure notification settings in your messaging tool. Raise awareness of the importance of focused work, and the costs of context switching and continuous distracting chat.
Make the most of tool features. Most vendors of communication tools are innovating to meet user needs, and some of these long-standing or new features can be useful when used appropriately. Channel topics/taglines are a prominent place to show or link to key information. Custom tags for groups of people can be used to obtain their attention without tagging absolutely everyone with @here – I’ve found this useful in service-type channels (e.g. environments/infrastructure) which have many members but of which few actually deal with the incoming messages.
Channels aren’t the only place for text communication. Many of the applications we use have built-in communication tools which are in-context and tailored to the work at hand. Pull requests have comments (line and top-level), document and spreadsheet tools have comments on words/cells. Issue trackers have comments on each issue, and allow new issues to be created to track ideas or unconfirmed bugs to be triaged later. Consider what’s the best tool for the communication at hand, for both yourself and others. And of course there’s direct messages and simple talking face to face or on a call – these too need thoughtful use.
Channels to consider
These are some channels I remember being commonplace or useful over many projects I’ve worked on. Together with the earlier parts of this post, they should help equip you to start thinking about what works for your project and team(s).
Project general. For anything that’s general, doesn’t fit anywhere else, or if you don’t know where to go.
Team[1…N]. General channel for each small team. Sometimes private, or teams may opt to have a separate private one just for when it’s needed.
Team[1…N] front door. Contact point for each team, for things that don’t need any specific person – e.g. questions, requests for help. Such a channel gets queries answered quicker, and distributes the workload to avoid it concentrating as direct messages to some specific people like the tech lead. When particular teams/parties have heavy communication, it may be worth splitting out into a dedicated collaboration channel to avoid overwhelming the front door channel.
Team / all pull requests. Some teams choose to post PRs in a channel to request review, in preference to using their repository platform’s own visibility and notification features. Posting may be automated by a bot integrated with the repository.
Practice/Role{X}. For matters of more specific relevance to people doing certain roles – developers, testers, UX, tech leads, delivery, product. Anyone is free to participate in these (and usually will ad-hoc), but most people only need to pay attention to one or two of these day-to-day.
Component{X}. For any major shared component (e.g. service, library) that multiple teams are contributing to. A place to coordinate, propose ideas, get help with specific problems, etc.
Technology{X}. For major technology areas that people work in, e.g. frontend, backend, cloud. A technology community to ask for specialist help and advice, or share news and articles of interest.
Environment{X}. For each environment (dev, test, prod, etc.). A place for announcements, problem solving, and coordinating. There may be automated bot integrations here to announce deployments or monitoring alerts.
Releasing. Place to coordinate and report on production releases. Only a few people generally interested.
Continuous Integration/Build/Test failures. With automated integrations to tag the last committer(s) whose changes could conceivably have caused the failure. Threads are used to discuss the problem, emoji reactions to indicate that someone is looking at it or that it’s been solved.
Announcements. For the things that people absolutely need to be aware of, regardless of how busy they were or if they happened to be on holiday when it was posted. Not all announcements are urgent, so no need to tag everyone always.
Some ideas for new channels may be signs of a deeper problem, which is causing a need for excess communication. Perhaps there’s a lack of documentation for something, an unreliable tool/system, a missing or ill-fitting process, or that we’re not making good use of other tools’ built-in communication features (see earlier section). Consider what you can do to address these instead.
Conclusion
Messaging tools are only one of the options we have to hand, and an effective channel structure is only one aspect of their effective use. Whether you’re starting afresh or already have channels in place, it’s well worth putting some thought into it. While it may be hard to measure, I expect a good tool set up well will improve your delivery velocity, product quality, and team satisfaction.