team
A team of fifteen usually has more collaboration tools than it has managers. Chat in one place, tasks in a second, documents in a third, files in a fourth, a whiteboard someone signed up for during a workshop, and a note taking app that two people use and nobody else has opened. None of it was a bad decision at the time. Each tool solved a real problem on the day it arrived.
The cost shows up later, in a form that is easy to feel and hard to name. Somebody asks where the latest version of the spec is and gets three different answers. A decision made in a chat thread is invisible to the person who needs it in two weeks. New people take a month to learn which surface matters for what. The stack grew by addition and nothing was ever removed, which is the normal outcome and the one worth doing something about.
Every list of collaboration tools mixes four different jobs together, which is why the lists are long and unhelpful. Separating them first makes the shopping decision much smaller.
The first job is conversation, meaning the fast, disposable back and forth that replaced walking to someone's desk. It is judged on speed and on how few people have to be interrupted. The second is work state, meaning the answer to what is in progress, who has it, and when it is due. It is judged on whether the answer is true without anyone being asked. The third is reference, meaning the documents and decisions that need to still be correct in three months. It is judged on retrieval, not on writing. The fourth is artifacts, the files, designs and recordings that the work produces.
Nearly every tool on the market claims at least three of these. Chat apps added lists and canvases. Document tools added databases and kanban boards. Task tools added comment threads and rich documents. The claims are usually real, in the sense that the feature exists, and usually weak, in the sense that nobody would have bought the tool for that feature alone.
This is where most stacks go wrong. A team adopts a chat tool for conversation, then starts tracking work in it because the feature is there, and ends up with work state scattered across channels where it cannot be counted. The same happens in reverse when a documents tool becomes the task tracker. The feature working is not the same as the job being covered.
Tools accumulate for structural reasons rather than through carelessness, and the reasons are worth naming because each one has a different remedy.
The first is that free tiers make trial costless and consolidation expensive. Anybody can sign up for one more product without a purchase order. Removing one requires finding everything inside it and moving it, which is real work with no visible reward. So the stack ratchets in one direction.
The second is that limits arrive individually. Slack's free plan keeps 90 days of message history and allows up to 10 app integrations, which is generous until the day someone needs a thread from four months ago. Notion's free plan caps file uploads at 5 MB each and page history at 7 days. Trello's free plan covers up to 10 collaborators and up to 10 boards per Workspace. None of these is unreasonable. What happens in practice is that a team hits one limit, does not want to pay for that product, and adopts a different free product alongside it. Two months later it hits a limit there too.
The third reason is the one nobody writes down. Adding a tool is a way to avoid a process decision. A team that cannot agree on where decisions get recorded will happily adopt a tool that promises to record decisions, and will then not use it, because the disagreement was never about software. A tool cannot settle a question the team has not answered out loud.
Once the four jobs are separated, the duplication becomes countable. The exercise takes about twenty minutes and it is usually uncomfortable.
| Job | Common primary tool | Also present in | What the duplication costs |
|---|---|---|---|
| Conversation | Chat app | Task tool comments, doc comments, email | Threads about the same work in three places |
| Work state | Task or project tool | Chat lists, spreadsheet, doc database | No single count of what is in flight |
| Reference | Wiki or doc tool | Chat pins, task descriptions, shared drive | Nobody trusts any version |
| Artifacts | Cloud drive | Chat uploads, task attachments, design tool | Files found by asking rather than searching |
| Schedule | Calendar | Task due dates, Gantt or timeline view, chat reminders | Two dates for one deadline |
The row that does the most damage is conversation, because chat is where discussion naturally happens and chat is the worst of the surfaces at retaining anything. A decision reached in a channel exists until the scroll buries it. The same decision written as a comment on the work item it concerns is found later by the same search that finds the work.
The row that costs the most money is schedule, since timeline and calendar views are frequently the feature that sits behind a higher plan. On Trello, Calendar and Timeline views arrive on Premium at ten dollars per user per month billed annually. On Asana, the free Personal plan covers two users with list, board and calendar views, and Timeline and Gantt views begin on Starter. Both are defensible product decisions. They matter here because a team that needs a timeline will often buy a second product rather than upgrade the first, and then owns two overlapping tools instead of one complete one. A stack where kanban, Gantt, calendar and timetable boards are all present from the free plan removes that specific fork in the road, and the comparison pages set out how several of these products differ on exactly this point.
The defensible minimum is three tools, sometimes two, and the shape is consistent across small teams.
One tool for conversation. One tool that holds work state and the discussion attached to each piece of work, because separating those two is the source of most lost context. One place for reference documents and files, which for many teams is already the cloud drive they pay for through their email provider.
What falls out of that list is worth stating plainly. A separate whiteboard tool is worth its cost only if the team runs regular structured workshops, and for most teams it was bought for one offsite and never reopened. A separate note taking app for meetings duplicates reference material unless the notes end up attached to the work they concern. A dedicated time tracking tool is necessary when invoicing depends on it and unnecessary otherwise.
The test for any candidate is narrow: name the job it covers, then name what gets deleted. If nothing gets deleted, the tool is an addition to the stack rather than a replacement in it, and additions are what created the problem. This test is uncomfortable because it disqualifies most purchases, which is the point.
For teams that are going to keep chat separate, which is the common and reasonable choice, the remaining question is whether the work tool can hold the discussion about each item. That is the seam where context leaks. A comment thread on the card, read by the next person who opens it, is worth more than a tidier chat archive.
Per seat pricing makes small numbers look harmless and the arithmetic is worth doing once. Five tools at an average of nine dollars per user per month, across fifteen people, is 675 dollars a month and 8,100 dollars a year. That figure is usually larger than anyone in the room expects, and it is not the main cost.
The main cost is attention. Each additional surface is a place that has to be checked, a set of notifications to tune, and a thing to teach every new hire. A stack of six tools means a new person spends their first fortnight learning where to look rather than doing the work they were hired for. That cost does not appear on an invoice, which is precisely why it grows unchecked.
Two things are worth checking on any plan before consolidating, because they change the arithmetic. The first is how guests and viewers are counted, since a team that works with contractors and clients can pay for a dozen seats that only read. The second is what the storage limit is and how it is measured, because file heavy teams hit that before they hit a seat limit. Both are on the pricing page of any product worth considering, and both are worth reading before a migration rather than after.
Consolidation stalls on the fear of losing history, and the fear is legitimate. The way through it is to accept that not all history has to move.
Work in progress has to move, and it is the smallest category. Active items in a task tool are rarely more than a couple of hundred, and several products import directly from each other, which removes most of the manual effort. An import path from Trello is one example of the kind of thing worth checking before choosing.
Closed history usually does not have to move. A tool kept in read only mode for a quarter, with nobody creating anything new in it, lets people look things up while the habit shifts. Most teams find the lookups stop within weeks. Reference documents are the category where an honest cut pays off, because a wiki with two hundred pages almost certainly has twenty that anyone reads, and moving the twenty is a morning's work while moving the two hundred is a project that never finishes.
The sequence that works is to move one team or one project first, run it for two weeks, and only then decide. Running two tools in parallel across the whole company is how migrations become permanent.
One detail is worth settling before the move rather than during it: who is allowed to create a new board, space or channel in the destination. A tool with no answer to that question reproduces the original sprawl inside itself within a few months, and the second sprawl is harder to see because it all sits under one logo. Naming one or two people who create the containers, and letting everyone else create items inside them, costs nothing and holds for years. The same applies to naming. A short written convention for what a board is named and what a channel is named prevents the situation where three people create three places for the same project in the same week.
Write down the four jobs, then list which tool each person actually opens for each one. The duplicates on that page are the decision, and the first thing to cut is whichever tool nobody could name a job for. Teams considering whether one board can hold work state and the conversation about it can look at how Pinateca is arranged or check the comparison against the tool currently in use.
Three is a reasonable target: one for conversation, one that holds work state together with the discussion about each item, and one place for reference documents and files. Teams that already pay for a cloud drive through their email provider often need only two more. The number matters less than whether every tool has a job nobody else is doing.
Usually not, and it is the hardest one to move because habit is strongest there. The higher return is in making sure work state and its discussion sit in the same place, so that chat can stay disposable. Replacing chat is a large change for a small gain.
Two real ones. A single tool that covers four jobs will be weaker at one of them than a dedicated product, so it is worth knowing in advance which job matters least. The other is lock in, which is addressed by checking what the export format is before migrating rather than after.
Ask each person which surface they open first in the morning and which they opened last week. Tools that appear in nobody's answer are candidates for removal regardless of what the admin console reports, because a licence with occasional logins is still paid attention nobody is giving.