The Setup
In early 2019, Metalab, the Victoria-based product design studio behind Slack’s original interface, was running into a problem that felt like a success story. The team had access to everything. Figma for design, Notion for docs, Asana for project management, Slack for communication, Loom for async video, Miro for whiteboarding, Abstract for version control, and dozens of supporting tools layered on top. Each one had been added for a legitimate reason. Each one solved a real problem. Together, they created a new problem no one had planned for.
Meetings started with five minutes of “which tool did you put that in?” Decisions were duplicated across platforms. New hires needed two weeks just to learn the workflow before they could contribute to the work. Senior designers were spending time that should have gone to clients on tool arbitrage instead.
The team wasn’t failing. They were delivering good work. But the overhead was real, and it was growing.
What Happened
The company didn’t announce a grand productivity initiative. What happened was quieter and more instructive. Individual project leads started making local decisions to consolidate. One team dropped Asana and moved task tracking into Notion because that’s where the project briefs already lived. Another stopped using Loom and went back to written async updates because the video recordings were taking longer to watch than to read. Slack channels got audited and cut by roughly half.
The consolidation wasn’t driven by a philosophy. It was driven by friction. Every tool that survived had to justify its presence by being irreplaceable. Tools that were nice to have, but redundant with something the team already used well, got cut.
By the time the dust settled, the active toolkit had dropped from the high forties to single digits. The core stack became Figma, Notion, Slack (with strict channel discipline), and a project management layer built directly inside Notion rather than handled by a separate app.
The reported outcome was faster onboarding, less context-switching mid-project, and more senior time available for client-facing work. The team didn’t get smarter or work longer hours. They just stopped paying the overhead tax on their own tool ecosystem.
Why This Keeps Happening
Metalab’s experience isn’t unusual. It follows a pattern that shows up across teams of different sizes and industries: productivity tool adoption follows an inverted U. Up to a point, each new tool genuinely helps. Past that point, every addition creates coordination costs that eat into the gains.
The mechanism is straightforward. Every app you use regularly requires a slice of your cognitive attention, not just when you’re using it, but when you’re deciding whether to use it. Psychologists call this decision fatigue. When your toolset is large enough that choosing the right tool for the right task requires deliberate thought, you’ve already lost something.
There’s also the context-switching cost. Research from Gloria Mark at UC Irvine has consistently found that interruptions, including the self-imposed kind that come from toggling between apps, take significantly longer to recover from than most people estimate. The cost isn’t just the minutes lost in the switch. It’s the degraded quality of focus in the work that follows.
Power users tend to underestimate both of these costs because they’re invisible in the moment. You don’t feel yourself losing 15 minutes to cognitive overhead. You feel yourself solving the immediate problem with the specialized tool you picked for it. The overhead is distributed across the whole day in ways that are genuinely hard to attribute.
This connects to something worth understanding about how multitasking trains your brain over time. The tool-switching problem isn’t just about lost minutes. It’s about what you’re conditioning yourself to expect from your own attention.
The Counterintuitive Part
The thing that trips people up is that more tools feel more capable, and they often are, in a narrow technical sense. A specialized project management app probably has better Gantt chart features than a Notion database. A dedicated time tracker probably captures more granular data than a simple spreadsheet.
But capability and productivity aren’t the same thing. A tool that does 80% of what you need and lives inside a system you already understand is usually more productive than a tool that does 100% of what you need and requires a context switch to access.
This is why the most productive teams use boring communication tools on purpose. Boring, in this context, means familiar and predictable. The cognitive load of using the tool drops to near zero, and that freed capacity goes back into the actual work.
The other thing that gets missed: constraints force clarity. When you can’t spin up a new Miro board for every brainstorm, you have to decide whether the brainstorm actually needs to be a brainstorm or whether it can be a short written brief. That decision, made consistently, tends to eliminate a lot of meetings and artifacts that weren’t serving the work in the first place.
What You Can Apply Right Now
You don’t need to run a company to use this. Here’s a practical way to audit your own toolkit.
Map what you actually use. Not what you pay for, not what you’ve installed. What you opened in the last two weeks. Most people find they’re actively using about a third of what they have access to.
Identify your overlap zones. Look for places where two tools serve the same basic function. Notes apps are a common culprit. Communication tools are another. If you’re maintaining context in more than one place, that’s a consolidation opportunity.
Ask the irreplaceability question. For each tool, ask: if this disappeared tomorrow, could I do 90% of what I do with it using something already in my stack? If yes, the tool is probably adding overhead without adding proportional value.
Set a default and stick to it. Pick your note-taking system. Pick your project tracking system. Pick your writing tool. The discipline isn’t about using the best tool for every situation. It’s about reducing the number of situations where you have to choose.
Give the reduced stack 30 days before you add anything back. The urge to re-add tools peaks in the first two weeks. Most of it passes.
The goal isn’t austerity. It’s reducing the tax you pay on your own systems so more of your energy reaches the work itself. Metalab didn’t become more productive by becoming less capable. They became more productive by making their capability easier to access.
You almost certainly have everything you need already. The question is how much of your day you’re spending managing the things you have instead of using them.
