How Big Technical Changes Happen at Slack

Revolutions and Fads: A Strategy for Technical Change

Most new technologies are fads: patterns of practice that flourish briefly and then vanish without leaving a durable mark. Microkernels, EPIC architectures, object request brokers, and 1990s-era neural nets all had their moment. They were championed by sincere, intelligent advocates who made plausible first-principles arguments for why their chosen technology would inevitably triumph. These were not frauds — the motivations were genuine. The outcomes simply did not match the enthusiasm.

A smaller set of new techniques are genuine revolutions: potent, lasting changes that confer lasting advantages. Object-oriented programming, hardware virtualization, the world wide web, public cloud, CI/CD, and modern deep learning are now permanent fixtures. At the time of their emergence, they were indistinguishable from fads. Slack’s goal is to catch the revolutions early while minimizing the energy spent on fads.

Distinguishing Winners from Losers

Relying on individual leaders’ intuition is unreliable — both precision and recall will suffer. Instead, Slack actively invests in experimenting with new things, accepting that most experiments will yield nothing. To tilt the odds in our favor, we kill experiments ruthlessly as soon as they fail to prove value. The aim is to try a little of everything, accepting that this means dabbling with fads, while still riding the transformative waves all the way to shore.

This approach can be described with a basic adoption curve model.

The Three Phases of Adoption

Technology adoption at Slack follows a typical sigmoid curve. The S-shape emerges from changes in the rate of adoption. In the early phase, only a few experimenters are involved, so adoption is slow. As the benefits become clearer, more teams join to capture them, leading to rapid adoption during the steep middle section. Eventually, the remaining use cases are the difficult ones, so adoption slows again near the end of the cycle.

We label these three phases as follows:

This pattern isn’t unique to software. Everett Rogers described the same phenomenon in his 1962 diffusion of innovation theory, based on his observations of how farmers adopted new techniques. The pattern holds for computing practice just as it does for agriculture.

React

React has transformed frontend development since its stable release in 2015. Its virtual DOM approach and unidirectional data flow made it compelling for Slack’s desktop UI.

• In 2016, React was foreign to Slack’s frontend codebase. During Phase 1, curious engineers experimented with it on pilot projects. To demonstrate its value, they rebuilt the emoji picker in React. This familiar and previously sluggish piece of UI was dramatically better in React. The functional prototype was far more convincing than any theoretical argument.
• As the team realized React would have a major impact, piecemeal adoption became inadequate. A complete rewrite was too risky. In Phase 2, a real migration project with a plan and staff was launched. Many teams opted into the new style as they created or modified views, while older views still needed maintenance.
• Phase 3 involved finishing the job by cleaning up the long tail of legacy views. Slack shipped a React-only desktop client in July 2019.

Hacklang

Server-side, Slack has been migrating from PHP to Hack since 2016, with the gradual introduction of types as a key part of that effort.

• Phase 1 began in 2017 when a few typing enthusiasts started adding obvious, easy type annotations to the codebase.
• Once bugs were caught by these early types before hitting production, others began using them too. This unintentionally accelerated adoption into Phase 2. The transition sparked the canonical static-versus-dynamic typing debate. Through discussion and accumulating experience, consensus emerged that increased type coverage was beneficial, and most teams chose to adopt types. After the initial easy wins, later Phase 2 work involved more ambitious typed migrations, systems to encourage typed new code, and extensive evangelism within the backend community.
• The hardest parts of the codebase were left for Phase 3. Rationalizing Slack’s internal object variants for channel types and converting complex core modules proved time-consuming.

Vitess

Vitess, a database clustering system for horizontal MySQL scaling, became central as Slack evolved its data sharding strategy.

• Phase 1 began as the team critically examined Vitess. Managing the homegrown sharding solution manually was tedious, and Vitess promised to automate most of the pain. The nascent Vitess team became convinced the technology was a winner.
• Moving low-risk production workloads, such as RSS feeds, to Vitess marked the start of Phase 2. Initially, only the Vitess team was involved, but operational support was still needed. As more tables moved over, the process became easier. Tools were developed for backfills, and a shared vocabulary emerged for describing migrations — including concepts like “dark-reads” of duplicated data and the problems that can arise.
• That progress eventually plateaued. Today, hundreds of tables representing more than half of the query workload have migrated, but some critical tables with complex dependencies and query patterns remain in Phase 3. Separately, a long tail of low-value tables requires different tooling for faster bulk migration.

LibSlack

Not every technology advances through all phases. LibSlack, the cross-platform C++ client library, did not move beyond Phase 2 and was ultimately discontinued.

• Phase 1 proved the concept: engineers built User and Presence implementations to validate a shared client library for business logic and caching. The logistics of compiling and shipping cross-platform code were also worked out.
• The project did not gain traction in Phase 2. Technical and strategic incompatibilities emerged between the library and the desktop client. Reimplementing existing logic in iOS and Android was cumbersome. Simultaneously, Windows Phone’s discontinuation reduced the need for the library.

The runway to full migration never materialized. The lessons from LibSlack were applied to the mobile and desktop clients in valuable ways. While the code artifact did not endure, the project shaped how Slack builds its clients and organizes engineering teams.

Why Adoption Curves Matter

The three phases described here are not the result of Slack’s processes, tooling, or milestones. They reflect how technical change naturally spreads inside any engineering organization. Early exploration is slow, middle-stage adoption is fast, and the final push to full migration is slow again. Recognizing this curve helps engineers choose the right strategy for where their project actually is, rather than fighting the dynamics of the phase they are in.

Phase 1: Exploration

The first phase costs nothing to enter. An engineer reads about an interesting technology, downloads it, and starts experimenting. No permission is required for this kind of dabbling, and it happens continuously across Slack. Most of these efforts end quickly, which is precisely the point: inexpensive exploration is a defense against chasing fads. Occasionally, however, the experiment proves useful to the engineer’s own team and gets adopted locally. When the solution looks broadly valuable, the engineer believes they know something the rest of the organization does not. Once the work starts affecting how other teams do their jobs, the project has moved into Phase 2.

Phase 2: Expansion

The engineer entering Phase 2 is no longer just building software; they are trying to change other engineers’ behavior. This requires persuasion, communication, and substantial technical work. It is the hardest part of the cycle and where most would-be changes fail to gain traction. Slack does not make this easier by centralizing authority: client teams are generally free to decline a dependency on your new system. There is no executive mandate that picks winners before teams have had a chance to evaluate the technology in real use. The burden of winning adoption rests on the change agent.

This approach deliberately prioritizes resilience to fads over speed of adoption. Teams that choose a system because it genuinely helps them are more likely to keep using it and advocate for it. Forcing a choice too early can lock in the wrong decision before problems surface. Phase 2 work, therefore, resembles product development more than traditional engineering. It requires user research to identify real pain points, communication that frames the new system in terms your audience understands, and building tooling that reduces the friction between current practice and the proposed change.

When teams begin adopting the system without being explicitly sold on it, the project is nearing the end of Phase 2. By the time the new approach is the default for new projects, it has become a de facto standard. That outcome is rarely accidental and demands skills beyond pure engineering.

Phase 3: Migration and Residual Holdouts

Self-propelled adoption eventually plateaus. What remains is a set of holdouts. Some are long-lived systems that work fine and have no reason to change. Others are cases where the old technology is genuinely better suited to the task, and a few are users simply attached to what they already know.

Many successful technologies never convert every use case, and that can be the right outcome. At Slack, gRPC is widely adopted as an internal API standard and is deep into Phase 3, yet memcached will not be rebuilt on gRPC because its custom protocol is well-supported and works well enough. The existence of such exceptions does not make the adoption a failure. Where the cost of supporting multiple approaches is too high, though, the migration must be completed deliberately. Different holdouts need different tactics: reviving stale systems may require the change agent to take ownership and begin modernizing them; functionally motivated holdouts may need capability enhancements or compatibility layers in the new system. For cases rooted in attachment, person-to-person conversation beats public debate. Someone’s elegant new system will be somebody else’s legacy eventually, and it is worth treating the old way with respect.

What Slack Expects From Engineers

Slack’s model for technology adoption comes with responsibilities for everyone involved, regardless of which side of a change they are on.

• Explore consistently. Engineers should spend some portion of their energy looking beyond their immediate roadmap. This is not a call to neglect commitments, but to stay aware of what is happening in the broader technical world.
• Be a reasonable customer. Teams that provide infrastructure need to evolve their systems too. That evolution may place costs on the teams that depend on them, and those costs should be communicated clearly and constructively.
• Break dependencies intentionally. Teams sometimes need to move off a downstack technology that no longer fits their needs. This is a legitimate part of setting technical direction, and it should be handled professionally rather than treated as a failure by the team being left behind.
• Adopt a customer-centric attitude while driving change. The success of a new system is measured by the satisfaction of the teams that use it. That requires outreach, feedback, iteration, and a real investment in helping others learn the new approach.

The long-term measure of technical success on any team is how well the people who depend on that team’s work are served by it.