Day 1

Eight of us sat around an old wooden table in Tiny Speck’s Vancouver office. Cardboard boxes and dead batteries were scattered around the abandoned desks of our former colleagues. The place felt big and empty. We’d shut down Ur — the world of Glitch — a month before. We were meeting today to kick off work on Slack.

Stewart sat buzzing at the head of the table, customary quadruple-shot cappuccino beside his laptop. He had a deck projected on the TV. It said codename: /slack on the first slide, with the rather clumsy subtitle “Help people use computers to work together, better.” The frustration and discouragement of Glitch’s ending were no longer apparent. Stewart vibrated with enthusiasm.

The slide deck outlined the concept and main features of the software he imagined: “all your team communication in one place, available equally well on your computer, phone & tablet, synced so you can always pick up where you left off, and everything available through one unified search.”

The pitch had been enough to convince our investors to give us one more life. A chance to pivot from the failed game to something entirely different. Now Stewart was laying out his plan for how we could actually pull it off.

What’s wrong with email

The basic idea was to replace email inside a company. Email had become the primary means of communication for most workplaces in the 90s and 00s. Everyone had it. Everyone knew how to use it. Companies had built elaborate workflows around it.

It was also terrible for organizational communication. Email splintered company messages into thousands of inboxes, giving each individual a partial view. Email threads that started with one topic rapidly sprouted tangential topics without a clear way to distinguish the different threads of the conversation. Reply-all chains bludgeoned recipients with high-noise, low-signal replies to sort through. 

Each email required an elaborate ceremony to compose. The sender must choose the recipients, compose a Subject line, issue a salutation, provide context on the matter at hand, ask their question or issue their instructions, close with a parting goodbye, and sign off. They could then optionally add attachments to be sent along with the email. Though — humans being humans — this step was often forgotten, requiring a hasty follow-up email with its own context and apology.

The “cc” (carbon copy) function of email offered a way for people to loop in anyone who might need to know, adding to the deluge of messages. cc’s sneaky partner “bcc” (blind carbon copy) let senders hide context about who could see it, breeding all sorts of communication anti-patterns.

A new employee at an email-based company arrived to an empty inbox, without any history or context to orient them to their role. Existing employees might search through their own inboxes to forward conversations and try to fill in the gaps. When the new person had a question, she might wonder who to ask – and if she guessed wrong she might wait hours or days to find the person with an answer.

People had become addicted to and dependent upon email. They hated the attention it required but were stuck without an alternative. Companies kept investing in policies and additional software to try to (unsuccessfully) fix their use of email.

Stewart summed up his pitch succinctly, “You'll know it's working when you don't have to use email at work any more.” 

A better way to work

Slack would offer many of the same functions as email, but fundamentally reorganized around a shared view of topic-based channels.

• Like email, you can send a message to someone at any time.
• Like instant messengers, messages in Slack are "bare" communication (no subject line, no salutation, no signature).
• Like IRC, you can broadly address a topic-based #channel rather than an individual.
• Files, images, and rich link previews flow directly into messages. They’re part of the content, not separate attachments or items you have to go find in a folder on some archaic intranet.

If email was a direct digital replication of 20th century paper mail — complete with inboxes, signatures, and addressees — then Slack was native to the mobile messaging apps and web-based communication expectations of the 21st century.

Slack would integrate directly with all the tools your company used for work. Calendar events would appear seamlessly alongside shared documents. Events from cloud file services like Dropbox and code repositories like GitHub would trigger updates in Slack. Commands from Slack could likewise send events to other systems — marking a customer ticket resolved or creating a new sales lead.

With our API, custom integrations could be written to connect Slack to any internal tool your company needed. These tools would be available to people from the message input in Slack via what we called “slash commands” for the forward slash character that preceded them.

All of this would come together in one system. Slack would become your organizational brain, complete with a searchable archive of all your company knowledge. 

Making money

Unlike Glitch, which people played for free and offered optional items and costumes for purchase, Slack would launch out of the gate with two payment tiers: Free and Standard. This strategy — known as “freemium” — would enable anyone to instantly start using Slack, then upgrade to the paid plan when they needed more storage capacity for files and messages. The Free tier would be restricted to 10,000 messages in the archive and would have soft limits on file storage and number of integrations.

We would charge $9 per month per person for the paid product, with a discount for annual subscriptions. This was significantly higher than most of the “chat” products that seemed comparable at the time; we had a hunch that the unified set of features would be much more valuable than chat alone. One morning shortly before launch, Stewart walked into the office and stated that the price would be $8, not $9, simply because it “felt better."

We would start by targeting startups and tech-sector small businesses that resembled our own. Then, we would grow into larger organizations driven by word-of-mouth and bottoms-up demand — though we guessed that usage would max out at about 150 people (we borrowed Dunbar’s number as shorthand for the number of individuals a person can keep track of in a social environment).

It was a compelling pitch. At this point we were firmly within Stewart Butterfield’s “reality distortion field” — the ability to generate confidence in the achievement of an idea, despite substantial reason to be skeptical. In this case, buying into the possibility of upending decades of corporate communication conventions used by billions of people around the world with a piece of nicely designed chat software.

Stewart advanced to the final slide of his deck to a timeline that looked like this:

Prototype • End of January
"Good enough for us to use full time"

Alpha • End of February
"Good enough for some trusted friends to try"

Private Beta • Mid-April
"Good enough to be tried by some people we don't know"

Open Beta • End of May
"Good enough to be tried by the general public, with appropriate disclaimers"

Production • ???
"Good enough to charge money for"

It was January 8th, 2013. We knew we had a good idea. We also knew the best way to make it better was to use it intensely ourselves, then get it into customers’ hands as quickly as we could. We had started some prototyping in December — but everyone needed a break after shutting down the game. With the holidays over, we were ready to get serious.

The original eight

Cal Henderson, Tiny Speck’s acerbic CTO, sat with arms crossed and took in Stewart's presentation with a neutral expression. Cal had cut his teeth building and then scaling Flickr to serve hundreds of millions of photos. He was a prolific coder and assertive technical leader. He had worked with Stewart since 2001 when he began contributing to Game Neverending from his home in England. Working as a student, Cal had initially been paid with wishlist items from Amazon, including rare Japanese releases of Radiohead recordings. He later emigrated to Canada to join the team in Vancouver. Now he was co-founding Slack.

Across from Cal sat the other two founders: Eric Costello and Serguei Mourachov. Eric lounged in his chair, one hand idly surfing on his laptop. His restless look suggested he was ready to skip the slide deck and jump into the work. Eric had been figuring out how to make software in web browsers since the 90s, inventing new user experience conventions that then became common as others adopted them. He led Flickr’s frontend team and the development of Glitch’s Flash client. He too had worked with Stewart since Game Neverending and everything since. Eric’s irrepressible good humour contrasted with Cal’s sarcastic demeanour.

Serguei Mourachov was Stewart’s oldest partner, joining together during the dot-com bubble and riding the wave since it burst. Serguei had immigrated to Canada from Russia in the late 80s. He briefly served as a Soviet tank driver before fleeing the country. These days he helmed the Java servers that powered the messaging layer of Glitch, keeping all the player’s clients in sync and up to date. Serguei sat with his elbows on the table, giving Stewart his attention and a quizzical head tilt.

Filling out the table were those of us Stewart had asked to stay after Glitch closed.

Myles Grant joined the Flickr team at Yahoo shortly after the acquisition. He’d become a partner to Cal as they scaled the service, and had followed the founders to Tiny Speck and now to Slack. Myles was the kind of guy who would solve whatever problem needed attention, and couldn’t help but find and fix other problems along the way. He sat, calmly awaiting new information.

Brady Archambo had joined Glitch as its sole mobile developer, single-handedly writing the game’s mobile apps. A quiet Texan, Brady was soft-spoken and easy-going. He’d be in charge of building Slack’s mobile clients as well.

Johnny Rodgers had been hired about a year before. His experience as a jack-of-all-trades web developer and designer had proved useful in the time since. He would partner with Eric to build the web client and with Stewart to work out the design.

Ali Rayl and Stewart were the only ones at the company not being paid to write code, though Ali was a confident programmer in her own right. She joined Glitch in its waning months to lead the QA team, but turned her attention to contributing code, writing documentation, reproducing bugs, responding to incidents, supporting customers, and generally making everyone’s lives easier.

“So, what do you think?” Stewart asked the room of veterans and generalists he’d assembled.

Ready to build

In many ways, we had a giant head start on the first milestone. The concept for Slack had evolved from Tiny Speck’s own internal communication tools. Over the years that the company worked on Glitch, our IRC server had been extended to support file-sharing, simple search, and a basic archive. This had given us a concrete model of the core meaningful features we needed to build, honed by years of extreme pragmatism — we hadn’t built anything extraneous into this system.

But we were starting with a clean slate: we did not intend to use any of the old code that we had cobbled together. We were not building an IRC client, after all. Instead we needed to redevelop the core ideas using our own code. We used the tried and true LAMP stack (Linux, Apache, MySQL, PHP). We were all deeply familiar with these conventional tools, and Cal and the Flickr team had defined a framework for building out and scaling web applications using them (called flamework for Flickr framework).

We would repurpose Glitch’s Game Server, written in Java, to become Slack’s Message Server. In Glitch, a player logged in, saw which of her friends was online, chatting live with whoever was around and sending async messages to those who weren’t. Many of Slack’s core concepts — of users (players), messages, and presence — were thus portable from the game, and the Java code was essentially agnostic to the application domain. 

The Slack clients would comprise most of the new territory for initial prototyping. We would use standard techniques on the web — JavaScript, HTML, and CSS — and would write native apps on iOS and Android. Our approach to technology selection was driven by functional simplicity and proven effectiveness. We avoided exotic technologies and techniques except where nothing else existed, and focused as much of our technological investment as possible on bearing out the product vision. We didn’t have any designs to work from, preferring instead to work directly in prototypes to figure out how it should work.

Cal took over the projector and opened a new spreadsheet. He started typing in tasks and assigning them, his fingers on the keyboard generating a tight percussive rhythm on the table. He added items as quickly as we could read them, and within a few minutes we were looking at a rough pass of what needed doing to reach our first milestone, our initials marked neatly beside each in square brackets. We were ready to start building.