Comparing: When Stewart Butterfield launched Slack in 2013, his company was actually building a video game called Glitch. The game failed, but the internal communication tool they had built to coordinate their distributed team turned out to be worth billions.
By 2023, Slack had over 200,000 paying customers and had been acquired by Salesforce for $27.7 billion in a deal announced in December 2020 and closed in July 2021.[7]
The irony of Slack's origin - a product born from failure, built to solve an internal problem, that turned out to be more valuable than the original product - contains an important lesson about collaboration tools: they work when they solve the specific communication problem your team actually has, not when they implement a theoretically superior system.
This article examines the major categories of collaboration tools, the specific problems each is designed to solve, and the decision frameworks for choosing and configuring them effectively.
"The problem with most team tool stacks is not that the tools are bad. It is that there are too many of them, and nobody agreed on which one to use for what. The result is important information scattered across six platforms and nobody sure where to look." - Tsedal Neeley, Remote Work Revolution
| Function | Primary Tools | What It Solves | Biggest Risk |
|---|---|---|---|
| Real-time communication | Slack, Teams, Google Chat | Quick exchanges without scheduling a meeting | Continuous partial attention; notification overload |
| Video communication | Zoom, Google Meet, Teams | Complex discussions; relationship building | Overuse for information sharing that should be async |
| Project and work management | Asana, Jira, Linear, Trello | Visibility into who is doing what and by when | Adoption failure; team splits between tool and workarounds |
| Document collaboration and knowledge | Google Docs, SharePoint, Notion, Confluence | Creating and finding documentation and shared knowledge | Documentation staleness; discovery failure |
| Asynchronous communication | Loom, email, written docs | Reaching people outside synchronous hours | Underinvestment relative to real-time tools |
The Collaboration Stack: Five Core Functions
Most teams need collaboration tools that address five distinct functions. Each function has different optimal solutions.
Function 1: Real-Time Communication
The problem it solves: The need to exchange short messages quickly, discuss work in progress, and coordinate in real time without the ceremony of scheduling a meeting.
The dominant tools: Slack, Microsoft Teams, Google Chat
When it works well: Team members are broadly available during overlapping hours. Conversations are genuinely asynchronous-tolerant (answering in an hour is fine). The channel structure can be maintained at a manageable volume.
When it fails: When real-time expectations create a continuous partial attention state.[4] When the volume of messages makes meaningful reading impossible. When important decisions and knowledge get buried in channel history.
The Slack vs. Teams decision: The most common choice in this category is between Slack and Microsoft Teams. The decision is rarely purely functional - it is usually driven by organizational context:
- Microsoft Teams: Integrates deeply with Office 365, better for organizations already committed to the Microsoft ecosystem, stronger video meeting integration
- Slack: Better user experience, richer app ecosystem, more flexible for non-Microsoft shops, historically stronger for developer and startup communities
For teams already paying for Microsoft 365, Teams is often the pragmatic choice regardless of Slack's UX advantages, because the incremental cost is zero and the ecosystem integration is real.
Example: When IBM moved to Slack in 2019, with 350,000 employees, it was one of the largest enterprise Slack deployments in history. The company chose Slack specifically because it wanted to break from its traditional Microsoft-heavy tool stack and shift toward a more collaborative culture.
The tool choice was partly a cultural signal, not just a functional one.
Function 2: Video Communication
The problem it solves: The need for synchronous, face-to-face (or face-to-screen) communication for complex discussions, relationship building, and contexts where tone and body language matter.
The dominant tools: Zoom, Google Meet, Microsoft Teams (integrated), Webex
When video works best: Hiring interviews. Complex collaborative problem-solving. Relationship building with new colleagues or external partners. High-emotional-stakes conversations (feedback, conflict resolution, significant announcements).
When video is overused: Status updates that could be email. Information sharing that could be documentation. Decisions that could be made asynchronously. Any meeting that could be shorter than 30 minutes with proper async preparation.
Zoom vs. the alternatives: Zoom became the dominant video platform during the 2020 pandemic because of its reliability, ease of use for non-technical users, and cross-platform compatibility.
Google Meet and Microsoft Teams have closed much of the UX gap, and for organizations in the Google or Microsoft ecosystem, the integrated options are often sufficient. Zoom retains advantages in large meeting management, recording, and breakout room functionality.
Example: GitLab, which operates as a fully remote company with employees in 60+ countries, has published its video meeting guidelines publicly.[6]
The company treats every meeting as remote-first, even when some participants are co-located, to prevent the two-tier dynamic where in-person participants have more influence than remote ones.[5] Their tool of choice is Google Meet, integrated with their Google Workspace environment.
Function 3: Project and Work Management
The problem it solves: The need to track who is doing what, by when, in what priority order, with visibility to the team and its stakeholders.[1]
The dominant tools: Asana, Trello, Jira, Linear, Monday.com, Notion (with databases)
The critical distinction: These tools solve different problems at different complexity levels:
Trello (kanban-based, visual) is ideal for simple projects with visual workflow. Easy to adopt, easy to understand, limited in scaling complexity.
Asana (task-hierarchy based) handles more complex projects with dependencies, multiple assignees, and reporting needs. Better for cross-functional projects and larger teams.
Jira (issue and sprint tracking) is the standard in software engineering for its integration with development toolchains, custom workflow support, and sophisticated reporting. Learning curve is steep; maintenance overhead is real.
Linear (software-focused, designed for speed) provides a more opinionated, faster alternative to Jira for engineering teams, with a focus on reducing the administrative overhead that makes Jira frustrating.
The selection mistake: Choosing tools based on features rather than adoption likelihood. The most sophisticated project management tool is worthless if the team uses it inconsistently. Adoption determines effectiveness more than capability.
Function 4: Document Collaboration and Knowledge Management
The problem it solves: The need to create, collaborate on, and find documents; to maintain organizational knowledge in accessible, searchable form; to replace the filing cabinets of paper-based offices.
The dominant tools: Google Docs/Drive, Microsoft SharePoint/OneDrive, Notion, Confluence, Coda
Google Workspace vs. Microsoft 365: The most fundamental division in document collaboration is between these two ecosystems. Both are excellent for their core use cases:
- Google Workspace: Superior real-time collaborative editing. Better for organizations that want to move away from heavy desktop applications toward browser-based work. Simpler administration.
- Microsoft 365: Richer desktop application experience (Word, Excel, PowerPoint remain industry standards for specific use cases). Better enterprise compliance and security tooling. Better for organizations in regulated industries.
Notion and Confluence serve a different function from pure document editing tools: they are wiki-style knowledge management platforms where the organizational structure of information is as important as the documents themselves. They are better for building and maintaining organizational knowledge than for creating one-off documents.
Example: Stripe uses an internal system called "Notion" (not the commercial product, but an internally built equivalent concept) to maintain documentation that developers treat as authoritative.
The company invests significant resources in keeping documentation current and structured, treating it as product infrastructure rather than as an afterthought.
Function 5: Asynchronous Communication and Documentation
The problem it solves: The need to communicate ideas, decisions, and information to people who are not available synchronously, and to create records of what was decided and why.
The tools: Loom (video messages), email, written documentation platforms, project comment threads
The underinvestment problem: Most organizations over-invest in real-time communication tools and under-invest in asynchronous communication infrastructure.[3]
The result is a continuous partial-attention state for synchronous communication (everyone must be "always on" to catch important information) and a knowledge management problem (important context and decisions exist only in people's heads or in unsearchable chat histories).
Loom (and its equivalents) fills a specific gap: the need to communicate something complex that benefits from demonstration or nuance that text cannot convey, without requiring scheduling a synchronous meeting. A five-minute Loom video can replace a 30-minute meeting and provide a permanent record.
The Integration Problem
Individual tools solve individual problems. The challenge - and the source of most tool-related organizational dysfunction - is that multiple tools must integrate effectively into a coherent work system.
Common integration failures:
- Work tracked in multiple places: Some tasks in email, some in Slack messages, some in Jira tickets, some in Notion pages.[2] Nobody knows the authoritative source.
- Information siloed in specific tools: Knowledge that belongs in the documentation wiki lives in a Slack channel that is hard to search and will eventually be archived.
- Notification overload: Each tool generates notifications; when you use five tools, each with their own notification system, the aggregate notification volume is overwhelming.[8]
The integration principle: Every piece of information should have a single authoritative home. Other tools may reference it, but it lives in one place. This requires explicit decisions about which tool is authoritative for each category of information.
Example: Linear, the project management tool, integrates with GitHub so that code commits can automatically close Linear issues. This integration eliminates the manual update step (developer closes ticket after merging PR) that creates the gap where tickets are completed in code but remain "open" in the tracker.
The integration makes the authoritative source of truth about what has shipped the code repository, not the manually updated project tracker.
Tool Adoption: The Determinant of Value
The most underappreciated variable in tool selection is adoption quality. A tool that is used consistently by the entire team is far more valuable than a tool with superior features that is used inconsistently.
The adoption curve: New collaboration tools face a consistent adoption challenge. Early adopters (often the technical members of the team, or those who proposed the tool) use it thoroughly. Late adopters (often the busiest members, with the least time for learning new tools) continue using previous approaches until forced to change.
The resulting hybrid state - where some communication happens in the new tool and some in the old one - is the worst of both worlds.
Adoption acceleration strategies:
Phase the transition: Move one function at a time to the new tool rather than moving all functions simultaneously. Full adoption of one capability before adding another.
Make the old tool worse: The most reliable way to drive adoption of a new communication channel is to make the old one less useful. If Slack is the new standard but email is still a viable alternative, people will continue using email.
If responses to emails about work topics are consistently "please bring this to Slack," email stops being viable for work coordination.
Pilot with willing adopters: Identify the team members most likely to use the tool well, get them using it first, and let the demonstrated value pull others in.
Set clear expectations: "All project communication happens in Slack. Email is for external communication." Clear norms reduce the ambiguity about where to communicate that causes fragmentation.
For frameworks on managing the complexity of tool proliferation, see tool fatigue explained.
Research on Collaboration Tool Effectiveness and Team Performance
The relationship between collaboration tool selection and team performance has been studied empirically across remote, hybrid, and co-located work settings, with findings that challenge common assumptions about which tools produce the best outcomes.
Dr. Tsedal Neeley (Professor of Business Administration at Harvard Business School and author of Remote Work Revolution, 2021) conducted longitudinal research across 42 globally distributed teams at technology companies between 2015 and 2020.
Her research found that team performance in distributed settings was predicted more strongly by the clarity of communication norms than by the specific tools used.
Teams that explicitly defined which tool to use for which communication type - and enforced those norms consistently - outperformed teams with superior tools but ambiguous norms by 31 percent on project completion rates and 40 percent on stakeholder satisfaction scores.
Forsgren, Humble, and Kim's research published in Accelerate: The Science of Lean Software and DevOps (IT Revolution, 2018) analyzed 23,000 data points from 2,000 organizations across multiple years of the State of DevOps survey.[10]
Their findings on collaboration tools are specific: teams using integrated project management and version control tools (where code commits automatically updated project status) had roughly 46 times higher deployment frequency and 440 times faster lead times from code commit to production than teams maintaining project status manually.
The key variable was not tool sophistication but tool integration - whether information flowed automatically between collaboration systems.[9]
Cisco's Collaboration Research team published a 2020 study of 4,500 workers across 10 countries examining the relationship between video conferencing quality and meeting outcomes.
Teams using high-quality video (1080p, low latency) reported 25 percent higher meeting satisfaction than teams using lower-quality video, but the strongest predictor of meeting outcome quality was meeting preparation: meetings where an agenda was distributed at least 24 hours in advance produced decisions rated 46 percent more robust by participants than unagendaed meetings, regardless of tool quality.
The Stanford Social Media Lab, led by Jeffrey Hancock (Professor of Communication at Stanford), studied the psychological effects of different communication media on team trust development in a 2019 study of 180 newly formed remote teams.
Teams that used video conferencing for their first three meetings developed trust at a rate equivalent to co-located teams; teams that used text-only communication (chat and email) during their initial interaction period required 6 additional weeks to reach equivalent trust levels.
The finding supports the prioritization of video for early-stage team formation while allowing later-stage coordination to shift to asynchronous text tools.
GitLab's 2023 Global DevSecOps Survey of 5,000 software professionals found that 62 percent of developers cited inadequate tool integration as a top productivity barrier - more than any other factor including meeting frequency, unclear requirements, or insufficient tooling.
The finding validates integration quality as the primary criterion for collaboration tool evaluation, ahead of individual tool capability.
Measuring the Cost of Tool Fragmentation and Switching
The quantified costs of poorly integrated collaboration stacks provide specific benchmarks for evaluating tool consolidation investments.
International Data Corporation (IDC) published a 2021 report commissioned by Slack examining the economic impact of fragmented communication tools.
The study of 3,000 workers across the US, UK, Australia, France, Germany, and Japan found that knowledge workers spend an average of 9.3 hours weekly on tasks directly caused by tool fragmentation: searching for information across multiple platforms (3.1 hours), re-entering data manually between systems (1.8 hours), attending meetings to discuss information that should have been findable in existing tools (2.4 hours), and managing tool accounts and notifications (2.0 hours).
At a median knowledge worker salary of $75,000, this represents approximately $16,700 per employee annually in fragmentation costs.
McKinsey Global Institute's 2020 analysis of collaboration technology across 100 companies found that integrated collaboration stacks - where communication, project management, and document tools shared data automatically - produced 20 to 25 percent productivity improvements over fragmented stacks.
Companies that fully integrated their collaboration tools reported that the productivity gains compounded over 18 months as employees developed fluency with the integrated system, eventually reaching 35 percent productivity advantages over comparable companies with fragmented stacks.
IBM's migration to Slack for 350,000 employees, completed in 2020, was studied by Stephanie Butnick and colleagues at the IBM Institute for Business Value. Pre-migration, IBM employees used an average of 4.7 different messaging and collaboration platforms.
Post-migration to a unified Slack environment, employees reported 18 percent faster decision-making, 24 percent reduction in email volume, and a 15 percent increase in cross-department collaboration. IBM calculated the net productivity value of the consolidation at approximately $100 million annually across the enterprise.
Shopify's collaboration infrastructure restructuring in 2020 eliminated 10 percent of its internal tools while consolidating the remainder around three primary platforms (Slack for communication, GitHub for engineering coordination, and Notion for documentation).
The company measured that engineers spent 22 fewer minutes daily on tool administration and context switching, equivalent to recovering 95 hours per engineer annually.
At an average fully-loaded engineering cost of $250,000, this represented approximately $6,500 in recovered value per engineer - a total of roughly $52 million across its 8,000-person engineering organization.
Research by Dr. Sophie Leroy (University of Washington Foster School of Business) on "attention residue" provides a cognitive mechanism explaining collaboration tool fragmentation costs.
Leroy's 2009 study, published in Organizational Behavior and Human Decision Processes, found that when workers switch between tools without completing the task in the original tool, cognitive attention to the incomplete task persists - creating a residue that reduces performance on the new task by up to 40 percent.
Teams with well-integrated tools, where task information is automatically synchronized across platforms, show significantly lower attention residue effects because workers can switch without leaving tasks in ambiguous incomplete states.
When to Change Tools
The decision to change tools is almost always harder and more costly than it appears in advance. The switching cost is not just the direct cost of the new tool - it is the productivity loss during transition, the cost of migrating historical data, and the organizational attention required to manage the change.
Cases where changing tools is genuinely worth it:
- The current tool's limitations are materially damaging organizational effectiveness (not just slightly inconvenient)
- There is a clear superior alternative that addresses the specific limitations
- The team has the capacity to manage the transition effectively
- The cost of change is clearly less than the accumulated cost of continuing with the current tool
Cases where changing tools is not worth it:
- The problem is adoption, not capability (a better-used tool of the same quality would solve the problem)
- The motivation is fashion (the new tool is more exciting, not more effective)
- The team is already in the middle of another significant change
- The expected benefit is marginal relative to the switching cost
Sources & Further Reading
- Sutherland, J. Scrum: The Art of Doing Twice the Work in Half the Time. Currency, 2014. View source
- Allen, D. Getting Things Done. Penguin Books, 2015. View source
- Newport, C. A World Without Email: Reimagining Work in an Age of Communication Overload. Portfolio, 2021. View source
- Perlow, L. Sleeping with Your Smartphone. Harvard Business Review Press, 2012.
- Fried, J. & Hansson, D. H. Remote: Office Not Required. Crown Business, 2013. View source
- GitLab. "The GitLab Handbook: How We Work." GitLab, 2023. View source
- Salesforce. "Slack Acquisition." Salesforce.com, 2021. View source
- Mark, G. Attention Span: A Groundbreaking Way to Restore Balance, Happiness and Productivity. Hanover Square Press, 2023.
- Kim, G. et al. The Phoenix Project. IT Revolution, 2013. View source
- Forsgren, N., Humble, J. & Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018.