We had seventeen tools. Seventeen.
Slack, Zoom, Notion, Linear, GitHub, Figma, Loom, Google Meet, Miro, Confluence, Jira, Discord, Tuple, Around, Tandem, Gather, and a custom internal wiki. Each tool had been added to solve a specific problem. Together, they created a new problem: nobody knew where anything was.
"Should this conversation happen in Slack or Discord?" "Is the spec in Notion or Confluence?" "Did we use Zoom or Google Meet for this meeting?" "Is there a Loom about this, or is it documented somewhere?" The cognitive overhead of remembering where things lived consumed more time than the tools saved.
The problem wasn't any individual tool—each was chosen for good reasons. The problem was the accumulation. Too many tools fragments information, creates confusion, and forces constant context-switching between interfaces. Remote work already has coordination overhead; unnecessary tool complexity compounds it.
At SmithSpektrum, I've seen engineering teams with tool stacks ranging from minimalist to overwhelming[^1]. The ones that work well share a pattern: deliberate choice about which tools serve which purposes, clear norms about tool usage, and willingness to consolidate when fragmentation appears.
The Core Functions
Before choosing tools, understand the functions you need to support.
Synchronous communication for real-time discussion: meetings, pair programming, urgent coordination. This needs to be reliable, low-latency, and high-quality enough that communication isn't frustrating.
Asynchronous communication for non-urgent messages, updates, and discussions that don't need immediate response. This needs to be organized enough that people can find relevant threads and context.
Documentation for knowledge that should persist: decisions, processes, architecture, onboarding. This needs to be discoverable and maintainable.
Project management for tracking work: what's happening, who's doing it, what's blocked, what's done. This needs to be the source of truth for project status.
Code collaboration for the actual engineering work: version control, code review, CI/CD. This is usually the most settled category since the industry has converged on Git-based workflows.
Design collaboration for visual work: mockups, prototypes, design systems. Relevant for teams with design functions.
| Function | Purpose | Key Requirements |
|---|---|---|
| Sync communication | Real-time discussion, meetings | Reliable audio/video, screen sharing |
| Async communication | Non-urgent messages, updates | Organized channels, threading, search |
| Documentation | Persistent knowledge | Discoverable, maintainable, versioned |
| Project management | Work tracking | Source of truth, visibility, integration |
| Code collaboration | Engineering workflow | Version control, review, CI/CD |
| Design collaboration | Visual work | Real-time collaboration, version history |
The Consolidation Principle
Fewer tools is almost always better—if the fewer tools cover the necessary functions adequately.
Tool consolidation reduces cognitive overhead. One less place to check, one less login to maintain, one less interface to learn. The value of having the "best" tool for a specific function is usually outweighed by the cost of having another tool to manage.
When evaluating a new tool, the bar should be: does this solve a problem that existing tools cannot solve, and is the problem important enough to justify adding complexity? Most tools people want to add solve problems that existing tools can solve well enough.
The exception is when a tool category is genuinely distinct and central to work. Code collaboration should probably not be crammed into your chat tool. Design work probably needs dedicated design tools. But within categories, consolidate aggressively.
Async Communication: The Central Nervous System
The async communication tool is typically the hub of remote collaboration. For most teams, this is Slack, Microsoft Teams, or Discord.
Channel organization matters. Too many channels fragments attention; too few creates noise. A reasonable pattern: team channels, project channels, functional channels (engineering, design, etc.), and social channels. Archive aggressively—channels that aren't used shouldn't exist.
Threading keeps conversations contained. The norm should be: respond in threads, not in the main channel, for anything beyond a one-line message. Main channels should be scannable; detail lives in threads.
Response time expectations should be explicit. Async means people don't need to respond immediately—but how long is acceptable? "Same business day" is a common norm. Make it explicit so nobody feels guilty about not responding instantly.
Notification management is essential. Default notifications are usually too aggressive. Help people configure notifications so urgent things get attention and everything else can wait for scheduled checking.
Synchronous Communication: When It's Needed
Video calls are the default sync tool, but different contexts have different needs.
Regular meetings (team syncs, 1:1s) need reliability above all. Zoom, Google Meet, and Microsoft Teams all work. Choose one and standardize—the switching cost of using multiple video platforms adds friction.
Pair programming and technical work benefits from specialized tools. Tuple, Pop, and similar tools are optimized for development collaboration: low latency, easy screen sharing and control, designed for extended sessions. Regular video calls can work but are less optimized.
Quick calls for fast clarification shouldn't require scheduling. Slack huddles, Discord voice, or equivalent—the ability to start a call instantly without calendar coordination enables faster resolution than async back-and-forth for certain problems.
| Sync Use Case | Recommended Approach | Why |
|---|---|---|
| Scheduled meetings | Standard video (Zoom/Meet) | Reliability, familiarity |
| Pair programming | Specialized tools (Tuple/Pop) | Low latency, developer features |
| Quick questions | Huddles/instant voice | No scheduling overhead |
| Large all-hands | Webinar-style tools | One-to-many broadcasting |
Documentation: The Organizational Memory
Documentation tools vary widely in philosophy. The right choice depends on your team's approach.
Structured wikis (Notion, Confluence, Outline) organize information hierarchically. Good for teams that want centralized, organized knowledge bases. The challenge is maintenance—structure that isn't maintained becomes misleading.
Lightweight docs (Google Docs, Dropbox Paper) are simpler—just documents. Good for teams that don't need heavy structure. The challenge is discoverability—finding things requires good naming and organization.
Documentation in code (Markdown in repos, inline docs) keeps technical documentation close to code. Good for purely technical documentation. The challenge is non-technical content and cross-project information.
Whatever you choose, the key is consistency. If some documentation is in Notion, some in Google Docs, and some in Confluence, nobody will find anything. Pick one primary system and use it.
Project Management: Tracking Work
Engineering project management has largely converged on a few models.
Linear has become popular for engineering teams: clean interface, keyboard-driven, built for engineers. Opinionated about workflow in ways that work well for many teams.
Jira is the enterprise standard: extremely flexible, integrates with everything, but complex. Can be configured into either a well-organized system or an overwhelming mess.
GitHub/GitLab Issues keep project management close to code. Good for teams that want minimal additional tooling. Less feature-rich for complex workflows.
Asana, Monday, etc. are more general-purpose project management tools. Work for engineering but aren't specifically designed for it.
The best choice depends on your complexity needs. Simpler projects can use simpler tools. Complex projects with many dependencies and stakeholders may need more powerful systems. Whatever you choose, it should be the single source of truth for "what's happening"—not duplicated across multiple systems.
Code Collaboration: The Engineering Core
This category is mostly settled.
GitHub is the dominant platform for code collaboration. Version control, code review, CI/CD, project management (through Issues/Projects). For most teams, GitHub handles most engineering collaboration needs.
GitLab offers similar functionality with a self-hosted option. Some organizations prefer it for control or specific features.
Bitbucket integrates with Atlassian ecosystem. Less common for startups but present in organizations using Jira/Confluence.
The choice often comes down to ecosystem and organizational preference rather than dramatic functional differences.
The Integration Layer
Tools that work together are more valuable than tools that don't.
Slack integrations from GitHub, Linear, and other tools surface information without leaving chat. Pull request updates, deployment notifications, task assignments—these appearing in context reduces the need to check multiple tools.
Automation tools (Zapier, Make, n8n) connect tools that don't integrate natively. If you need to sync information between systems, automation can reduce manual overhead.
Single sign-on reduces login friction. If you have many tools, SSO through an identity provider (Okta, Google Workspace, etc.) removes the tax of managing many credentials.
The Adoption Challenge
Tools only work if people actually use them consistently.
Clear norms are essential. Which tool for which purpose? Where does this type of information live? What are the expectations around response time? Documenting and communicating these norms prevents the fragmentation that comes from people making individual choices.
Migration support when introducing new tools. Don't just add a tool and expect people to figure it out. Provide training, answer questions, and actively support the transition. Old habits persist unless actively replaced.
Leadership modeling matters. If leaders use tools inconsistently, teams will too. If the executive team uses Slack while expecting engineers to use Teams, you have a problem.
Regular review of tool usage. Are people actually using the tools as intended? Are there tools nobody uses that should be removed? Are there gaps that need new tools? Periodic audit keeps the stack intentional.
The team with seventeen tools? They spent a month consolidating. Slack for async communication. Zoom for video meetings. Notion for documentation. Linear for project management. GitHub for code. Figma for design.
Six tools. Clear purposes. Documented norms for when to use each.
"We lost some specific functionality that individual tools had," the engineering manager admitted. "But we gained so much more in clarity. People stopped asking 'where should I put this?' because the answer was obvious."
The stack isn't about having the best individual tools. It's about having a coherent system where people know how to work, where information lives, and how to communicate.
References
[^1]: SmithSpektrum remote tooling advisory, 2021-2026. [^2]: Statista, "Workplace Collaboration Software Trends," 2025. [^3]: Okta, "Businesses at Work Report," 2025. [^4]: Slack, "State of Work Study," 2025.
Building your remote engineering stack? Contact SmithSpektrum for distributed team tooling strategy.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum