Slack needs no introduction, so I’ll dive straight in. Thank you to Cal Henderson, Keith Adams, and Ali Rayl for helping with this.

This is an issue from my free newsletter, Monolith. I write about how successful companies built their products (and broke the rules) before they had product market fit.

Brief History: Slack’s birth from a failed video game company is Valley lore at this point. The common telling, as with all lore, is sensationalized.

In 2009, cofounders Stewart Butterfield, Cal Henderson, Eric Costello, and Serguei Mourachov set out to build a video game they had previously failed to build in 2002. Stewart and Cal at a conference in 2010: https://youtu.be/KxGm5i9lQao?t=52 (transcript):

We have an excellent chance of being successful because we failed at it before and the odds of failing twice at the same thing are pretty low, yeah astronomical. In 2002 we started a company called Ludicorp and we were trying to make a game called Game Neverending. Same thing: a web-based massively multiplayer game except it was 2002. A lot of things were different. Chief among them it was impossible to raise money for consumer facing internet startups because it was post dot-com crash, post September 11th, WorldCom, Enron, you know, actually a much much more difficult time to raise money so we ran out of money when we were part way through making the game and tried to do something else the technology. That something else was Flickr. Flickr got bought by Yahoo and we spent several years doing that. There's four of us from the Flickr team started a new company, Tiny Speck, and we're making Glitch.

With a successful exit under their belt and a different fundraising environment, money was easy: https://youtu.be/zsBjAuexPq4?t=1370 (transcript):

We could raise as much money as we wanted. So that was easy. We didn’t even make a deck. We just said “we’d like some money” and people gave us money.

The team raised $5M from Accel in 2010 and another $10M from Accel and a16z in 2011. Glitch launched in September of 2011. By the end of 2012 it was clear the game wasn’t going to work. They shut Glitch down. They had $5M left and an internal communications tool.

From the beginning, Tiny Speck’s team was distributed:

Tiny Speck’s executive team had been based in different cities across North America. Butterfield and Mourachov lived in Vancouver, Henderson had set up camp in San Francisco and Costello managed client development from New York City.

To communicate more easily they built an internal system around IRC: https://youtu.be/EhxX06-LsZs?t=1962 (transcript):

Slowly we developed a system that was the foundation of all the ways the company communicated and was really beneficial and realized, huh, none of us are going to work without something like this ever again and other teams of 8 software developers would probably like as well. So we decided that’s what we were going to do.

The next two years were a rocket:

November 2012 - Started production-izing Slack
May 2013 - Around 45 companies were using Slack in a private beta
August 2013 - Announced a public preview and 8,000 people sign up in 24 hours
April 2014 - Raised $42.75M in a Series C with 60,000 DAUs and 15,000 paid seats.
October 2014 - Raised $120M at a $1.12B valuation with 200,000 active teams and 73,000 paid seats.

Slack went public in 2019 at a $15.7B valuation.

Development

The initial, internal version of Slack was just a wrapper around IRC: Internet Relay Chat (IRC) is a protocol from the late 80s. The Tiny Speck team used IRC, but it had some major flaws. The protocol didn’t support persistent messages, search or file uploads so the team built the features they needed around an off-the-shelf IRC server. From Stewart: https://youtu.be/EhxX06-LsZs?t=1902 (transcript):

We had developed a system that was the proto-Slack. Again, in ’92, one of the network tools I’d used was IRC or Internet Relay Chat. We used IRC at Tiny Speck, and it’s a very old technology.

With most messaging systems, there’s a concept of store-and-forward. If I want to send a message to you but there’s no connection to your client it will just be held and then forwarded to you next time you connect. IRC didn’t have that. If you weren’t connected the moment I sent the message, you would just never receive it. So we built a system to log the messages. But once we had the messages in a database, we wanted to be able to search them. So we built search. And then bit-by-bit, feature-by-feature we built things to integrate with our file server so when someone uploaded a file it would get announced into IRC or if an alert went off in the datacenter it would get put into IRC.

As the team developed Glitch, they would periodically ship a sorely needed feature to enhance IRC. Again from Stewart: https://youtu.be/zsBjAuexPq4?t=374 (transcript):

When there was an opportunity that was so obvious that we couldn’t not take advantage of it, we’d spend the minimum number of minutes on that and then go back to it (developing Glitch). At the end of that process we had this fully designed product that we were using that was a terrible implementation, not what you would do if you started from scratch, but it was obvious that this was something that had enormous value.

When the team pivoted in late 2012, they continued to use the internal, IRC version for two months while they built Slack from scratch. They moved over once the product was ready to be used internally.

The MVP had UX issues for teams bigger than ~10: In the beginning they “begged and cajoled” their friends at other companies to try it out and give feedback. They started with six to ten companies. Rdio being the biggest at around 120 employees. It was immediately clear that the product worked very differently for teams larger than Slack’s.

From Cal: https://youtu.be/TpVIeP3BIVY?t=1080 (transcript):

Those first few days of being used by other people was such a period of immense, rich feedback. There were so many things that we just hadn’t thought about because we were so familiar with the way were working but also really dumb things. If you had two people in your company called “Matt” there was no way to disambiguate between them, or if you had 20 people on your team there weren’t scrolling lists because we were an 8 person team.

The Slack team incorporated that feedback into the product, onboarded more teams, and continued to incorporate that into the product. This iterative product cycle is something they learned from Flickr.

Again from Cal: https://youtu.be/TpVIeP3BIVY?t=1125 (transcript):

An obvious lesson that we carried through from Flickr was when you look at great software products, the ones which are great did not start that way. They started out in a very different way, the product was presented very differently, users interacted in different ways, and the team iterated sometimes massively to get to where they are today. It’s all about that feedback loop of understanding what your customers are doing, problems they’re having, what they are trying to achieve and folding that back into the design of your software and iterating towards a product that can be great and that people can love.

Slack’s architecture resembles that of an online game: Slack clients cached everything. On startup, they would make a single API request, called rtm start. This would download everything about a user’s workspace including the channels, members, and channel membership. The client would then open a WebSocket connection to send and receive updates to the local cache.

From Keith Adams, chief architect of Slack from 2016 to 2020, talking about how the media likes telling the story of Slack’s pivot from an online game: https://youtu.be/WE9c9AZe-DY?t=445 (transcript):

Usually people just mention this as some funny thing: “oh they were a game company, isn’t it funny how cookies crumble sometimes?”. That’s true, but it actually comes back in certain ways. If you kind of squint and tilt your head the actual architecture of Slack resembles the architecture of a massively multiplayer online game. You kind of have your “world” you operate in, which is your team, and in order to make that world seem both persistent and interactively mutable with other things in the world you end up making a pretty thick cache of what is going on in that world and then you have a way of getting low latency updates for the changes in that world. That kind of mental paradigm of “oh it’s kind of like an online game” explains a lot about Slack. It’s why we have loading screens for instance. It’s the same reason video games tend to have loading screens.

My take

Slack was built to solve their own problem. Similar to Nomad List, the initial version of the product came from a genuine need of the creator(s).

Simple things can provide immense value. Slack was simply an extension of an open protocol, but it provided immense value to the right users. This is another case where there was zero technical innovation required to create something massively valuable.

It’s not just coincidence that Slack was born out of a gaming company. This is relevant beyond just the technical architecture. Slack doesn’t feel like work. It’s one of the reasons people love it. MetaLab designed much of Slack’s initial UI. From MetaLab founder Andrew Wilkinson:

To get attention in a crowded market, we had to find a way to get people’s attention. Most enterprise software looks like a cheap 70's prom suit — muted blues and greys everywhere — so, starting with the logo, we made Slack look like a confetti cannon had gone off. Electric blue, yellows, purples, and greens all over. We gave it the color scheme of a video game, not an enterprise collaboration product.

Links / Resources

Also published here.

Slack's birth from a video game company was not a coincidence

Development

My take

Links / Resources