Using Slack like a Slack developer

How Slack uses Slack

You might have heard Slack’s origin story: it began life as an internal tool that helped a games development company to 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 channel-based messaging platform that brings people, data and tools together in one central place. 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 its own engineering teams looking to leverage 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 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.
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 that works on Slack as most users know it – the core product

• Enterprise: the team that makes 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 

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 workspace.

Like all of the four main engineering teams at Slack, the Platform team has 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 has the following:

• #devel-block-kit

Where day-to-day work is discussed and managed by engineers, project managers, designers, testers and others. Here, you can expect to 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, nail 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.

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 them right within Slack.

Almost all our channels are public, and people from other teams who have a general interest in what the platform team is building will join. But sometimes we do need private channels. For example, we have a private leadership channel, and another 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 common scenarios for which Slack apps help our teams to work smarter.

Deployments

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 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 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.

Graphs for quick insights 

Instead of logging in to 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 that we use for DevOps 

Over to you

So there you have it – a snapshot of how Slack uses Slack itself. This is just one example of many. Even within our engineering teams, there are lots of different ways that we use our own platform to work more efficiently.

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.