Behind the Team: How Communication Processes Evolve at Slack
Chatting with Bear Douglas, Director of Developer Relations at Slack
Hey there š
My name is Conor. Iām helping shape how teams work at Hugo, bringing together your meetings, notes, and tasks all in one place. Future of Teamwork is where I feature the best insights on productivity, communication, and culture in the workplace. š
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.
In this article youāll learn:
How to evolve your meeting lifecycle as headcount grows
Using Slack the Slack-way to maximize team efficiency
Moving from specialized teams to departmental collaboration
š Lifecycles and team evolution
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.
š How Slack Uses Slack
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.Ā
The Developer Relations team uses the following channels:
Public channel, #team-devrel, for a company-wide interface with their team.
Private team-only channel (#devrel-only) for the team to socialize and share internal issues or topics they donāt necessarily want to publish or discuss more widely with the company.
Intake channel (#plz-devrel) where other teams in the company can make specific requests to the Developer Relations team, which can be triaged and managed.
Reviews channel (#devrel-reviews) where the team members post content or material that require review by other team members.
Status channel (#devrel-updates) for status updates and news. The leadership models and encourages updates that arenāt strictly work-related, for example, if people are dealing with stress due to their environment or if they did something fun over the weekend.
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.
š£ Keeping your team aligned
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.
If you enjoyed this issue and youāre feeling generous, like or retweet the post on Twitter. You can also show support by sharing Future of Teamwork with friends or subscribing if you havenāt already. š„
Until next time,
Conor