Four Worst Slack Practices
by Scott Reece, on Jan 14, 2020 4:44:22 PM
Slack has become a leading tool for DevOps-focused teams. It makes sense: after all quality communication is a hallmark of a well-run team. Tools that enable that communication are an important element of success.
But some companies treat Slack as a “magic bullet,” forgetting that (as with any tool) how you use it is just as important as the tool being used. Just like you wouldn’t use a hammer to split a 2x4 in half, using Slack in the wrong ways—or, more commonly, failing to take advantage of all its features—can create new problems that distract your teams from important issues.
With that in mind, here are four of the worst Slack practices that your teams should make sure to avoid.
1. Not Using Slack Integrations
Part of the reason Slack is so popular among IT teams is its integration with other tools like GitHub, Jenkins, Jira, and many more. But many teams start using Slack based on its good reputation and merely end up treating it like any other instant messenger platform. Doing this means paying for a tool but using only one small fraction of its functionality. This is a really poor ROI.
Integrating Slack with the tools your Dev and Ops teams are already using creates a space for auto generated notifications. For example, setting up a notification for when an application gets to the quality assurance (QA) part of its release pipeline lets the Dev team see that the build has moved past all of its automated tests, lets QA teams know that they can start testing the build for issues and completeness, and lets Ops know that a release may be ready for the public soon. This significantly reduces feedback loops and centralizes all communication about that application inside Slack. Slack also creates a record of the communication, meaning you have a history of who did what and when right in Slack.
Obviously setting up meaningful integrations will vary from team to team, but not setting them up at all means you’re not taking full advantage of this paid tool.
2. Not Creating Channels Where You Want Conversations to Happen
Unexpected errors are a cliched reality of IT. Having a shared space to discuss, share, and solve them not only helps fix errors quickly, it also spreads knowledge across teams so that, in the future, those same errors are fixed quickly or don’t happen at all.
But these benefits quickly evaporate when you have only one space for problem-solving. A single Slack channel for IT can quickly turn into the floor of the New York Stock Exchange during trading hours—a swarm of communication chaos where meaningful conversation is nearly impossible. In such a poor environment, problems may take much longer to be solved or may fall entirely through the cracks, both which lengthen lead times and hurt business.
Creating individualized internal groups channels within Slack means each group has a dedicated space for people to post and receive only the specific notifications that matter to them. For example, in addition to an all-team channel for emergencies and announcements, having a “Dev” channel, “Ops” channel, “QA” channel, and so on means each team has a focused space in which to discuss specific problems and solve them. This avoids distracting teams from their work with irrelevant (and maybe even constant) notifications.
3. Not Using Slack as a Community Platform
Using Slack internally in an expansive way helps your team share information and learn from each other, however knowledge exists outside of your organization. But paying for Slack gives you much more than this.
Slack has many different public groups that DevOps teams often join to tap into the “hivemind” of other Slack-using teams. Sometimes getting help or advice from uninvolved parties can yield fresh ideas and answer questions more quickly than team meetings.
Some popular community channels DevOps teams use are:
DevOps Chat is one of the most highly used Slack channels that covers a variety of topics including configuration management, deployment, and Docker. If developers have a question on a topic that cannot be answered internally, these forums serve as a tool to receive answers, best practices, or other ways of looking at a problem.
The #Developers Slack channel is a global community for developers around the world. Channel topics include testing, deploying, debugging, and packages.
#DevChat Slack features over 50 different channels to help software developers come together to solve problems and learn from one another. Links, resources, and answers are shared in real-time, meaning questions can be answered quickly.
There are also tool-specific channels like #Kubernetes, #Docker, and more. You can search and join these channels from Slack’s Channel search.
4. Policing How Teams and Individuals Use Slack
While the previous three “Must Don’ts” dealt with not using Slack’s full functionality, on the other hand is policing the way your teams or individual workers use this tool. Micromanagement kills innovation and worker morale. Limiting how your people use Slack hurts them and, ultimately, the business.
There is no “one-size-fits-all” way to do DevOps—or to use Slack. Each team and organization will need to find out for themselves how best to use this tool, its offerings, and its many options. Trial-and-error is a natural part of onboarding a tool. Clamping down on who may do what with Slack may make it much less useful than it might otherwise be and can even lead to a “black market” of communication that actually meets workers’ needs.
Remember that communication is a human activity and greater communication is the goal. Allowing people to communicate with Slack as they do in real life is vital to making this tool worth the cost. Creating strict, onerous rules that must be followed about what gets posted, where, by whom, how quickly, etc. just discourages people from using the channel entirely.
Communication is Key
Encourage your teams and people to make the most of Slack. By avoiding these worst Slack practices, you can create a platform that allows seamless communication between teams, letting you iterate faster, shorten lead times, and maintain your market edge.
Inedo DevOps tools maximize developer time, minimize release risk, and empower stakeholders to bring their vision to life faster. All with the people and technology you have right now. To get help streamlining your CI/CD processes, contact firstname.lastname@example.org, or find us on Slack at #BuildMaster, #ProGet, and #Otter.