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.

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.

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.

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.

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.

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.

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.

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.

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.

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.