Blog
Consider Ditching Slack
Slack has become a crutch more than a productivity tool, and many have lost sight of the goal of it. Let’s talk about why you should rip it out of your startup, and you may experience a healthy pain.
At Convictional (previous company), the founders had decided that Slack wasn’t the right tool for the culture they were building and didn’t default to adding it. It’s all too common to just default to adding Slack because there is a free tier and “that’s how people communicate for work”. Once it’s in your workflow, it’s hard to remove.
Let me explain why it should be:
- It can lead to performative behaviour, and you can lose your culture in it.
- It punishes your top performers, and amplifies your weak performers.
- It’s too convenient and skips critical steps.
Performative
Busy Work
The idea of “busy work” is doing activities, or tasks that provide the perception of work, but doesn’t actually move any meaningful needle. I’d argue this is most common in meeting heavy large corporations. What if you sent an email instead of the meeting? Would the same outcome be achieved? If the answer is yes, that’s probably busy work.
In startups, busy work happens in a few ways. It could be people who come from big corporations and bring the behaviour of “lots of talking about a problem” with them. Or, people who lean to decision by committee, compared to making a decision quickly and carrying out as an individual. Or finally, people who “work in Slack”.
In my experience founders are quick to catch onto the first two. They notice the output of the employee is incredibly low relative to customer value created, and they are often shown the door pretty quickly. If they aren’t, the startup is usually dead within 12 months. “A” players don’t want to work with these people, so usually congregate.
The third one is hard to see because they are quick to respond, are on multiple threads, and people don’t see the number of hours going in. Hours of useless meetings is obvious, but 5 minutes stack 50 times isn’t obvious. There’s often the performative behaviour belief that always online, and fast to respond means that they are good at their job. It’s hard to say, “Jim is always fast at responding, he isn’t doing his job.” Right there is were the error is made, you lose sight that your startup only exists to create customer value, and nothing else. You made the mistake of believing “fast to respond” means creates customer value. Even if I switched that sentence to be, “Jim is always fast at responding to customers”, it still misses the point. Great, he’s fast, but did he solve it for good? Did respond with the right answer? Why did the customer message in the first place? We begin to measure the wrong outcome.
The best way to avoid this is to put activities on a scale. On one side, “performative”, and on the other “performance”. For example, “respond quickly to other team members” is leaning more towards performative. If that didn’t happen, it isn’t a big deal. “solve customer problems for the last time” is performance. Remember, you’re asking what if this didn’t happen? If you didn’t respond to the customer quickly, could they find their answer else where? Solving it properly for the last time is more important than solving it quickly in the short term.
By removing Slack, it will mean you lean into other tools more such as Linear / Github Issues, email, Notion, etc. This will be a healthy improvement because a lot of these tools were built for the specific use case. Front is great example - yes, it has a discussion / live chat component to it, but it happens around a customer email thread. The same will be true with Linear (or other project management tools). Instead of low value direct messages to each other, you will maintain a healthy project board. Generally, you will get more intentional with each existing tool.
Culture
Hanging out in Slack - it doesn’t really add to your culture. We have “fun vibes” in Slack isn’t that meaningful. Yes, some camaraderie can be built, but you shouldn’t lose sight of it’s the equivalent of small talk. Making small talk is good, but to build real relationships, you need to have real discussions. Slack has nothing to do with those real discussions. It takes away because it’s a tool for fast response compared to long thoughtful thought.
Convictional had an async culture. Discussion happened in Github Issue threads. You weren’t aiming for a fast response. It would take effort to provide a thoughtful response to a teammates opinions. You had to write. You had to thoughtfully pick your arguments, facts and words. The fastest response didn’t win. There was enough friction with the path to responding, that you didn’t want to do it often and quickly.
The final thing I’ll add to the impact on culture is team members onboarding. People confuse easily available with thoughtful onboarding. Often startups, think new hires know what to be asking, or the specific terms to be searching for. New hires need to know what the next step is. Startups don’t spend the time investing in a proper experience because “they’ll just message on Slack”. You should consider the question, what if I couldn’t talk to them throughout the entire onboarding experience? Or there’s 24 hour delay in my responses? You would build a proper system and stop leaning on Slack as the crutch.
Top Performers
Slack (really always “online”) punishes your top performers because they are the simplest path to an answer. Your weak performers will choose the easiest path to answer - bad news for you, it’s the Slack message to the top performer. Ex. “Hey, you built it, (insert question instead of figuring it out)”.
Show me the incentive, I’ll show you the outcome - Charlie Munger
Slack has created a tool that removes barriers to slow responses. It has it’s perks, but also it’s downfalls. In my opinion, Slack creates a Manager schedule for everyone, and most startups need a “maker’s schedule”. Read PG’s essay about Maker vs Manager schedule.
”For someone on the maker's schedule, having a meeting is like throwing an exception. It doesn't merely cause you to switch from one task to another; it changes the mode in which you work.” - Paul Graham in Maker’s Schedule, Manager Schedule
Dumb questions happen with everyone, but you want there to be enough resistance that spending time finding the answer is possible. If the answer lives in the code and it takes 20 minutes to search, or you have to wait an hour for a response. The weak performer should do 20 minute path first. If they don’t, maybe you made the wrong hire. Adjusting the same example, if your top performer responds in 5 minutes - guess what path will be taken.
This problem really presents it’s self after a year or so. You’ve built your product, and top performers often have the most context. If they are strong, they will either let the code be the documentation, or they will write documentation. The problem is with every new feature or improvement, they receive 1 or 2 more questions per month if it’s not nipped in the butt. Eventually, all their time is going to answering questions that shouldn’t be asked in the first place.
In my own experience, you can try to give people permission to push back or ignore these questions, but it’s hard if you hire kind people. They want to be helpful, and not be an asshole. But it’s a fine line. As leader, it’s better to setup tools to create resistance like removing Slack direct messages.
“Have time for a quick Huddle?” is my least favourite message. It tells me that you are okay with interrupting my flow state. I encourage people to read Deep Work.
Documentation Missing
I’ve already touched on this one, so I won’t spend too much time on it. People mistake Slack threads for documentation. “We had the discussion and came to an outcome in Slack. It’s documented.” It’s not - as time passes, you would have to know the exact thing to search for to find it. All too often documentation is skipped because it’s written in Slack.
You could solve this by documenting the outcomes after the discussion in Slack. Or, just start with the documentation, and have a discussion around the final outcomes. Ex. Write the initial draft in Notion, and use the comment feature there. Re-write parts based on feedback. No Slack is involved.
Conclusion
It’s hard to see now, but I encourage you to think, if we removed Slack would it makes things worst. For most startups, it wouldn’t change much in terms of pros, but it would definitely remove some cons: busy work, lack of documentation, maker vs manager schedule.
Time is the finite resource and we are constantly fighting for more capacity. Slack optimizes for fast replies and low hanging fruit, but to move the needle for your customers, you need to be doing the long term actions. The real work happens outside of Slack.