It’s a fairly uncontroversial statement that Slack has changed the workplace communication space. Over 12 million daily active users can attest to the value of the product and the paradigm shift that it has introduced.
I was lucky enough to chat with Bear Douglas, Director of Developer Relations in order to get a look into how Slack functions internally, both in terms of how they think about meetings and communication — Yes, that includes how Slack uses Slack.
Developer Relations is critical to Slack’s success. There are over 700,000 weekly active apps developed on the platform from smaller independents and mega-corps alike, and Bear and her team are tasked with improving the developer experience for all of them.
Meetings and processes evolve as the teams evolve. What worked for you at 10 people might not work for you at 20 might not work at 30 and so on. Bear explained her thinking around process lifecycles:
“When it comes to processes, my attitude has generally been that all processes and all meetings have a life cycle. And so we have been through different formats and outgrown different formats over time.”
The Developer Relations team at Slack currently consists of approximately 20 people across different time zones, so the group follows a hierarchical model where small teams specialize and the team leads make departmental decisions together.
When the team started their regular update meetings, it was run weekly with a shared document of hot topics that warranted discussion. Once the hot topics are covered, the team would go around the room (or video call) and each person highlighted one item from their updates. This allows people to get an idea of what others are doing, without overburdening the group with unnecessary details. This worked well, for a while.
Eventually, the team grew to 20-30 people and the process had to evolve. Now, the departmental meeting takes place biweekly and leans on a more “big picture” approach.
Teams give updates on the Objectives and Key Results (OKRs) for the group, and then have a guest speaker on a specific topic.
“With a group that size, you want something that’s not just a status meeting. You also want something that is still primarily broadcast, because 20 people can’t really have a functioning conversation about something. Recently, we’ve used Zoom breakout rooms to have discussions about the presentation in smaller groups.”
Bear notes that as your team grows, people may feel uncomfortable. At first, they don’t know what everyone on the team is doing, but the initial discomfort passes as people realize it’s just simply not possible to know all the details. For anyone with the inclination and the time, all the information is available on Slack or other channels.
Today, status updates, discussions, and requests have moved to Slack rather than requiring real-time meetings. Similar to setting up the right formats for meetings, setting up the right formats and channels for Slack conversations have contributed to the team’s effectiveness in using these kinds of asynchronous channels.
Bear’s team has an interesting setup for managing Slack communications, where different use cases and discussions are split out into independent channels instead of throwing everything into the same chat.
Although theoretically, it seems that the reviews channel would be superfluous, it turns out that using a separate channel results in a much higher response rate. It may be because it prevents threads from getting lost in the noise, or because there’s a different psychological trigger being activated. Whatever the case, it works.
In addition to these communications, Bear sends up a weekly roundup in the public channel with 3 items that shipped, 3 upcoming releases, and links on other activities going on within the team.
When Bear described the shift, it was as a circular process. When there’s a small team, everyone is aligned on the same goals, and you expect people to jump in and help one another to cover different domains. As the department grows, people specialize more.
While specialized teams work well, they can also lead to a lack of coordination and differences in priorities within the department. How do you avoid the siloing of teams and create an environment where people still work together towards shared goals?
Bear and the leaders of each sub-team create a “Top Projects” list which prioritizes the deliverables of the team so that the team as a whole meets its goals. Agreement on the top projects allows everyone to prioritize their work both within the teams and across the entire process:
“The top projects list is designed to show that you can borrow time from other teams. If we agree on those top projects that are shipping, we set the expectation that someone might come to you and say, “Hey, I need some engineering help on this,” or “folks on my team don't have a specific expertise. Can I have some of this person's time?” It's a different mode of thinking. Usually if you are under pressure, the first reaction is to ask for more headcount. The new mindset is to think about your team not as three people but as 25 people.”
Having individuals work across the teams within the department gives people the opportunity to know one another better, attend different teams’ meetings, and learn from the processes in different teams. Keeping one set of priorities means that everyone has a sense of pulling together towards a shared goal.
When you consider this in conjunction with evolving processes and effective communication, it’s no wonder Slack is the powerhouse that it is.