How Slack uses Slack
You may have heard Slack’s origin story: it began life as an internal tool that helped a games development company collaborate better.
Fast-forward to today, and Slack is used by teams all over the world – and all over the enterprise, from marketing and sales to HR to 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 that 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 that 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 dev-facing features like APIs
- Core: The team that works on Slack as most users know it: the core product
- Enterprise: The team that makes sure that Slack scales 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 that 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 uses 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:
Where day-to-day work is discussed and managed by engineers, project managers, designers, testers and others. Here, you’re most likely to see things such as code merges, design updates and drafts of product specs.
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.
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.
We have triage and escalation channels for managing bug reporting, incidents, outages and more. The PagerDuty app posts incident alerts in an appropriate channel and lets you triage 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 that 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.
We can preview and address Jira tickets in Slack without having to find and open the URL.
Form details are pre-filled, so 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 resolved.
Every Zendesk ticket that’s created is funnelled into a relevant Slack channel so that 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.
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 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.