Basecamp’s chat sucks, and I like it

And I like it. But first, a little history.

Back when I started at GitHub, we were using Campfire. 37signal’s standalone chat service. In fact, GitHub hired me through a Campfire interview—around 2010.

Michaniona , Thessaloniki

After some time of using Campfire we wanted to create our own chat app, and also make it a product. We started working on it and, if I remember right, even started using it in the company for a while. Then Slack happened and the rest is history.

We switched to Slack and we abandoned the idea of creating our own chat app.

Slack is not only a chat app. For most remote companies, it’s where everything happens.

GitHub was growing. We went from a 2 digit number of employees to a 4 digit one. Slack started showing its problems.

The combination of growth and using something like Slack changed our communication culture. You see, Slack became the backbone of our company. When we started, we all wanted to be remote first. We agreed to use written asynchronous communication through GitHub Issues. Chat was there for chat-ops, water-cooler chats and emergencies.

After Slack we still used GitHub Issues. Yet, people started defaulting to chat. The problem was not so much that. It was more about the new expectations. People expected almost immediate responses. Not responding immediately or within a day could label you rude or non-collaborative. Even if you didn’t want others to feel like that, the receiving end of a chat message couldn’t help it. They felt they needed to respond immediately. I caught myself writing disclaimers along with my messages to say there’s no urgency. That people can respond whenever they had time. But even that created noise to them.

Imagine waking up to 20-40 red numbers of unread messages in Slack. Almost all with the expectation of doing something about them as soon as possible. Or having to check them to see what’s urgent and what’s not.

This creates stress. Stress doesn’t make you productive. Not being productive means you are not happy.

At this point I want to say it’s not Slack’s fault. It’s how people use a product that’s based on chat. Any chat app with the extensibility of Slack will have similar problems. There is now Team and other competing products as well. They organize chats in a different way, but they are still based on chat.

A second problem was GitHub growing from a remote first company to having a big office in San Francisco. If leadership is not remote, the company will never be remote first. If you don’t work from Europe for a month, you can never understand the problems of being remote. You can only listen to feedback, but it is difficult to appreciate the problem.

Important discussions started happening outside of Slack or GitHub Issues. This created the sense of a two gear company. One existed in the office and the rest was remote.

When I quit GitHub to startbuilding HeavyMelon, we had two big questions:

1. Are we going to be fully remote and distributed?
2. What tool(s) are we going to base our remote company on?

The answer to the first question was straightforward. Hell, the two founders of HeavyMelon—myself and Ilias—live 500+ kilometers apart. We not only want to be remote. We also want to be fully distributed. This means we can hire from anywhere in this world. When we colonize Mars :alien:, we can hire there as well.

The second question generated a debate. Should we default to Slack like most companies do nowadays? Slack has everything. We can integrate our repositories. We can show CI results. We can create chat-ops with ease and take advantage of prior art. We can chat in different channels, and more. We have to use Slack anyway for other groups we are members of. Usually members of other communities, at a personal level. One more Slack group wouldn’t hurt, right?

After some semi-heated debate, we decided against using Slack or anything similar.

We went with Basecamp .

My argument is Slack is ruining the culture of a remote, distributed, calmup . One could put rules. People should only use Slack for chat-ops, notifications, and emergencies. Would that help? Would it help people avoid falling into the trap of moving all communication to Slack? My experience says no.

I am coming from years of using Slack. A company cannot maintain a calm remote culture through rules only. They need to choose their tools as well. And they need to do that in a careful way. That’s why we chose Basecamp.

Basecamp organizes everything as Projects. Each Project has its own area for chat, messages, todo lists, schedule (calendar), and more. The big difference is that chat sucks in Basecamp. I can’t confirm it, but I almost think this is on purpose. In any case, that helps people choose more async means of communication. Messages and todo lists, where you can also communicate using comments. Chat is good for the quick message, for the social interaction, dropping a tweet or a YouTube video of interest.

The difference between chat and a message is that the latter has all the nice formatting options. But most important, it allows you to think before you write. It allows you to edit your draft before you hit send. And it allows everyone to respond in their own pace, in an asynchronous way. It never creates the expectation of urgency, unless you choose to. Or the need to have a real time conversation. If that’s the case, one can use chat.

HeavyMelon Basecamp message board

The fact that chat sucks in Basecamp has some downsides of course. I often want to drop a code snippet and ask something. That’s difficult. Or at least less advanced compared to Slack. Creating your own chat-bot is up to you. There are many Slack integrations out there. It is very easy to add them. Basecamp has integrations but limited ones, and incomplete in most cases. You can write your own of course, but that takes time and energy.

We decided against using integrations or creating chat-ops for starters. If we do, we will only do it for emergency situations. In any case, you can always go to the service you are interested in and check things through their UI. This helps the whole company stay connected to how things look at the service provider’s end.

When you always use chat-ops and never visit the UI of the service you are interacting with, you are missing out. I’ve seen folks not being able to use the service when chat-ops weren’t available. Or sometimes a chat-ops didn’t support some functionality. Or Slack was down.

The tools we choose for our company help us stay calm through the constraints they put in place.

Slack, Team, and other similar products are here to stay of course. I already see them changing things to the better. They definitely know about the problems I am describing here. Their product teams are trying to figure out how to improve the craziness situation. New startups are popping up every month trying to approach chat in a different way. Trying to address the shortcomings of basing your company on chat.

This is a difficult problem to solve. Chat invites people to real time communication. It creates that expectation. It is very difficult to shake that off.

In the meantime, I enjoy not having to run the Slack client on my laptop. My laptop CPU and memory also enjoys that.

Fully remote companies are only going to increase in number. They need the right tools. They need the tools we haven’t written yet. A fully remote company is in the best position to write those tools. We are a fully remote company, writing tools for remote distributed support teams for starters. Wish us luck :).

We are building a support tool called Supportress to help teams stay calm, be happy and productive, and have happy customers.Subscribe to this blog, or express your interest to participate in the private beta .