Lots of engineering teams (including ours) use Slack to manage their software development process. We were curious: exactly how do these teams use Slack to keep their work focused and ship stuff faster? So we did as we do, and talked to a bunch of technical teams to find out what works best for them.
TL;DR: Every channel should have a clear reason for being. From there, take advantage of the Slack platform — by using off-the-shelf apps from the Slack App Directory, or building home-grown integrations to pipe in data from internal data sources — to commit and review code, fix bugs, and manage deployment and keep everything running just as it should.
One thing we heard loud and clear: well-organized public channels — where anyone on your team or at your company can stay informed, seek help, and complete tasks — are of utmost importance.
While it may seem like having fewer channels would keep things simpler, we actually recommend an organizational scheme of more channels, each with a specific purpose — this can help to focus work among smaller groups of people who want and need to know the nitty-gritty.
Here’s a channel organization scheme we heard works for a lot of engineers:
General software team channel: Teams usually have a top-level, large membership channel (e.g. #engineering) for all managers and individual contributors from different disciplines (front-end, back-end, deployment, etc.) to talk and solve problems together.
Project channels: Use a naming convention to organize channels for each new feature. If each channel starts with something clear and recognizable like #project- , it’ll be easier to find.
“Your interface is discoverability,” says Nic Benders, chief architect at New Relic. “If I need to talk to somebody on the insights team, I should be able to pop into Slack and post in #insights-team to find help.”
Interest-area channels: Create a channel for each technology or sub-group in engineering, for example #security, #ios, or #java, where specialists can gather. At New Relic, Benders calls them “communities of practice.”
Automated output channels: Some teams organize their notifications from software services (some examples below) into a dedicated channel collecting the output, while others instead report specific notifications into project- or team-specific areas.
Software development commonly falls into four general areas: writing code, fixing code you’ve already written, publishing it, and keeping everything running and stable. Let’s break down how each part works in Slack.
A software engineer writes code to build and improve product features, and code repositories are key to coordinating it all. A code repository allows a team to work on different aspects of a codebase concurrently, while also managing contributions and code review.
Typically, a developer branches out from the master codebase, deploys to their own local environment, and makes changes. When they commit their code to the cloud, notifications from apps like GitHub and Bitbucket appear in specified Slack channels.
Piping commit messages into Slack raises the visibility of a developer’s work and helps managers track progress. In the event of a problem, it also provides a breadcrumb trail of recent changes that might need to be rolled back.
Pushing changes to the main codebase requires a pull request, and that’s another activity where visibility in Slack can facilitate code reviews and reduce context switching.
Some teams create bots to check outstanding pull requests every morning to make sure a review hasn’t fallen through the cracks:
Most companies use off-the-shelf apps available in Slack’s app directory, while others, like Vox and its CTO Pablo Mercado, go the custom route. “We take GitHub webhooks and we pass it through our own API layer that then posts to Slack, because we want to customize the amount of output that comes through,” he says.
Piping bug tracking alerts into Slack is another way your team can be notified in the same place they’re already discussing bugs and code reviews — saving you from constantly switching between apps and browser tabs.
When bugs are reported, channel messages can be used to assign work and monitor progress:
Get it out there
You can also catch any failures in the build process and get people talking right away about how to fix them.
Other teams launch build-and-deploy events using slash commands (e.g. /deply project-rocket) inside Slack. Still others create custom bots to convert release checklists into multi-step bot interactions that ensure every step for rolling out a new site or app is followed.
“Developer attention is the scarcest resource on the engineering team, so it’s crucial to have a deploy process that makes really good use of it,” says Aaron Suggs, operations engineering manager at Kickstarter.
“It requires very little developer attention because it’s so automated, and if things are broken, it just stops deploying. That’s a really valuable tool to invest in.”
Keep it running
The enormous responsibility of keeping a product online and stable is often the domain of a software operations team (commonly known as “ops” or “devops”). An ops team usually deals with uptime and maintaining infrastructure, and also helps manage minor service interruptions or major security breaches.
Incident response is a blanket term for when things go wrong, and engineering teams were nearly unanimous in their use of Slack as the mechanism for real-time information gathering, analysis, and triage — exactly what you need when things go haywire.
Ops teams most commonly use apps like PagerDuty, Pingdom, and New Relic for monitoring, error-reporting, and uptime packages. Alerts from these services automatically appear in Slack, and thanks to notification settings, ops team members can make sure they’re the first to know when something goes awry.
When you integrate the apps your engineering team needs into Slack, your team will stay up to date and organized right where they’re already working.
You’ll also get the added benefit of a searchable communication history that makes adding new developers to projects really straightforward. As Jeremy Mack, Director of Engineering at Postlight puts it, “The whole point is [for Slack] to be simple and easy to understand and get into for new people or people on a project — they’ve got the whole history right there.”
Matt Haughey uses GitHub but sometimes still has to look up what branch, diff, fork, push, and pull really mean.