The company that became Slack spent 2012 failing at something else. Tiny Speck, founded by Stewart Butterfield after he had already sold Flickr to Yahoo, was building a browser-based multiplayer game called Glitch. It had charm, a devoted small audience, and no path to a viable business. Glitch shut down in late 2012. The team that had built it was distributed across several cities, and to coordinate that work they had built themselves an internal messaging tool on top of IRC. That tool was the only asset worth keeping. Slack was announced the following year, and the name is a backronym — Searchable Log of All Conversation and Knowledge — which tells you precisely what the team had decided the valuable part was. The pivot is a good story. The more useful observation is that almost nothing in Slack was new. Persistent chat rooms, one-to-one messaging, searchable history, file sharing and integrations existed in commercial products years earlier. Campfire launched in 2006. HipChat entered beta in 2009. The capability was available, buyable and largely ignored. So the question worth asking about 2012 is not what Slack invented. It is what changed between the era when these tools existed and nobody adopted them, and the era when they became unavoidable.
What Had to Be True First
Five conditions came together in roughly this period, and none of them was a feature. Distributed work stopped being exceptional. In 2006 a team in one office had a working alternative to chat: the office. By 2012 development teams, agencies and startups were routinely split across cities and time zones, and the cost of not having a persistent shared channel had become obvious rather than theoretical. Email had visibly failed at internal coordination. Not as a medium, but as the default for every internal conversation. Reply-all threads, unsearchable attachments, new joiners with no access to context — the pain had accumulated long enough that people were looking for an alternative rather than needing to be sold one. Mobile made persistence valuable. Chat tools built before smartphones assumed you were at a desk. Once everyone had a capable phone, a persistent channel you could pick up anywhere became meaningfully different from a desktop client you logged into at work. SaaS purchasing had become normal. A team lead could sign up, put it on a card and have twelve people using it the same afternoon. The 2006 equivalent required a server, IT involvement and a procurement conversation — which is to say, it required someone senior to care. Integrations made the tool a hub rather than a destination. Build notifications, ticket updates, alerts and deployment messages flowing into the same place as conversation is what made chat load-bearing. Without that, it was another window to check. Slack's genuine contribution was assembling these into something that felt good to use and required no decision from anyone senior. That is product work of a high order. It is not invention, and the distinction matters for anyone trying to predict what adopts next.
The Timing Lesson for Buyers and Builders
The pre-history of Slack is the clearest available case study in a pattern that repeats constantly: being early is indistinguishable from being wrong, right up until it is not. Campfire and HipChat were correct about the product and early on the conditions. They built real businesses — HipChat was acquired by Atlassian in 2012 — but neither captured the category, and Atlassian eventually migrated its chat customers to Slack in 2018. The first mover advantage that theory promises did not materialise, because the market was not there to be moved. For technology buyers this argues for a specific discipline. When a category is repeatedly pitched to you and repeatedly fails to take hold, the useful question is not whether the product is good. It is which external condition is missing, and whether that condition is close. Categories do not fail permanently for lack of features; they wait for a change in how people work, what devices they carry, or how software gets bought.
What Organizations Got Wrong When Chat Finally Arrived
The adoption wave that followed produced its own well-documented problems, most of which were avoidable. It was added rather than substituted. Most organizations kept email at full volume and added chat on top. The result was two channels to monitor and no reduction in anything. Chat only pays for itself if something else genuinely shrinks. Channel sprawl arrived within months. Unmanaged channel creation produces hundreds of rooms, most inactive, with the same conversation happening in three of them. The searchable archive that was the entire premise becomes harder to search, not easier. The expectation of immediacy was never addressed. Chat looks synchronous. Without an explicit norm about response times, people begin treating every message as urgent, which destroys the concentration that distributed work depends on. Retention and governance were decided by default. Organizations that would never have let email retention be set accidentally allowed years of internal conversation, decisions and shared files to accumulate under whatever the default plan provided — or to vanish under it. Decisions moved into an unstructured medium. Chat is excellent for coordination and poor as a record. Once approvals and decisions happen in channels, reconstructing why something was done becomes an archaeology exercise.
Practical Guidance for Collaboration Stack Decisions
- Name what the new tool replaces and measure whether it did. If internal email volume has not fallen twelve weeks after rollout, you have added a channel rather than changed one.
- Set channel conventions before adoption, not after. Naming, ownership, archival criteria and a default lifespan. Retrofitting structure onto four hundred existing channels is far harder than establishing it with forty.
- Write down the response-time expectation. An explicit norm — chat is not urgent, use a call for urgent, no expectation outside working hours — is the single cheapest intervention available and almost nobody makes it.
- Decide retention deliberately and align it with your records policy. Whatever the answer, it should be a decision. Regulated sectors should assume chat is discoverable and plan accordingly.
- Keep decisions out of chat, or move them out promptly. Coordinate in the channel, record the outcome somewhere durable. The searchable log is a search tool, not a decision register.
- Watch for the shadow version. If teams are already using a consumer messaging app for work, that is demand signalling. Meeting it with a governed tool is better than prohibiting it.
- Treat integrations as the adoption mechanism. The tool becomes essential when the systems people already watch report into it. Prioritise those connections over rollout breadth.
- Plan the export. Years of institutional conversation in a vendor's archive is a dependency. Know what leaves with you and in what format before it matters.
The Condition That Is Changing Now
The reason to revisit any of this in 2026 is that the value of the searchable log has shifted again. For a decade, the archive's worth was limited by human search. You had to know roughly what you were looking for, and the recall was poor enough that most of the accumulated history was dead weight. AI assistants that can read across an organization's message history change that calculation — which means every retention decision, access permission and channel-privacy setting made casually over the past ten years is now consequential in a way it was not when it was made. That is worth a deliberate review rather than a default. The same logic that made chat valuable when work went distributed is now making the archive valuable in a new way, and the governance mostly has not caught up.
Common Questions
What is the origin story of Slack?
Slack grew out of an internal messaging tool built by Tiny Speck, Stewart Butterfield's company, while it was developing the online game Glitch. Glitch shut down in 2012 and the team pivoted to the communication tool, announcing Slack the following year. The name stands for Searchable Log of All Conversation and Knowledge.
Was Slack the first team chat tool?
No. Campfire launched in 2006 and HipChat entered beta in 2009, both offering persistent rooms, searchable history and file sharing. Slack's advantage came from timing and execution rather than from inventing the category.
Why did team chat succeed in the mid-2010s and not earlier?
Distributed work became common, email's failure at internal coordination became widely felt, smartphones made persistent channels valuable, SaaS purchasing let teams adopt tools without approval, and integrations turned chat into a hub for other systems.
What should you set up before rolling out a chat tool?
Channel naming and ownership conventions, an explicit response-time norm, a deliberate retention policy aligned to your records requirements, a plan for where decisions get recorded, and the integrations that will make the tool part of daily work.
Collaboration Stack Assessment — Outpace reviews what your tools are actually replacing, where your conversation history is accumulating, and what your governance is missing.