Hacker News new | past | comments | ask | show | jobs | submit login

Slack has a staying power that the author didn't catch: once you've got all kinds of apps reporting data directly into Slack, and all kinds of rooms set up for specific data purposes, it's even more sticky than email.

Before a Slack-using company would switch, the competitor would need to support many/most/all of the integrations that the company is using. You've really only got two chances to win Slack's customers: the point before they seriously adopt Slack, and the point in the future where Slack does something stupid like jack prices way up or suffer a serious breach.

You could make this same argument to argue that Slack would fail against email.

Something like: there are all kinds of email integrations, user-specific and group-specific setups, etc. at companies. How can Slack ever compete?

The answer was that Slack was so much better for many companies that it made sense to suffer the pain of switching.

The company that beats Slack will likely be 10x better communication software or something very similar but distributed much more effectively (maybe Microsoft Teams in the enterprise).

Chat is a complement to email, not a replacement. Over time some people may take their formerly-email activities to chat, but no cutover is required.

Running two chat systems side by side, on the other hand, is a huge pain. There really is a pressure to get everything migrated and the old one turned off.

Depends on the company. At our 6 year old startup, email is dead except for external communication. Everything is on slack including ops, stand ups and informal communication. At Google, hangouts was lightly used but everything was on email.

People expect an instant response on chat, but reading emails from time to time. That makes a huge difference in interruptions when you work.

This is dependent on a particular workplace's culture, not an inherent aspect of the technology.

Yup. I can't think of last email that was sent within my startup. Only clients and partners. Though some partners we have shared slack rooms, so even that may be going down.

Curious, how large is the startup?

In the ballpark of 140.

Email is for outside the boundaries (outside-of-company, outside-of-division in a silo'd company), chat is for inside - there's still people who do prefer email especially in partner facing roles, but I think its fair to say that most prefer using chat if they had a choice.

Not necessarily true. For example the enterprise I work in doesn't allow saving chat history. This makes email better for technical discussion that needs recorded.

What's the rationale behind that?

Legal. When we are sued (we make equipment used in dangerous environments, and we have a lot of money, so if there is the slightest chance we can be blamed we will be sued) US law says we need to give all relevant information to the other side. That includes any saved chat logs and emails. However if something was deleted before we are sued we don't have to give it out.

We lost a law suit once because a [not native English speaker] wrote "the bearing will fail with disastrous consequences", he meant the shaft would need to be replaced, but when a fire started in the area of the bearing that email was part of discovery and the jury decided the bearing was at fault for the fire not the user failing to clean the area which was our story. (legal would rather I not give you the case to read for yourself)

Chat tends to be less formal than email, thus more opportunity exists for something that is easy to take out of context. By not allowing saving chat logs we ensure they they will never get to court.

We have strict rules that emails must be deleted after a few months (unless we legally need to keep them). Any information in the email that is worth keeping longer than that is put in a formal system where legal can examine the words to ensure they won't be taken out of context and used against us.

You can make chat unavailable after x months along with email. Of course if actively being sued that may be longer.

Sounds wrong to me. Hiding chat logs or other business information from the company itself as well as customers (albeit suing ones) seem stupid. How would the company ever be able to audit its own operations? Getting sued is sometimes also not too bad as it can reveal bad practices within an organization. An analogy would be an X-ray, not entirely healthy but very revealing.

Normal companies do not operate voice recorders in offices/conference rooms or even telephone wiretaps, except for specific regulated positions. Text may be more convenient to collect and search but I don’t think it’s morally any different.

It doesn't matter what sort of business you are in, you need to have some ad-hoc communication that isn't part of a "permanent record", or else you incur communication friction everywhere.

Having it broken down by system is a pretty practical approach.

I suspect that part of it might be legal. It's too easy for someone to say something in chat that will look bad when you're sued.

I can organize and search my mail archive much better than chat, and I disable the notifications on chat anyway, so I'm not sure about that.

Email feels more asynchronous than chat. With an email, I don't expect an immediate answer, and I expect a better-researched answer.

Well, and email integrations are easy to replace - it's a single, uniform interface.

Author here. Slack is undoubtedly sticky, although I challenge the assumption that all integrations need to be replicated in a niche play. Those who did adopt Level were willing to give up a number of integrations that were low-value to them or were just causing noise that proved unnecessary.

I was struck with " They recognize that Slack is not suitable for meaningful conversations, so they automatically delete chat messages older than a few weeks to discourage relying on it for long-term archival." in your article.

It's something I feel quite strongly about: chat should not be archived. There should be no backscroll; being not around when people are talking means not being part of that conversation. Chat messages have no value beyond the moment. Any chat implementation that assigns importance to messages beyond the current conversation is wrong.

For the rest... It was like peeking into an alien world. I've been maintaining an open source application since 2004, and I've had various day jobs, but managed to build it out into my day job the past couple of years. I've never had the startup itch :-) Just let me build up my userbase, my income stream and my contributor team, and I'm happy.

> being not around when people are talking means not being part of that conversation.

Persistent chat is one of the biggest values of Slack or Discord or Mattermost, and one of the big reasons I'll take it over IRC any day.

Persistent chat that you can join and read the backlog of is incredibly valuable. It becomes an asynchronous communication medium, rather than a synchronous one. And it's much richer and lower-friction than email.

Agreed about being able to access some backlog being important, but even in well-implemented systems with good search etc. I personally haven't found backlog older than maybe a few weeks that useful.

Similarly, I'd disagree about friction, but I can see how that might be cultural/personal preference - none of the chat systems I've used provides good-enough tracking of "I still need to take care of this" compared to email clients with a few flags.

With people having the expectation of chat to be instantly replied, like a chat in a real life (someone walking to your desk and saying something) it is not asynchronous in any way.

You seem to suggest people have that expectation, but I think it might be very culture specific. Where I come, people will not freak out if it takes you a day to respond to an SMS.

SMS is NOT chat.

That's also culture-specific.

> It's something I feel quite strongly about: chat should not be archived. There should be no backscroll; being not around when people are talking means not being part of that conversation. Chat messages have no value beyond the moment. Any chat implementation that assigns importance to messages beyond the current conversation is wrong.

What's the value in removing this? I regularly look back to see what was discussed, it allows easier integration across timezones. I don't want to have to be around late for my American colleagues, or have to shift the conversation to large cc'd email. For chat I am involved in, why do you think I shouldn't be allowed a history of what I have talked about with people?

> There should be no backscroll; being not around when people are talking means not being part of that conversation.

We must use chat very differently, because I don't understand this.

The number of times I've found answers to problems ("How do I X? Why can't I get Z to work with vagrant?" etc) by searching through Slack channels, or viewing pinned messages that explained something (or had a workaround/fix for a problem) is huge. This has been especially helpful when joining a team, where searching the archives can be the first step in finding answers.

A lot of what we chat about could safely be ephemeral, but there's a significant amount of company / team knowledge which can be searched (or pinned). The friction necessary to have people put answers in Confluence (or similar) is high enough that often the answers (or discussions around them) are either never written, or not updated later.

Don’t use confluence. There are knowledgebases with way less friction.

Please name them for those of us looking

I'm also super interested in better, or more usable, recommendations.

I disagree. I use the search function in Slack all the time. Documentation can't replace the meta discussions that give you the bigger picture and help you resolve specific problems. Slack is like our company's own Stack Overflow.

My 2 cents is... don't give up. Make sales calls. Aim to get 100 rejections (makes rejection a metric to aim for, really, so less pain?). Then you get a better view of the market and the real pain points.

> Author here

Great article, very informative. Thank you for the effort.

There's a lesson in there, viz. that an ISV ecosystem around your product is a major retention factor.

Nothing new here of course, tech shops have been doing it for decades. Centuries even maybe.

See also: certification programs.

I think you could provide a compatible API, or a wrapper around your API that makes it (mostly) compatible, claiming that you do it for interoperability.

If you think that’s too risky, legally, an alternative could be to provide example code showing “to do X in Slack, do this on our API”. If your tool gets some traction, a third party wrapper might show up.

Those integrations are slack's moat, but I think many of those useful integrations are already multi-tenant (having to support hipchat for large corps), or through a proxied service that can add a new output integration. For smaller businesses who just use the slack connector store that might be more difficult.

Not that it'd be easy but I imagine that you can steal their customers by adding chat rooms and integrations slowly to some other type of software, rather than a more direct angle where you have to win at one of those two moments.

Microsoft Teams with their decent video conferencing might have an angle plus being “free” part of 365.

The company I worked at previously tried to force MS Teams on everyone. Problem was that most developers there ran Linux and the client was far inferior to Slack on that platform. Unsurprisingly very few developers used Teams and it failed horribly as a decent communication replacement. It became yet another communication channel devs may, or may not, respond in. End result: email still reigns supreme, complemented by xmpp for the non-devs with the technical know how to understand how to connect to the internally hosted server.

So my view is that until Microsoft get their act together, Teams is not a serious contender to Slack. Companies can get it "free" together with their Office subscription, but most developers won't use it until it works decently on their development platform of choice.

That's the discussion we're actively having now. My only concern is how to move the knowledge and context that's currently in Slack somewhere else. Also, who knows if Teams will actually catch on - though with Microsoft threatening to get rid of Skype, it'll end up being the more official looking meeting app anyways, so why not bring the rest along?

I’m pretty sure Teams is here to stay. It’s growing. MS is investing a lot of resources and it’s improving rapidly.

But I think your point about MS getting rid of Skype for Business in favor of Teams is the most important one. Once that happens, which MS has stated publicly, Teams will become a necessary app for MS to support, since enterprises won’t tolerate MS not having s chat service in O365.

My employer ran several pilots of alternative chat systems alongside our primary. It sucked. Having both clients open, remembering which rooms are actually in active in which systems, etc. was obnoxious. Might work for a single closed-loop team but even then.

Isn't Mattermost pretty close? When I moved to a company with Slack, I recognized a lot of stuff from my previous job where some of the devs used Mattermost.

zulip has quite a few integrations too apparently.

I've been thinking about giving zulip a whirl with one of our smaller teams at work, and see how it compares to slack. Quite a few items on the "why zulip?" page really resonate with me.

Couldn't you offer an integration API that's compatible with Slack?

Maybe not in the US, where APIs are under copyright, but outside it could work...

What's stopping potential competitors from making slack-compatible APIs?


Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact