How to intentionally structure & scale company communications
We live in a world of constant notifications, alerts, messages, and pings — in our personal lives and in the workplace. Though most know that this state of distraction impacts our ability to work and focus deeply on the hardest problems, it turns out that solving this problem is perhaps just as tough. It’s hard to do as a single-player and relies on changes to the underlying culture and systems to have a chance at success.
As a distributed team at Levels that works asynchronously, we’re ready to do whatever we can to ensure our team can do their best work and make progress towards an important mission. We take the responsibility to ensure that our tools, process, and culture allow for this.
Unfortunately, the traditional communication tools in a startup’s tech stack aren’t designed with those goals in mind. On their own, each tool is easy to set up, well designed, and has a compelling value proposition. The standard stack looks something like this:
- Google Workplace for internal and external email and calendaring
- Slack for DMs and group chats across work projects, affinity groups, social watercoolers, and work firehoses. As the tagline goes, “Slack is where work happens.”
- Google Docs and Sheets for knowledge work
- Zoom for sync video calls
The thinking is that once you set these up, you’re pretty much good to go! In practice, this is the moment the slope gets slippery. We started with the same toolkit out of convenience, but as we reverted to old habits and started feeling pain, we realized that a laissez-faire approach wouldn’t encourage the environment we hoped to create.
Modern knowledge workers increasingly spend most of their time communicating about their work rather than doing the work itself. (In one of my favorite assessments of the situation, people are just LARPing their jobs.) It’s easy to see how de facto work communication tools and practices are failing — details are lost, communication overhead is high, and people are stressed.Many dislike work not because of the work itself but the amassing of plaque around the work. We’ve ended up with an always-on work culture in an effort to keep up, and our ability to do deep, focused work is diminished. The result is a stressful and ineffective work environment that can lead to burnout and dissatisfaction.
According to Brook’s law, the number of communication paths grows at a faster rate than the number of people you add to the group. As a result, what worked for a small team of 10 won’t work for a team of 40. Actively designing and tending to the tools & process is essential.
We set out to solve these (and associated) pain points, and we ended up in a good enough spot for now — where asynchronous communication channels are prioritized and replace distractions like “quick questions,” firehose Slack channels, and other constant sources of notifications. Our internal communication is now organized, discoverable, and tracked in a tool called Threads. This supplements our use of Notion for long-form memos and process documentation.
The tools we’ve chosen to move away from — email and Slack — are the defacto “work OS” for getting things done at most similarly-staged companies in our industry, so we thought it’d be worthwhile to share our process for getting to our current state.
1. Establish the Vision
To start, we wanted to be clear about what we were working towards so that we could design with our distributed company values and culture in mind.
Our communication-specific principles are as follows:
- Work should feel calm & controlled, and our tools and process should allow us to triage and maintain clarity into actions and next steps.
- Relative priority should always be clear by creating distinction between communications that require reading, and those that require action (with a due date).
- Communications should be discoverable and transparent. With a few exceptions, communication shouldn’t be siloed by team or group. This limits others’ abilities to work autonomously and discover context that may be relevant to them.
- Communication should live in context, alongside the work being discussed. It should be compatible with how we get work done, written clearly, in long-form to prioritize asynchronicity and avoid the need for meetings to transfer information.
- Channels and mediums should be standardized. What goes where and what’s expected from each channel should be explicitly defined. Requests for input or response are explicitly defined and tracked. Each team and individual should not need to reinvent the wheel or implement their own process for handling communication.
- Response times & etiquette must be upheld. To avoid a world where everything must be marked urgent in order to ensure a quick response, we must trust that others will see our messages and respond to them in the agreed-upon time to unblock us to proceed.
- Our tools will only succeed if we have a process and structure for using them effectively and consistently. A great tool with all the right bells and whistles but without adherence is not enough.
You can hear me talk more about some of our principles for communication (and where they came from) here:
Your communication values may look different from ours. For example, you might work in an industry or role where real-time responsiveness to your coworkers or customers is important. I urge you to put in the time to pressure test those assumptions and define your values before you go any further.
2. Identify What’s Broken
Once we knew where we wanted to be, we looked over our current practices to find the misalignments. This meant looking beyond the ideals we had about how a tool could work (or the big promises these tools make in their marketing) and paying attention to what was happening in practice.
For example, email is a great tool for communicating asynchronously in theory, but we took note of all the cracks that show when it’s pushed to the edge. Email messages are inherently siloed and out of context. We noticed cases where someone missed a conversation they would have liked to chime in on with input. Because they weren’t included on the initial email thread, they didn’t know it was even happening (see an example of this in action below).
Email is also challenging to triage based on priority and convert into action steps. You can read an email and decide you don’t need to take action, but if replies come in later that do require your input, it’s hard to parse that out. Finally, we were seeing the volume of email increase quickly — with a team of 30, it wasn’t uncommon for a single thread to have dozens of replies over just a few days, all moving in different directions. We can and did use tools like Superhuman and Mailman to help our team be better at email, but being better or faster doesn’t control the overwhelming flow of information or fix the underlying issues. Keeping up with this firehose was a big challenge for our asynchronous working style across time zones.
Moving on to Slack — the core of the hyperactive hive mind (to use Cal Newport’s term) for most teams. Slack promises to allow you to “collaborate on your own time,” but telling our team to turn off their notifications or only check Slack once a day turned out to be futile. It’s well designed, fun to use, and really addictive. For example, if someone posted a message or link, we’d see dozens of emoji reactions, GIFs, and threaded replies flowing within minutes of the post. Slack encourages this. If a post was project-specific, a decision would often be made quickly as the conversation unfolded. Checking in a day later and trying to catch up on the thread to add your own thoughts was nearly impossible. No matter how intentional we tried to be, our use of Slack kept defaulting to the same way other companies use it: a steady stream of information where signal is mixed with noise and where “you had to be there” when it was live to add or retrieve value.
A lot of companies assume that communication friction is just part of doing work. But we felt these symptoms all pointed to breakdowns in how we were communicating as a growing, distributed, and asynchronous-first team — and ultimately threatened our culture and ability to work together effectively in a cool, calm, and collected way. Instead, we wanted to work with a tool that didn’t allow fast-moving conversations to happen before those who needed to were able to chime in — and that’s often on the timeline of hours and days, not seconds and minutes. The biggest culprit of these issues seemed to be any tool that blurred the line between synchronous and asynchronous, so we decided to start by exploring alternatives.
3. Test
When it came time to start making changes, we wanted to avoid haphazard decisions that might whiplash the team’s trust or hinder their ability to get work done. Few things are more frustrating than having someone else mess with your workflow.
Before making any big changes, we tried the simplest things. We reminded the team to use Slack and email in intentional ways that aligned with our intentions. But as mentioned, these tools are too well designed to fight our will and we inevitably ended up back where we started. We discussed simple process improvements for email — like adding prefixes to subjects — but these were incremental edits on a flawed system for collaboration. They weren’t substantive enough to address the deeper issues.
After exploring at least a dozen tools over the course of a few months, we discovered Threads and it seemed like it might have been able to solve many of the challenges we were facing. Product marketing landing pages are good at promising a lot, though, so we wanted to test drive this for ourselves.
We ran a month-long test with Threads with the intent of replacing internal emails and instant messaging. We started small with a handful of team members and projects. The need to loop others into where the work was happening came organically, and we let that run its course with open invites. A critical mass was working in Threads within a few weeks and we decided to go all-in for an honest trial. We communicated to the team that we were going to pause Slack for a full month and pressure test ourselves. Timing mattered — our team of 30 was adaptable and small enough to test fully, but also be able to revert back if needed. If you’re working on something similar for a larger team or organization, your dynamics will be different.
Even so, removing daily, trusted tools from a team comes with pushback. Some had valid reservations about what we’d lose along the way — watercooler chats, urgent coordination, the ability to DM, and more. The incongruence with our values, and analysis of the known negative side effects of the always-on culture was clear though, and we pledged to solve for the edge cases explicitly instead of letting those edge cases dictate our core working style.
As part of this process, we created plenty of supporting documentation about our communication principles and philosophies, in addition to practical guides outlining our intended workflows and toolsets.
We also made it clear that this was a type two, reversible decision — if the trade-offs were too high or we introduced too much friction, we could reassess and change course. We asked the team to weigh in with their feedback on a Notion page and started a meta channel in Threads to discuss effective use and share best practices as part of the transition.
In the end, this change largely worked for us. We were able to wean off of the firehose communication that had become standard for us in Slack and found workarounds and healthy alternatives for the use cases that Slack excelled out. We’re no slower in our ability to make important decisions or move projects forward, which is an argument that many have against leaving real-time messaging behind.
We’re still working on improving outlets for social watercooler connection and fast 1:1 communication, but are confident that those challenges can be solved without sacrificing our core culture.
4. Communicate
It’s important to acknowledge that strong and disciplined communication habits are not a shared core competency across the team. Everyone brings their own habits and preferences from past roles and companies, so picking and choosing what works and deprogramming the habits we don’t want to inherit is also part of the process. We make our approach clear through visible and proactive communication.
As part of our culture of documentation, we have memos in Notion outlining precisely how we use different tools, and what situations they should be used for. As part of our onboarding month, we direct new hires to all these resources and give them time to acquaint themselves with the tools they’ll need to collaborate with their team every day.
5. Iterate
Though we’ve made enough significant changes to focus our attention on other company-building efforts, this effort will never be complete. Our internal communication challenges and needs will change as our company grows, and we’ll return to this process to keep honing in and avoid slipping into a state of entropy.
Our current challenge is finding better norms for synchronous communication when it’s needed for truly urgent events like outages or debugging. We also haven’t nailed the casual, interest-based conversations that tend to play out organically in synchronous chat or DMs. We’ve returned to the start of this process to understand how our current approach might not align with our vision, and we’re not excluding any options from consideration.
Wrapping Up: Invest In Improving Your Internal Comms
When I share our changes and process with others, I’m often met with a range of reactions — from intrigue and interest to “that would never work for my team!”. In most cases, the person is generally frustrated with “work about work,” and the underlying cause is often the friction and tension that using sync communication tools in async work environments creates.
The appetite to spend energy and time on these fundamentals is usually low — but unaddressed, the stress that adds up across the team takes away from the ability for folks to stay energized and focused, and to create a work culture that executes well on a company’s priorities and mission.
If you want to dig deeper into the ways we and other companies are thinking about work communication differently, we recommend the following books and resources:
Books
- Deep Work by Cal Newport
- It Doesn’t Have to Be Crazy at Work by Jason Fried & David Heinemeier Hansson of Basecamp
- Out of Office by Charlie Warzel & Anne Helen Peterson
Podcasts
- “Principles of effective communication” with me and Levels CEO Sam Corcos on A Whole New Level
- “Stop. Breathe. We Can’t Keep Working Like This” with Cal Newport on The Ezra Klein Show
- “The New Future of Work” with Matt Mullenweg on Making Sense with Sam Harris
Resources
What Levels does—and why
Learn more from the Levels Team