I think it’s clear by now that chat is the new office. As a company trying to build in the open, we think that what we’re calling “Town Hall Chat”, opening our internal chat channels to our users, is the future of open company communication. 

Today we’re moving our corporate communications off of Slack and entirely to Discord and opening every channel that we can to the public, either read-only or as full participants. Now our users can co-work with us in our office, virtually participate in some of our online meetings and virtually check out our whiteboards as we build.

It’s a new kind of company communication that hasn’t been done a lot (if ever?). Here’s how we did it, should you want to try it too.

A Short History

When I first started in the software industry a few short decades ago, most internal corporate communication would be done in person, in meetings, or over email. 

In the early days of GitHub however, around 2008, most of our internal communications were done in a chat application from 37Signals called Campfire. Even if the whole team was sitting around a table in a cafe or in the office in person, we would still be chatting mainly digitally.

In those days (15 years ago), this style of internal corporate communication (chat over emails and meetings) was a bit rare. However, today, post-COVID, nearly every company has started or fully moved to some version of remote working, and chat is now both the new email and the new office space.

GitHub preferred it because there are some huge advantages to it. It’s shared (unlike email), real time, searchable, and reference-able. There are URLs for conversations, they’re are not prone to subjective individual memory, and perhaps most importantly, they’re asynchronous.

Over time, Campfire was replaced by Slack at GitHub (Campfire was being phased out, we tried developing our own chat product, we struggled to ship it, different blog post maybe...), as millions of other companies did. Now nearly every company has a corporate Slack or Teams instance. It’s where the work gets done.

However, one big downside to corporate chat is that basically none of them have a good way to have non-employees participate. It’s similar to the old days of open vs closed source. You have to have one system for chatting with users and an entirely different system for chatting internally. Many companies, ourselves included, now have Slack for internal conversations and Discord for external ones.

For companies like GitButler who are trying to build in the open, trying to give our customers and users insight into what we’re doing and how we’re making decisions, this is detrimental. We have conversations that could be public but are private by default, just because of which tool these conversations are happening in.

Today, for us, this is changing. 

We’re moving all of our corporate conversations entirely into Discord. This means that when our product team is making design or engineering decisions, they’re happening as much as possible in publicly available rooms.

Now we have all of our private internal conversations in rooms that only our employees can access and any other conversation in rooms that our entire community can see and participate in. We can internally argue about which rooms absolutely need to be private or could be opened up somehow. We’re developing in the open and designing in the open. Also, when a user has an issue or feedback, our whole company is there to hear it.

Not only that, but the permissions system of Discord allows us to consider even more interesting things. We could give some users (contributors or supporters perhaps) read-only access to some semi-private channels. We haven’t started down this road yet, but that it’s possible is a whole new world of being able to be scalably open and transparent.

One of the fun side effects of this is that unlike a normal product-focused Discord server, we have some channels that are more for culture than product. Users can share their best dad jokes in our #dad-joke channel, or photos of their pets in our #introduce-your-pets channel. We could make these private too, and most companies have something like this in Slack, but why not include everyone?

You Can Too

So, let’s say you want to move your company to this hybrid-open relationship with your users as well and you’re also stuck behind the Slack moat. 

What were the slightly tricky things we had to do to adapt from the one tool to the other? How can you move your company to a Town Hall Chat format?

Room Grooming (gRooming?)

One immediate practical consideration is how to setup your rooms.

This is also an issue in Slack or any other corporate chat solution, but it’s an interesting one to consider if you have mixed public/private rooms in your company chat.

We don’t want an explosion of rooms, as tends to happen with company chat setups. We took the opportunity to see what Slack channels we had, see which were regularly used, and consolidate a bit. It’s also important to help new users figure out where they should go. Unlike a corporate setup, it needs to be fairly clear with zero onboarding where things should be discussed.

We also decided to add small emojis to the start of each channel name to help with visual scanning. All of ours are of the style #🛠・development or #😏・dad-jokes, which uses the “・” character as a visually minimal separator as otherwise you need a dash in the name (as you can’t use a space).

The difference between Slack, where you need to join or be invited to rooms, making discovery sometimes problematic but enabling lots of small rooms, versus Discord where all the public rooms are visible by default is an interesting one. We’ll see how we deal with this as we grow. I’m sure there are lots of best practices in this environment that don’t really exist yet.

Integrations

One of the largest issues we had with moving over were the various Slack integrations we had. Slack has a fantastic set of integrations that are widely supported by other services. Discord has basically none. Some of the integrations we had that needed to be moved or otherwise supported in order to get internal comms parity were:

• GitHub (PR and other repo activity)
• Homerun (hiring notifications)
• AWS Chatbot (ChatOps deployment stuff)
• Stripe (seeing when people subscribe so we can send them perks)
• GitButler Feedback button (in our app, you can send feedback easily)
• Hacker News / Social mentions (we had Vercel’s Slacker set up)
• Internal stats (signups per day, etc)

It’s not a tiny list and all of them are very different levels of challenges of re-integration. Some we could also probably do without, but I wanted to see if we could basically move over everything in some form.

Webhooks

Discord has a few good ways to get messages in, but since most of these are just notifications rather than something that requires a responsive chatbot, generally the Discord webhooks system is good enough. For every channel you can setup unique URLs that can be easily posted to in order to inject some message, which is actually much easier than the way Slack does the same thing. This is how we converted our Internal stats stuff over.

Zapier

For most of the rest of them, we now rely on Zapier to do the notifications. Zapier has a very simple Discord integration module and then we just need input modules for the rest of the services.

For some of them, such as GitHub and Stripe, Zapier has nice modules that can see the changes we’re looking for and post them directly to Discord. Those were a few minutes to put together. For some of the others, such as Homerun and the social mentions, we had to eventually fall back to email to get something approximate.

For example, Homerun has a nice Slack integration, but the only other way to get notifications of new activity was email. So we set up a dummy email in our Google Workspace, have Homerun send emails there, authorize Zapier to access that Google email account, setup a filter in Gmail to tag the correct (not marketing) emails from Homerun, and forward parts of that incoming email to Discord. Not ideal, but it does work.

AWS Chatbot

The only real chatbot we had was AWS Chatbot, which is impractical to reimplement in Discord. Luckily we were mostly only using it for deployment notifications, so we just set up a new SQS queue for messages from our Code Pipeline, setup an Email sink for those notifications and sent them to the same Google email and tagged them differently. 

Then we set up a Discord notification from that. It still needs some work, but at least we are getting some data for those same kinds of events.

Archiving

As we went through our rooms in Discord, we decided to combine or shut down ones that were no longer relevant. However, there isn’t really an “archive” feature in Discord and we still wanted the content searchable, so how do we get it out of the list of rooms users see? 

We ended up making a private category and putting them in there for now. We’re not sure that’s the best option in the long run, but it means we don’t have to delete them and they’re not showing up for people right now.

Sensitive Data

One of the biggest issues that we debated was trust in the system over any sensitive data or conversations. This would include help requests that include any sort of personal information, conversations about things like fundraising or finances, and especially HR types of communications such as hiring or compensation.

Discord does not have the corporate or security focus that Slack or Teams does, it is also has a rather significant percentage of ownership by Chinese company Tencent, which is also concerning for privacy and security reasons.

To some degree, we have to work under the assumption that everything that goes over this server is somewhat insecure and that our “private” rooms are in fact simply “difficult to access”. Our current solution to this is to communicate all truly sensitive data over end-to-end encrypted solutions like WhatsApp.

It’s really unfortunate that Slack does not have the type of public functionality that Discord does. Slack is better in so many ways, but similar to how GitHub really had an advantage over other code hosting solutions because it allowed and encouraged a mix of private and public possibilities, Discord is the only possible and embraced solution that allows us to mix public and private in a way that works.

Hopefully that will change someday and we can have a blog post about moving from Discord to whatever that solution is.

Fin

We’re excited about opening our office (virtually) to more of our users and expanding the trust we have in each other. 

I would love to see more companies do this, because I would be excited to see how other companies work and to be a more integrated part of some companies and products that I find awesome.

If you’re considering moving from Only Us Chat to Town Hall Chat as well, share it with us on Twitter or tell us in our Discord, we would love to be able to learn from each other.