At Tighten, Slack is our office. As a fully remote team, we live in our Slack instance every minute of every working day. It's our conference room, our cafeteria, our water cooler, our TGIF watering hole, and most importantly, the nexus of all project communication.

As early adopters of Slack, we've thought a lot about how to structure our Slack environment to optimize communication, particularly on client projects. Looping external people into your Slack team is not without its risks, and we've found it merits careful case-by-case consideration.

The basic communication needs for every project

While each project has its peculiarities, there are some common communication needs most projects share. A typical client project might involve three Tighten team members (two developers and a project manager), one or more individuals who work for a partner company (say, a design firm), and one or more representatives of our client. To successfully facilitate communication between all of these players, we need:

1. A place to conduct day-to-day internal communication
2. A place to communicate with our external partners
3. A place to communicate with, and receive feedback from, our clients

When we first started using Slack, we didn't really think through how to separate these concerns. When starting a new project, we would simply spin up a channel and give everybody access to it, including partners and clients. This quickly became a problem—the room became too noisy for the client to keep up with the discussion, and our team felt like they couldn't speak candidly in a space where the client was always present.

The better approach, we discovered, is to have a separate channel for each communication context demanded by the project. The goals of this strategy are twofold:

1. Create a space for each unique mix of people that will need to communicate regularly during the project
2. Name each space in such a way that everyone knows exactly who they are talking to at all times

#2 is the critical piece. As an owner of the business, one of my recurring nightmares is that I accidentally conduct a sensitive conversation in the presence of the wrong person, say, an important client. Things are said in less-than-tactful ways, comments are taken out of context, we are exposed as frauds (or worse), the client fires us, and the company goes down in flames. Yikes.

As an owner of the business, one of my recurring nightmares is that I accidentally conduct a sensitive conversation in the presence of the wrong person, say, an important client.

This situation must be avoided at all cost. If we were all sitting in the same conference room someplace, all we would have to do is look around the room to know who I'm talking to. But in remote collaboration land, it's not that easy. We must be vigilant, and here's how: choose channel names that clearly and unambiguously indicate who is in the room.

Let’s say we are starting a development project codenamed Delta for a Company called Megacorp. Tighten has the contract with Megacorp, and we have enlisted our partner Acme Design as a subcontractor.

Context 1: Main Channel

• Channel name literal: #delta
• Channel name structure: #[project]
• Channel composition: Tighten team members

The Main Channel is what Tighten will use for all of our day-to-day communication on the project. We'll trick it out with various integrations like GitHub, Trello, Bugsnag, etc. As such, it will be the noisiest, most active channel for this project, and the one where our team can speak freely and casually as they do their work. Occasionally, a given project will develop its own personality, inside jokes, gifs, and emojis. OK, more than occasionally.

Importantly, the main channel is also a place where our team can talk openly about how the project is going without worrying who hears them. Even on projects that go very smoothly, there are always conversations that should remain internal. If you've ever done client work, this won't be a foreign concept to you.

Context 2: Partner Channel

• Channel name literal: #delta-acme
• Channel name structure: #[project]-[partner]
• Channel composition: Tighten, Acme Design

The Partner Channel serves as a place for Tighten team members to collaborate with partner organizations. In this channel, our design partner will upload design files for feedback, discussion, and reference. Our developers will ask questions about implementation, request clarifications, etc., then retreat to the main channel to complain about the persnickety designers. Just kidding. Kinda.

Context 3: Client Channel

• Channel name literal: #delta-acme-megacorp
• Channel name structure: #[project]-[partner]-[client]
• Channel composition: Tighten, Acme Design, Megacorp

The purpose of the Client Channel is to facilitate concise, essential communication between the client and other project participants. While our client may also be added to Trello boards or other tools, these tools are generally not integrated into the client channel, in the interest of keeping the Client Channel noise to a minimum.

On this hypothetical project, we've included our design partner in the Client Channel as well, and we've stacked the partner in the name of the channel. Remember, we want to make channel composition clear and unambiguous above all else.

Additional Contexts

As a project proceeds, inevitably some contexts for communication will arise that we didn't plan for. For instance, we might need to discuss terms of a contract with the client, or negotiate rates with a partner. We also usually maintain a separate channel named directly after the client or partner (in this case, simply #megacorp or #acme) where we discuss things like finances, contract terms, and future projects. We generally make these channels private, as most discussion at this level will take place between management types.

Finally, thanks to Slack's recently-introduced group DM feature, other subsets of people who need to communicate during a project can simply be arranged ad-hoc. Sweet.

Channel Summary

Drawbacks to this Approach

Like any design decision, our approach is not without its tradeoffs.

First, the stacking of elements in channel names can get a bit cumbersome. You will eventually run up against Slack's 21-character limit for channel names, and you'll have to start abbreviating. For our team size, this isn't a big deal, but I can imagine it becoming a hindrance for larger teams with longer client lists. Nevertheless, I'd rather have a long, ugly channel name than something ambiguous or error-prone.

Second, there's the matter of transparency with clients. When we first implemented this strategy, we were hesitant to name channels in a way that would reveal to clients that they were being excluded from the Main Channel. As a company that greatly values tight collaboration with our clients, isn't it a little weird to exclude the client from the primary project discussion?

The answer is no. By and large, our clients are smart, busy people with many demands on their time. In every case so far, they are perfectly happy to be shielded from the minute-to-minute chatter of the Main Channel. They appreciate the noise reduction, and could care less about missing the full circus.

Note: The size of the project, the number of collaborators, and several other factors come to bear on whether we have multiple channels for a project, and if so, which and how many.

Conclusion

So that's a glimpse into how our organization tackles handling Slack channel organization for client projects. Since every project is different, we don't always adhere strictly to this framework. We allow common sense to override dogma, and so should you. Even if your projects are shaped differently than ours, consider giving some deliberate thought to how you structure and name your Slack channels. It will help optimize communication, respect everyone's time, and it just might help you avert a disastrous communications snafu.

Love this idea? Hate it? Let us know on Twitter.