The Stack That Grew Without a Plan
Most teams’ collaboration tool stacks evolved reactively: someone added Slack because it was better than email for quick questions, someone else added Notion because they needed a shared wiki, and Microsoft Teams came along as part of a 365 subscription that the organisation already had. Now three tools partially overlap in function, people use different tools for similar things, and context is scattered across platforms in ways that make finding anything a three-app search.
The collaboration tool rationalisation problem is genuinely common and genuinely costly: the average knowledge worker switches between apps 25+ times per day according to some productivity research, and tool context-switching is among the most commonly cited productivity obstacles in remote work surveys. The answer isn’t necessarily fewer tools — it’s more intentional tool selection where each tool has a clear, unique function in the stack.
Slack: What It Does Best and What It Doesn’t
Slack’s strength is real-time team messaging organised by channels — it replaced email for quick coordination within teams at companies that adopted it, creating persistent, searchable conversation threads accessible to anyone in the channel. Its emoji reactions, thread replies, and app integrations (connecting to GitHub, Jira, Google Drive, and hundreds of other tools to surface relevant events in Slack channels) made it the default team communication layer for technology-forward companies.
What Slack doesn’t do well: structured documentation and reference content. The Slack conversation where an important decision was made three months ago is theoretically searchable but practically difficult to find. Slack’s messaging format doesn’t support the structured document format that reference material needs. Using Slack for knowledge management — keeping important reference information in channel messages rather than in a document — creates the context-scattered problem rather than solving it.
Microsoft Teams: The Integrated Suite Approach
Teams’ strength is integration with Microsoft 365: documents, files, calendar, and the full Office suite are integrated into the Teams interface in ways that reduce context-switching for organisations fully embedded in Microsoft’s ecosystem. A Teams meeting can have a shared OneNote open simultaneously; a channel can surface relevant SharePoint documents; a Teams call can launch directly from an Outlook calendar entry. For Microsoft-centric organisations, this integration reduces the cross-app friction that standalone tools create.
Teams’ weakness relative to Slack is user experience: its interface is more complex, it’s slower to navigate, and its chat experience is more formal and less conversational than Slack’s. Teams also conflates its messaging, meeting, and document functions in a single interface that can be confusing for the specific task the user is trying to accomplish. Organisations that chose Teams primarily for included cost (it comes with 365) rather than for its communication quality often find their teams gravitating toward less structured communication channels for quick coordination.
Notion: Structured Knowledge Without Communication
Notion’s role in a collaboration stack is documentation and structured knowledge management — things that don’t belong in a chat channel or a document that’s shared one-off. Project wikis, team handbooks, process documentation, meeting notes that need to be referenced later, and structured databases of resources are all appropriate Notion content that Slack and Teams don’t serve well.
Notion’s weakness is real-time communication — it has commenting and mentions but isn’t a messaging tool. Trying to use Notion for quick team coordination creates the same mismatch as using Slack for documentation: you’re asking a tool to do something it wasn’t designed for. The clear functional division: Notion (or Confluence) for structured reference content; Slack or Teams for real-time and async messaging. These two functions don’t overlap well in any single tool.
Building a Stack Without Overlap
The collaboration stack design principle: define a specific primary function for each tool and document it explicitly so the team knows where each type of content belongs. Slack for real-time team messaging and quick questions; Notion for structured documentation and reference; Google Meet or Zoom for video calls; GitHub or Linear for engineering work tracking. When each tool has a clear mandate, the ‘where do I put this’ decision becomes answerable rather than arbitrary.
The consolidation temptation — replacing all of the above with a single all-in-one tool — typically produces one tool that does everything moderately well and nothing excellently. The team that consolidates on Notion for everything loses the conversational quality of Slack; the team that consolidates on Teams for everything loses the documentation quality of Notion. Deliberate tool selection with clear functional boundaries produces better team experience than forced consolidation.