Most operations stacks grow by addition. A tool solves a real problem, someone adds it, and it stays forever, whether or not the problem it solved is still the problem you have. Nobody schedules the meeting where a tool gets removed. The result, two or three years in, is a stack nobody fully understands, a monthly bill nobody's audited line by line, and a team quietly working around three tools that all claim to do the same thing.
Why stacks only grow
Adding a tool solves an immediate, visible problem: someone's blocked, a manager approves a subscription, the blocker's gone within a week. Removing a tool solves a diffuse, invisible problem: mild redundancy, a little wasted spend, some cognitive overhead nobody's complained about loudly enough to fix. Given that comparison, addition wins every time, not because anyone's being careless, but because the case for adding is always stronger in the moment than the case for subtracting.
What the audit actually checks
Who logs in, and how often
Pull actual usage data, not who was given a seat. A tool with 20 licenses and 4 active weekly users isn't a tool the team relies on, it's a tool three people tried once and one person still uses.
What it does that nothing else in the stack does
Map each tool to the job it does. When two tools map to the same job, that's not redundancy by design, it's usually two different hires or two different pushes solving the same problem without knowing the other tool already existed.
What breaks if it disappears tomorrow
Some tools are quietly load-bearing even with low login counts, a reporting tool that feeds one dashboard the leadership team actually reads, for example. Test for real dependency, not just activity.
What it costs against what it replaced
A tool bought to save time should be measured against the time it actually saves, not the time it was pitched to save. If nobody can point to what got faster or what stopped requiring a person, that's the tell the ROI case never got tested after purchase.
When adding a tool is the wrong fix
The instinct when something's slow or messy is to look for a tool that fixes it. Sometimes the real problem is upstream of any tool: bad data feeding a good system, a process nobody follows consistently, or a handoff with no clear owner. Buying a tool on top of that doesn't fix the root cause, it adds a subscription to a problem that was never about tooling in the first place. This is the same trap covered in signs your operations are broken, heroics and dropped balls usually trace back to ownership and process, not a missing piece of software.
Making the audit a habit, not a one-time cleanup
A single stack audit feels good and fixes the backlog of accumulated redundancy, but the stack starts growing again the moment it's over unless the review becomes routine. Put it on the same cadence as the kind of weekly ops review that already asks what's actually working, just less often, quarterly is usually enough.
Every tool answers three questions: who uses it, what would break without it, and what it costs against what it saves. A tool that can't answer all three isn't automatically cut, but it's earned a real conversation instead of another year of auto-renewal.
FAQ
What should an ops stack audit actually check?
Four things per tool: who actually logs in and how often (real usage, not seats issued), what it does that nothing else in the stack does, what breaks if it disappears tomorrow, and what it costs against what it's actually measured to save, not what it was pitched to save.
Why do ops stacks only grow and rarely get cut down?
Adding a tool solves a visible, immediate problem, so it's easy to approve. Removing one solves a diffuse, invisible problem like mild redundancy or a little wasted spend, so there's rarely a moment that forces the conversation. Given that comparison, addition wins by default.
When is buying a new tool the wrong fix?
When the real problem is upstream of any tool, bad data feeding a good system, a process nobody follows consistently, or a handoff with no clear owner. A new subscription on top of that doesn't fix the root cause, it just adds cost to a problem that was never about tooling.
How often should you run a stack audit?
Quarterly is usually enough. A one-time cleanup fixes the current backlog of redundancy, but the stack starts growing again immediately unless the review becomes a routine, similar in cadence to a regular ops review.
Ops stacks grow by addition because adding a tool solves a visible problem while removing one solves a diffuse, invisible one, so subtraction almost never happens on its own. A real audit checks actual usage, overlap with existing tools, real dependency, and cost against measured value, not the pitch. Sometimes the fix isn't a new tool at all, it's the process or ownership upstream of it. Run the audit quarterly, not once, or the stack quietly grows right back.
Read next
Not sure what in your stack is earning its subscription?
I help teams audit the tools they've accumulated, cut what's redundant, and fix the process gaps a new tool won't actually solve. See how I work.
Book a Call