Latest / The Productivity Podcast with Fexingo: Output, Efficiency, and Long-Term Economic Growth / Why Most Productivity Tools Actually Reduce Output
Transcript
- Lucas: So let me start with a number that stopped me cold this week: the average knowledge worker now toggles between eleven different software applications per hour. That's from a 2025 study by the MIT Digital Economy Lab. Luna: Eleven per hour? That's basically every five and a half minutes you're switching contexts. Lucas: Exactly. And the study found that each switch costs about twenty-three seconds to mentally reorient. Doesn't sound like much until you do the math — that's over four hours per week, per person, just in the friction of moving between tools. Luna: And that's before they've even done any actual work in any of those tools. Lucas: Right. Which brings me to the real paradox: most productivity tools are sold on the promise of saving time. But collectively, they may be burning more time than they save. I want to look at a concrete case today — a mid-sized manufacturing firm in Ohio that adopted fourteen new SaaS tools over two years. Luna: Fourteen tools. That feels like a lot for a mid-sized company. What were they trying to solve? Lucas: Each tool addressed a specific pain point. A project management tool to replace email threads. A communication tool to reduce meetings. A time-tracking tool to improve billing accuracy. A CRM to centralize customer data. A document collaboration platform. An expense reporting tool. Individually, each had a decent ROI case. But what the company didn't model was the interaction effects. Luna: The hidden cost of having to remember which tool to use for which task. Lucas: Exactly. The MIT study calls this 'tool overhead' — the cognitive load of maintaining mental maps of what lives where. The Ohio manufacturer ended up with a situation where the average employee was spending roughly forty-two minutes per day just navigating between tools. That's context-switching time, log-in time, time spent searching for that one report in the wrong system. Luna: So if a tool promises to save thirty minutes a day but costs forty-two minutes in switching, you're net negative twelve minutes per person per day. Lucas: That's the equation I want listeners to sit with. For a five-hundred-person company, that's a hundred hours of lost productivity every single day. Over a year, that's over twenty-five thousand hours. At a fully loaded cost of maybe sixty dollars an hour, that's one point five million dollars in lost output annually — from tools that were supposed to boost efficiency. Luna: And that's just the direct time cost. It doesn't include the subscription fees for those fourteen tools. Lucas: No, it doesn't. The company was spending about four hundred thousand dollars a year on SaaS subscriptions alone. So they were paying four hundred K for the privilege of losing one point five million in productivity. The CFO eventually ran the numbers and started a tool rationalization project. Luna: I've heard this called 'tool debt' — like technical debt, but for the proliferation of software that becomes harder to unwind the longer it accumulates. Lucas: That's a great framing. And tool debt has a compounding effect. Every new tool adds marginally more to the switching burden, but the benefit of each new tool is usually fixed or diminishing. So the marginal benefit curve slopes down while the marginal cost curve slopes up. At some point, adding tools actually destroys value. Luna: If today's conversation is making you think about your own tool stack — whether it's actually helping or just adding friction — that's exactly the kind of practical insight we try to bring each week. The way we keep this show ad-free and focused on that kind of content is listener support. If you found this useful, you can buy us a coffee at buy me a coffee dot com slash fexingo. Lucas: Yeah, that's genuinely what keeps us going. No ads, no sponsors, just a straight conversation about what works. So back to the Ohio manufacturer — they cut from fourteen tools down to six core platforms. What happened? Luna: I'm guessing productivity went up. Lucas: Significantly. They measured a twelve percent increase in output per employee over the following six months. The time saved from reduced context-switching more than made up for the loss of any niche functionality from the tools they cut. Employees reported feeling less frustrated and more focused. Luna: So the lesson isn't 'don't buy tools.' It's 'model the full cost, including the interaction effects.' Lucas: Exactly. And I think there's a broader economic point here. We've been in a productivity slowdown since the mid-2000s, despite an explosion in software tools. One hypothesis is that we're mis-measuring output — that the tools do create value we can't capture. But another hypothesis, which I find more compelling, is that a lot of the supposed productivity gains from software are eaten by the overhead of managing that software. Luna: So the productivity paradox of IT — the famous Solow line 'you can see the computer age everywhere but in the productivity statistics' — might be partly explained by tool proliferation itself. Lucas: Robert Solow said that in 1987, and it still resonates. But I think the phenomenon has gotten worse. Back then, a typical office worker had maybe two or three main tools — a word processor, a spreadsheet, maybe a database. Now they have a dozen or more, each with its own interface, updates, logins, and mental model. Luna: And each tool vendor has an incentive to add features to keep you from leaving, which makes the tools more complex and slower over time. Lucas: That's the feature bloat cycle. The tool that started as a simple to-do list becomes a project management suite with Gantt charts, resource planning, and ai generated status reports. The cognitive load increases. And the employee who just wanted to check off tasks now has to learn a whole system. Luna: There's a parallel with the concept of 'time poverty' in economics — the idea that as we add more options and tools, we feel more pressed for time even if we're saving time in isolated tasks. It's the paradox of choice applied to software. Lucas: That's a great connection. I want to bring in one more data point. The MIT study also found that companies with the highest tool density — more than twenty tools per knowledge worker — had the lowest self-reported productivity. And the relationship wasn't linear. Once you passed about eight tools per person, the net benefit turned negative. Luna: So there's a Goldilocks zone. You want enough tools to cover essential functions, but not so many that the overhead outweighs the benefit. Lucas: Right. And that Goldilocks zone seems to be around four to seven tools for most knowledge workers. Which is exactly where the Ohio manufacturer landed after their rationalization. Luna: What's the practical takeaway for our listeners? How do you evaluate a new tool? Lucas: I'd suggest a three-question test. First, does this tool replace an existing tool, or is it additive? If it's additive, you're increasing your tool count, so the bar should be higher. Second, what is the switching cost for each employee to learn and adopt it? Vendors often give you the implementation cost but not the ongoing cognitive cost. Third, can you measure the net time saved across the whole team, not just the champion who's pushing for it? Luna: That third one is crucial — because the person advocating for a new tool is often the one who will use it most, and they underestimate the friction for others. Lucas: Exactly. The champion is a power user. They might save an hour a day. But the rest of the team might only use it occasionally, and for them, the switching cost could be higher than the benefit. The net effect for the organization could be negative even if one person loves it. Luna: So the economics of productivity tools is partly a collective action problem. Individual tool decisions that make sense locally can create global inefficiency. Lucas: I think that's the core insight of this episode. And it's a reminder that productivity isn't just about optimizing individual tasks. It's about designing systems that minimize overhead and friction across the whole organization. Sometimes the most productive thing you can do is remove a tool, not add one. Luna: That feels like a good place to leave it. Next episode, I'd like to explore the flip side — when do tools actually create exponential productivity gains, and how do you identify those? Lucas: Perfect. We'll dig into network effects and platform economics. For now, if today's episode made you think about your own tool stack, we've done our job.