There’s a pattern you notice after working with enough high-output engineering teams: the ones with the best throughput are rarely using the most sophisticated communication stack. Many of them still rely on mailing lists, IRC, or plain wikis. The instinct is to assume they haven’t gotten around to upgrading. The reality is they know something about how communication overhead actually works.
1. Asynchronous-by-Default Tools Force Better Writing
Email and mailing lists impose a friction that feels annoying at first: you can’t just dash off a half-formed thought and expect an immediate response. That friction is load-bearing. When you know a message is going to sit in someone’s inbox for hours before they see it, you write more completely. You include context. You ask one real question instead of five reflex questions.
The engineering teams at the Apache Software Foundation have coordinated some of the most complex open-source infrastructure on the planet largely through mailing lists. The Linux kernel development process, which involves hundreds of contributors across dozens of time zones, runs primarily on email. These aren’t teams that failed to discover Slack. They’re teams that made a deliberate architectural choice about communication latency. High latency forces high-bandwidth messages, and high-bandwidth messages mean fewer round trips.
Slack’s default mode is the opposite. The interface is optimized for short bursts. Reactions are one click. Threads are optional. The implicit contract is: respond quickly, keep it brief. That’s fine for coordinating lunch. It’s a tax on any problem that requires more than thirty seconds of thought.
2. Notification Architecture in Modern Tools Is Designed to Keep You Engaged, Not Focused
Slack’s business model depends on you spending time in Slack. The more you use it, the stickier it becomes for your team, and the harder it is to justify switching. This creates an incentive structure that is not aligned with your productivity. The notification defaults, the unread badges, the thread reply alerts, the channel activity indicators: all of these are design choices, and they were not made with your focus time in mind.
This isn’t a conspiracy theory. It’s the predictable output of a product team optimizing for engagement metrics. Tech companies design settings menus to nudge you toward choices that benefit them, and Slack’s notification settings are a clear example. The default state is maximum interruption. Turning it down requires deliberate effort, and most teams never fully do it.
Older tools like IRC (Internet Relay Chat) have no persistent notification state by default. You’re either in the channel or you’re not. Email clients, used correctly, are checked on a schedule you control. The absence of a live-presence indicator means no one expects an immediate response, which means no one is watching the channel for one. That changes the social contract around response time in a way that compounds into real focus hours across a team.
3. Plain Text Formats Create Searchable, Portable Knowledge
One of the underappreciated costs of a chat-heavy workflow is what happens to institutional knowledge. Decisions made in Slack threads are effectively buried. You can search for them, but the search is noisy, the context degrades quickly, and the thread format makes it hard to extract a clean record of what was decided and why.
Teams that default to email or internal wikis for anything decision-adjacent end up with a much better record. Email threads are imperfect but they’re linear and searchable. A mailing list archive is publicly linkable. A wiki page can be edited as understanding improves. None of this is glamorous, but it means the knowledge exists in a form that doesn’t require you to have been present in a specific chat window at a specific time to benefit from it.
Software teams that work in the open have understood this for decades. The discipline of writing things down in linkable, searchable form isn’t just good hygiene. It’s how distributed teams accumulate organizational memory rather than constantly rediscovering the same answers.
4. Low Ceremony Tools Have Lower Switching Costs and Therefore Less Lock-In
Slack workspaces accumulate integrations, custom workflows, bots, and automations over time. Each addition makes the workspace more useful and also harder to leave. The cost of switching grows with every bot you configure and every slash command your team relies on. This is not accidental. Network effects and integration depth are core to how SaaS tools achieve retention.
A team running on a mailing list and a shared wiki can migrate those artifacts in an afternoon. The format is open, the data is portable, and nothing requires a third-party API to keep working. This matters most when pricing changes, when an acquisition reshuffles a product roadmap, or when the tool simply stops being good. Beta versions are often better than final releases because the incentives flip at launch, and tools that grow complex over time often drift from what made them useful early on.
5. The Real Bottleneck Is Never Communication Speed
The framing behind most productivity tool marketing is that faster communication produces faster teams. This is almost never true in knowledge work. The bottleneck for a software team is almost always thinking time, not message latency. The code review that’s blocked isn’t blocked because feedback took four hours to arrive. It’s blocked because the reviewer needs an uninterrupted hour to read it properly.
Optimizing for faster responses to the wrong messages doesn’t move the real constraint. What does move it is protecting the time when actual thinking happens, which means fewer interruptions, not more responsive ones. Teams that understand this will deliberately introduce latency into communication channels to protect the resource that actually limits their output.
This is the insight that sits behind the “boring tool” pattern. It’s not nostalgia. It’s a correct diagnosis of where time actually goes, and a tool choice that follows from it. The teams using mailing lists and IRC aren’t behind. They built their communication stack around a model of how thinking works, and it turns out that model was right.
