Rolling out Slack at scale

Anyone who’s managed a software rollout at scale will tell you it’s no easy task. People are creatures of habit, and habits are especially hard to break in the workplace. Dave Macnee, a manager of customer success at Slack, knows this anxiety well. He regularly coaches administrators, team owners, advocates, and executive sponsors as they deploy Slack to many thousands of employees. At the first stop of our 2018 Frontiers conference in San Francisco, Dave shared a few of his most tried-and-tested rollout tips.

If you’ve been entrusted by your company to get the most possible value from Slack, or see your team scaling up in the near future, this advice is for you.

Slow down to speed up

For many companies, “rogue” installs of Slack often come from a few internal teams testing it out on their projects before realizing they love it and want to adopt it more widely. While a company’s first instinct might be to jump in and quickly deploy Slack across the organization, successful teams take a moment to slow down before they speed up. Take a step back, think about the company’s vision for using Slack, and then lay out those goals in a project plan.

To ensure success, especially at larger scales, you have to set boundaries and ground rules for Slack. Determine which business processes and workflows will benefit from being incorporated into Slack channels and which will remain as they are. There are most likely several managerial oversight meetings you can skip once project discussions take place in channels, but maybe there are financial regulations that require some meetings to continue unchanged. If you have a goal of transparency, make rules about when and what subjects are acceptable in private channels, while setting other channels to public by default.

Once you’ve taken a step back to assess your goals, you’re ready for the next stage.

Lay foundations for scale

Launching Slack across a company requires a bit of planning, so you’ll want to assemble a team of experienced Slack users to help lead the charge. These are your “Slack champions”—they know their way around the product and should have a place on your launch team to help develop foundational rules.

One of the biggest first steps of laying a foundation is figuring out your channel naming conventions. We’ve written a whole piece about this in the past, but put simply: Determine what channel name prefixes and suffixes you’ll follow to make it easier to predictably find channels in the future. Let’s say you prepend all project channels with #proj- and you hear about a new internal project code-named Spinach—chances are you’ll find a #proj-spinach channel if you check your Quick Switcher. If you have shared channels with clients and you happen to run across #acme-sc, you’ll know it’s probably a channel shared with the Acme Corporation.

It’s also a good idea to remind everyone to fill out the channel purpose and set a descriptive topic whenever a channel is started. That way, when others run across a channel sometime later, they can understand why a channel was created and what subject matter people are using it to discuss.

Train and support employees

Remember your Slack champions? They’re a key resource for helping others get started with Slack. Have them available to answer questions either in direct messages or, better yet, in a #slack-help channel you create to let anyone in the company post questions and read answers.

You should also develop custom-tailored documentation for your company so every new hire and member of your Slack team knows how to download, launch, and log in to Slack on their desktops and phones. Consider adopting user groups to assign default channels to any members who get added to internal teams. For example, the next time new hires join @it-team, they’ll be be added to a dozen information technology channels on their first day, automatically.

Gather feedback to keep improving

Anytime a company adopts a new tool, it’s worth having a feedback loop to check its effectiveness after launching. There are a variety of ways to do that, either formally through things like regular NPS reports or informally through surveys and requests for comments. Identify red flags that can be addressed, but also pay attention to any internal teams that are slow to adopt Slack. Sometimes specific groups have needs that aren’t being met and could use some guidance, while other times it’s the nature of their work to do it elsewhere.

It’s quite alright to review the rules that are in place and to modify existing policy to match what users want and need.

Above all, a successful rollout takes time, and it starts well before you begin onboarding users. Identifying key people and teams inside your organization and crafting a good set of documentation are foundational steps. And once Slack is out there, keep tabs on team satisfaction and make any necessary tweaks to help keep everyone working together.