Every business I've ever worked with has a proverbial junk drawer. It's the collection of processes, tools, meetings, and approval chains that made perfect sense when someone created them and now exist for no reason other than nobody has asked whether they still should.
The CRM that three departments pay for, but only sales logs into. The weekly status meeting that probably should be a shared doc but has been on the calendar since 2019. The QA checkpoint which hasn't caught a defect in fourteen months but adds two days to every delivery cycle. The expense approval chain was designed for a procurement policy that was changed three years ago.
Each one seems small, but that's precisely what makes them so dangerous. Death by a thousand paper cuts. You don't notice an extra ten minutes here, a redundant sign-off there, or a $200/month license nobody remembers authorizing. But operational dead weight is cumulative, and the accumulation is invisible because nobody is looking at the total.
I think most SMBs are carrying somewhere between 10 and 20 percent more overhead than they need to, serving problems that no longer exist. And I think the reason it persists is simple: businesses are very good at adding things when problems emerge and almost constitutionally incapable of removing them when the problem goes away.
How the Weight Accumulates
The pattern is always the same. Something goes wrong, and leadership responds by adding a process. A review step, an approval gate, a standing meeting, a new tool.
And the process works. The specific problem it was designed to fix gets fixed, and everybody moves on.
But the process lives on. The problem it solved might evolve, disappear, or get solved by something else entirely, but the process remains on the calendar, in the workflow, and on the invoice. It becomes part of "how we do things here," which is the corporate equivalent of furniture you stop seeing because it's been in the same spot for years.
SurveyMonkey's parent company Momentive ran this exercise on their software stack, and the results were uncomfortable. They discovered they were running 430 applications across the organization. After a systematic audit, they canceled 222 of them, removing roughly $7 million in annual spend. Not by cutting things people needed, but by eliminating things nobody was using.
Momentive's situation wasn't unusual. Research consistently shows that companies use only about half of the software licenses they pay for. And that's just software, the category where usage is easiest to measure. The process bloat, the meeting bloat, the approval-chain bloat? Nobody's even counting.
Three Questions That Cut Through It
The diagnostic is blunt and actually pretty easy; you just need to take the time to do it. List every recurring process, tool, meeting, and approval in the operation. Not just the ones you think might be unnecessary. All of them. Then gather your leadership team and front-line personnel from operating teams, and ask three questions about each one.
What specific problem did this solve when we created it?
This question alone eliminates a surprising amount. Half the time, nobody in the room can answer it. The process predates everyone currently involved. It was inherited, not designed. When nobody can articulate the original problem, you're maintaining a solution to a question nobody remembers asking.
Does that problem still exist?
Regulations change. Team structures change. Tools change. The manual reconciliation step that existed because two systems didn't talk to each other might be pointless now that someone built an integration eighteen months ago. The approval gate that existed because a junior employee made a costly mistake might be unnecessary now that the junior employee is a senior manager with a decade of context.
Some worry that removing bloat will cause the unknown original issue to recur. It doesn't matter. The gain from bloat elimination is greater than the risk of a mystery gap revealing itself. The question you should be asking is, "Is this problem active right now in a way that justifies this specific process?" If the answer is no, kill the process.
What would break if we stopped doing it for 30 days?
This is the kill shot. Most leaders who've never run this exercise assume the answer is "something important," but it turns out most leaders who actually run it discover the answer is "nothing." The 30-day trial is a pressure test rather than a permanent elimination. If you stop a process for a month and nobody notices, you have your answer. If something breaks, you restart it with the knowledge that it's genuinely load-bearing and not just legacy furniture. If you (or your organization) are even more skittish, you can adapt this to a quarterly or even annual trial.
Netflix operates with a version of this philosophy baked into their culture. They systematically eliminated traditional performance improvement plans, annual reviews, and most approval processes, not because those things are inherently bad, but because they examined each one and found the original problems had better solutions. The expense policy became "act in Netflix's best interest." The performance management system became real-time feedback. They didn't remove structure. They removed the structure that was serving yesterday's problems while creating drag today.
Why Business Leaders Resist This
Knowing the diagnostic and actually running it are very different things.
Loss aversion is the big one. Removing a process feels riskier than keeping it, even when keeping it has a measurable cost and removing it has a theoretical one. Now that just doesn't make sense, does it?
The old known process feels like a sturdy guardrail, and taking it down feels like you just may be tempting fate. But a guardrail on a road nobody drives anymore isn't protecting anything, is it? It's just taking up space.
Then there's ownership ambiguity. Nobody owns the process, which means nobody has the authority to kill it. It lives in the gap between departments, maintained by inertia and funded by a budget line that gets approved annually without scrutiny because it's small enough not to trigger a review. And the cost is distributed across departments, making it even harder to feel, all while the benefit (or lack thereof) is invisible. No single unnecessary process is expensive enough to flag. The total requires someone to add it up, and adding it up requires the audit that nobody wants to run.
Ownership ambiguity is a killer. Leaders, either themselves or a central team depending on the size of your org, need to be assigned ownership for these orphan processes and expenses.
The Compound Effect
What makes this worth doing isn't any single process you'll eliminate. It's the compound effect of removing dozens of small drags simultaneously. Two days off a delivery cycle here, one unnecessary meeting a week there, a sign-off step that adds a day to every vendor payment.
Individually, none of these justify an operational review, but collectively, they're the difference between an organization that moves at the speed of its people and one that moves at the speed of its accumulated process debt.
The leaders I respect most treat their operations the way a good mechanic treats an engine. They don't just add parts when something rattles but periodically pull things apart to see what's still doing useful work and performing the way it should. Warning though, the audit isn't glamorous; it probably won't produce a framework you can put on a slide, and it can lead to some humbling realizations (and some outright stupid decisions)... but it might be the highest-ROI afternoon you spend this quarter, because the weight you're carrying is very real, even if you've stopped feeling it.
Keep building,
-- JW
