Basecamp’s chat sucks

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 start building 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 👽, 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.

Don’t be sorry

It is rather common to see support people apologizing to customers. Some are in the habit of doing it almost every single time. Maybe it’s part of their standard response template.

Camping Elia Halkidiki
Camping Elia

You better avoid apologizing every single time. There is a danger your customers develop resistance. The more times you say “I am sorry for your troubles”, the more it becomes an unconscious addition to your response. The customers can sense that. They will think you are not sincere. When it’s time to really be sorry, they will not believe you.

Is it ever possible to not be sorry when a customer has troubles though? Well, yes. It depends. You can spend a few seconds assessing their situation. Is the problem they are reporting blocking? Is the trouble they had severe? What is the cost for them? Not every problem is similar.

For example, a customer reports a UI misalignment. You do not detect frustration in their initial email. You don’t have to be sorry. This is a reason to say thanks! It is an opportunity to turn this into a positive and elevate your customer’s feelings. You acknowledge the trouble they went through to report a glitch so that you can improve your product.

A customer reports a bug that has prevented them from using your service for the past 4 hours. They had a deadline to meet with their customers, and they depended on your service. They are very irritated about the whole situation, and you can clearly see that in their email. Now, that’s a reason to be sorry.

It’s not time to bring out that canned response though. Transferring your genuine feelings to paper or the screen of your computer, should always start with a blank slate. What you write needs to be based on the unique situation at that particular moment.

You can’t only just say you are sorry. Just saying “I am so sorry for the troubles!” will not cut it. You need to also show your customer how much you understand how the problem has influenced them.

That’s the only way for them to lower their defenses and focus on moving forward with a solution.

Do you have examples of great responses where you had to apologize? We’d love to see them in the comments bellow!

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.

Calming up

HeavyMelon is our new calmup, and we’d like to welcome you to its blog. This blog is an extension of our company. A place for us to share our ideas and experiences. Talk about our philosophy and beliefs, and share news about the products we are building.

HeavyMelon is not new actually. It goes back. We first introduced the name under a different company back in 2010. It was when Ilias and I created a startup for food delivery in Greece. Ilias is my friend and business partner.

The moon, Thessaloniki.

After a year of development, another service won the market. Lesson learned. When you try to create a marketplace, it’s not always easy to bootstrap it. You need to burn cash for advertisement and active, on the spot, sales. That’s actual people traveling the country to bring in stores.

Fast-forward to today, we want to build a calmup. What is a calmup? It’s the opposite of a startup. We don’t want to get rounds of funding to grow fast. We want to grow in a controlled way. We want to bootstrap our business. I’ve written a small explanation on my personal blog.

We are doing this by creating the first version of our product, as fast as it makes sense. In the meantime, we want to start showing it to potential customers. Let us know if you are interested.

Our goal is to make something that customers want to pay for, day one.

The way we are building our company, can create a calm working environment. We are 100% remote. This means we value a calm and asynchronous working environment and communication.

My 9 year experience at GitHub Support helped us choose to build a support tool as our first product.

In a way, we want to extend the calmness of our company. We want to find Support teams that will appreciate how our opinionated support tool is going to work.

We named our tool Supportress, and our goal is to start an early alpha testing period later this year.

We want support teams to have calm working conditions.

HeavyMelon’s vision for Support teams

Calm support teams, will maintain their human voice, and have happy customers.

Watch this space to learn more about our journey.

Follow us at Twitter if you prefer that.

If you want to know more about Supportress, the support tool we are building, we’d love to talk to you. Please contact us. No strings attached. Our sales process is going to be calm too 😃.

If you would like to read more about my personal side of the story, I’ve written about it over at petros.blog.

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.