top of page
Search

The Real Waste in Knowledge Work Isn't What You Think



Here's something they don't teach you in business school: in knowledge work, there's no conveyor belt to tell you when you've wasted something.


If you run a factory a real one, with machines and raw materials waste is visible. You can weigh it, measure it, sweep it off the floor. When Chris walked through a McDonald's fry factory earlier in his career, he watched a dump truck of potatoes go in one end and perfectly bagged fries come out the other. One guy with a hose. Decades of refinement. Millions of dollars of machinery. No ambiguity about what got made, and no ambiguity about what got wasted.


Knowledge work doesn't give you that.


In knowledge work, the waste is time — and the insidious thing about time is that it disappears in ways that feel productive.




The Switching Cost Nobody Admits To

Chris has been doing software implementations and change management work. As part of that, he got disciplined about tracking his time starting a timer for each client, each task, each meeting.


What he found wasn't just inefficiency. It was a kind of clarity he hadn't expected.


"There's nothing more magical than two to three hours of lost time working on something that's challenging," he said. "There's nothing more rewarding."


But getting there required seeing, in uncomfortable detail, exactly how much time didn't go toward deep work. The five minutes between meetings. The email that pulled him sideways. The moment he switched clients and then switched again before either task had traction.


Switching cost is real. It's just invisible until you make yourself look at it.


The Tool Suite That's Designed to Distract You

Here's the uncomfortable truth about the standard office software stack: it's built to interrupt you.


Outlook wants your attention. Teams wants your attention. Every notification, every badge, every unread count — it's all pulling you toward reactive work and away from the deep stuff.


And we've developed a cultural story around this that lets us off the hook. "Answering email is work." Sure. But is it good work? Is it the work that moves things forward?


The corollary from operations management is quality. Quality is hard to define, but as Chris put it "you know it when you get it." The same is true of good knowledge work. You know when you've done it. You feel the difference between a morning where you shipped something real and an afternoon where you stayed busy.


The problem is that our tools and our habits make it easy to stay busy indefinitely without ever doing the real work.




Why Knowledge Work Changes Fast (And That's a Problem)

The fry factory runs the same way today as it did fifty years ago, roughly. Minor improvements, new technology at the margins. But the core process — potatoes in, fries out — is stable. That stability was earned through slowness. The machinery forced it.


Knowledge work has no such constraint. A CEO can pivot a knowledge-based business with a few decisions and a slide deck. There's no million-dollar equipment to reconfigure. And that speed is genuinely an advantage — until it isn't.


The flip side of that agility is what Chris calls the Dunning-Kruger problem: in knowledge work, we consistently oversimplify change and overpredict what will happen when we implement something new. We build the software rollout, we announce the new process, we declare the problem solved.


And then six months later, nobody's filling out the status column.


The people who built the fry factory couldn't afford that kind of optimism. Writing the check forces you to slow down. The absence of that forcing function in knowledge work is one of the reasons process debt accumulates so quietly.




Going to the Gemba (And What That Means When There's No Shop Floor)

In Toyota's production system, there's a concept called going to the gemba — going to the actual place where work happens to see what's really going on. Not the report about the work. Not the dashboard summarizing the work. The work itself.


In knowledge work, we forget to do this. And it's not because we don't know better — it's because there's no obvious shop floor to visit.


But there is one. It's your colleague's desk. It's the person who reports to you. It's the customer on the other end of the process. The question "how are you delivering value, and to whom?" is just as valid in a software company as it is in a factory. We just don't ask it as often, because we've over-indexed on metrics that serve the business's profitability rather than the person doing the work or the customer receiving it.




The 70% Rule

One of the most practical insights from this conversation: stop trying to be perfect before you show your work.


When Chris was younger, he'd spend hours polishing a spreadsheet or a PowerPoint before presenting it. Inevitably, his manager would have notes — sometimes just a typo, sometimes a direction change that made half the work irrelevant.


Midway through his career, he learned to stop at 70% and invite feedback earlier. Same outcome. Far less wasted effort.


This isn't just personal productivity advice. It's a process principle. The urge to over-polish before sharing is a form of waste — and it's compounded when the direction is wrong. Getting alignment early is cheaper than getting it perfect late.




What This Actually Changes

If time is the waste in knowledge work, then the question isn't "how do I work faster?" — it's "how do I protect the work that matters?"


That means:


  • Batching tasks instead of context-switching constantly

  • Planning your week around the work that has real value, not just the work that fills the calendar

  • Tracking your time honestly, even briefly, to see where it actually goes

  • Checking in earlier on projects to avoid over-building in the wrong direction

  • Going to the gemba — talking to the people doing the work, not just reading the summary


None of this is new. But the clarity that comes from watching your timer tick on something that doesn't matter — that part is underrated.



Process Debt is a podcast about why software implementations fail and what to do about it. New episodes drop weekly.


 
 
 

Comments


bottom of page