How Slack’s own developers use Slack

Best practice in our engineering teams.

How Slack uses Slack

You might’ve heard Slack’s origin story: it began life as an internal tool that helped to improve collaboration within a games development company. 

Fast-forward to today, and Slack is used by teams all over the world and in every area of business, from marketing and sales to HR and customer support, not to mention engineering teams. It’s a collaboration hub that brings together people, data and applications. And it’s highly adaptive, altering to suit the structures and working styles of all sorts of teams.

To demonstrate the value that Slack brings to teams, it’s often easier to show rather than tell.

As a company with engineering teams of our own looking to realise the full value of Slack in everything they do, we thought it made sense to turn the spotlight on ourselves.

So here’s the story of how Slack’s developers use Slack in their everyday working lives.

Every team is different, so what works for us won’t necessarily work for everyone. But read on for some insights into the ways our engineering teams use Slack.

Vertical and horizontal collaboration

No two engineering teams are the same. Your setup will vary depending on your size, structure, industry, whether your engineering teams are building a core product or supporting the wider work of the organisation – or both. The list goes on.

As a company with a product engineering focus, Slack has a number of engineering teams.

Some organisations might have a traditional waterfall team structure, split according to development process chronology: architects, then developers, then testers and so on.

At Slack we split our teams according to vertical pillars instead:

  • Platform: The team responsible for external development-facing features, such as APIs
  • Core: The team who work on Slack as most users know it: the core product
  • Enterprise: The team who make sure Slack can be scaled up for big businesses
  • Infrastructure: The team responsible for the back-end side of things

Each of these teams has their own goals and processes, but they all have to work together at different times, so collaboration has to be vertical and horizontal.

That’s why we have cross-team channels that are project or goal-specific – for managing a feature launch or for end-of-quarter reporting, for example.

Then there are function-specific channels, such as the one we use for front-end developers to share best practices across teams.

Let’s take a closer look at one of these four pillars, the Platform team.

How Slack uses Slack: the Platform team 

Again, each team use Slack differently (that’s the beauty of it), but the Platform team will give you an idea of how we use our own hub.

Like all of the four main engineering teams at Slack, the Platform team have a team channel that serves as their main base.

This is where general team announcements happen. All team members are present and the channel is open to employees from other teams who want to stay on top of what’s going on. Then each feature in development has its own set of subteam channels. For example, the Block Kit team have the following:

  • #devel-block-kit

Where day-to-day work is discussed and managed by engineers, project managers, designers, testers and others. Here you’re most likely see things such as code merges, design updates and drafts of product specs.

  • #feat-block-kit

Content in this channel relates to discussion about the feature as a whole. Product, design and development agree on what is in or out of scope, pin down specific requirements and make decisions as edge cases arise.

  • #gtm-block-kit

Channels with a “gtm” prefix are where the go-to-market strategy for a new product launch is discussed.

In the past you might have a load of email notifications about incidents, outages or code updates, but you can’t really do anything with them. In Slack, you see the notification in context and you can handle it right there.

Mike BrevoortDirector of Software Engineering, Slack

We have triage and escalation channels for the management of bug reporting, incidents, outages, etc. The PagerDuty app posts incident alerts in an appropriate channel and lets you use triaging right within Slack.

Almost all our channels are open – even to people from other teams with a general interest in what the Platform team are getting up to – but sometimes we do need private channels. We have a private leadership channel for management and for discussing how to cascade important comms to the rest of the team.

How we use Slack apps

When we say “Slack apps”, we mean things such as the PagerDuty app we mentioned in the previous section: an app that makes your critical software tools accessible and usable within your Slack workspace.

Here are a few key engineering use cases where Slack apps help our teams work smarter.


We use Slack apps that funnel push notifications from GitHub and other services. This automates and streamlines communication, leading ultimately to faster, safer code deployments.

Bug tracking

We can preview and address Jira tickets in Slack without having to find and open the URL.

Form details are already filled in so that tickets are automatically put into the right place for triage. And we use quick visual cues to speed up our work. For example, we use ⚪, 🔵 and 🔴 emoji to prioritise tickets and a custom app organises them based on those priorities.

When someone reviews an item, they use a 👀 reacji then a ✅ to show that it’s been resolved.

Customer support 

Every Zendesk ticket that’s created is funnelled into a relevant Slack channel so it can be easily dealt with in collaboration with teammates.

We use a lot of apps (both custom and publicly available) in our Slack workspace, but even built-in Slack functionality like reminders are a great way to rally the team and discuss what’s happening today. That simple function has saved us from interrupting individuals with a daily meeting.

Brian NgoSenior Engineering Manager, Slack

Graphs for quick insights 

Instead of logging into other software, you can pull handy graphs right into Slack, spot problems and act quickly to correct them. For example, a graph might monitor your API’s rate of 500 errors and give you an at-a-glance view of a recent spike that could signify a server issue. 


Some of the Slack apps we use for DevOps 

Over to you

So there you have it – a snapshot of how Slack uses Slack itself.

But it’s just one example of many – even within our engineering teams, there are lots of different ways we use our own platform to work in a smarter way.

Learn more about building bots, apps, tools and workflows for Slack here or contact sales for a chat about how your engineering teams can make the most of Slack.

    Was this resource useful?


    Nice one!

    Thanks a lot for your feedback!

    Got it!

    Thanks for your feedback.

    Whoops! We’re having some problems. Please try again later.