You Don't Have Too Many Tools. You Have Too Many Owners.

Every revenue stack I have inventoried ran north of 25 tools, and a couple pushed past 28. Every year someone in finance notices the line item, calls it tool sprawl, and announces a procurement freeze. Six months later the stack is the same size, because a freeze stops new tools from arriving and does nothing about the twelve you already pay for that nobody owns.

For years the standard move was to cut the stack by budget line: sort tools by cost, cancel the top few, declare victory. That move fails because it treats sprawl as a spending problem. It is not. Sprawl is a governance problem. You bought a tool, the person who championed it left, and now it renews on autopilot with no one accountable for whether it earns its seat. The expensive orphan and the cheap orphan are the same disease, and cost tells you nothing about which one to cut.

Here is the tell. Ask “who owns Outreach” and if the answer is a shrug or a committee, that is a tool that will renew forever regardless of usage. The tools that get killed are the ones with a named owner who can be asked “is this still worth it” and has to answer. The fix, then, is not a budget cut. It is a build: five rungs that climb from a spreadsheet to a self-governing stack, where every tool has one owner and a scheduled moment when keeping it is a decision rather than a default.

Climb it bottom to top. Each rung is worthless without the one below it, which is why the budget-cut approach fails: it jumps straight to killing without inventory, ownership, or a scored reason. Scroll the ladder, then I will show you the scorecard and the config that make each rung real.

1. R5Make the ritual recurringquarterly

   Every quarter, score the tools renewing in the next 90 days in front of their owners. New tools enter the RACI on purchase. The stack now governs itself and the annual sprawl panic ends.

2. R4Kill or keep on the scoreunder 6

   Anything under 6 goes on the kill list unless the accountable owner writes a case. Cancel before the auto-renew fires, because a kill decision that lands after renewal is a note for next year, not a saved dollar.

3. R3Score overlap and usage0 to 10

   Run the five-question scorecard. Active usage, unique job, revenue line, owner clarity, switching cost. This is where the second enrichment vendor and the dead-champion tool show up as numbers instead of hunches.

4. R2Force one name into Accountable1 name

   Fill a RACI with a single accountable human for every row. The rows where no name fits are your orphans, and you find them with zero usage data. This rung alone surfaces four or five kills.

5. R1Inventory every tool and renewal date25+ rows

   One row per tool: name, annual cost, renewal date, auto-renew yes or no. This is the spine. Nothing above this rung can happen until the list exists, and the renewal date is what schedules everything later.

Locate your stack on that ladder. Most teams live below R2, with a list somewhere and no accountable column filled in. That is why the freeze is the only tool they reach for: without ownership and scores, killing anything feels arbitrary, so they block the front door instead. Every rung above R2 replaces arbitrary with defensible.

The two artifacts the ladder runs on

The whole build is two artifacts: a RACI and a decommission ritual. Rungs R1 and R2 produce the RACI. Rungs R4 and R5 are the ritual. Rung R3, the scorecard, is the hinge between them.

The RACI is one row per tool. Responsible is the person who administers it day to day. Accountable is the single name who answers for its value and signs its renewal. Consulted is whoever depends on its output. Informed is everyone downstream. The point of the exercise is the Accountable column, because filling it in surfaces every orphan instantly. When you sit the team down and force one name into Accountable for all 25 rows, you will find four or five tools where no name fits. Those are your first kills, and you found them without touching usage data.

The decommission ritual is a standing quarterly review where every tool coming up for renewal in the next 90 days goes through a kill-or-keep scorecard in front of the person accountable for it. Not a freeze. A recurring decision point. A tool does not renew because the contract auto-renews. It renews because a named human scored it and argued to keep it.

The two artifacts feed each other. The RACI names who defends each tool; the ritual is the moment they defend it. The diagram is the loop.

The kill-or-keep scorecard (rung R3)

Score each tool zero to two on five questions. Ten is the ceiling. Anything under six goes on the kill list unless the owner makes a written case.

Question	0	1	2
Active usage	Under 20% of licensed seats used monthly	20 to 60%	Over 60%
Unique job	Fully overlaps another tool we own	Partial overlap	Nothing else does this
Revenue line	No traceable link to pipeline or retention	Indirect	Directly in a revenue workflow
Owner clarity	No Accountable name	Named but disengaged	Named and actively manages it
Switching cost	Rip it out tomorrow, no one notices	Some rework	Deeply wired, high migration cost

A tool scoring 60% usage, zero unique job, indirect revenue link, no owner, and low switching cost lands at 4. That is a $30K/year renewal you cancel before the auto-renew fires. A tool at 9 with 70% usage and a unique job is safe and you stop questioning it.

The five questions are not arbitrary, and it is worth knowing why each one earns its place. Active usage is the fastest tell, because a tool nobody logs into is already dead and only the invoice has not noticed. Unique job is the overlap test, and it catches the most expensive sprawl, the second tool that does what a tool you already own does, bought by a team that did not know the first one existed. Revenue line forces the owner to trace the tool to a workflow that makes or keeps money, and a tool that cannot be traced there is a nice-to-have wearing a must-have badge. Owner clarity is the orphan detector, and it is the one that surfaces the champion-left-in-March problem the freeze can never see. Switching cost is the honest counterweight: a deeply wired tool with mediocre usage might still be a keep, because ripping it out costs more than the renewal, and the scorecard should tell you that rather than let you make an expensive purity decision.

Notice what the scorecard deliberately does not include: how much the tool costs. Cost is not a scoring input, because a cheap orphan is still an orphan and an expensive tool that scores nine is still worth keeping. Cost belongs in the prioritization of your kill list, not in the kill decision itself. Score first on value and ownership, then sort the kills by dollars so you cancel the biggest silent charges first.

The config that makes it a system, not a spreadsheet

The reason most governance dies after one quarter is that it lives in a slide nobody re-opens. Put the RACI and the scorecard weights in a config file that a scheduled job reads, and the ritual runs itself. Here is the shape I use: one entry per tool, the five scores, and a renewal date the job compares against today to flag what is due in the next 90 days.

# stack-governance.yml: one entry per tool; a weekly job scores and flags renewals
kill_threshold: 6          # total below this needs a written case
review_window_days: 90     # flag renewals inside this window

tools:
  - name: Outreach
    accountable: sdr_manager        # R2: exactly one name, never a team
    annual_cost: 84000
    renewal_date: 2026-11-01
    auto_renew: true
    scores: { usage: 2, unique: 2, revenue_line: 2, owner: 2, switching: 2 }
    # total 10 -> keep, stop asking

  - name: IntentData
    accountable: null               # no name fits -> orphan, R2 flags it
    annual_cost: 30000
    renewal_date: 2026-08-15
    auto_renew: true
    scores: { usage: 0, unique: 0, revenue_line: 0, owner: 0, switching: 0 }
    # total 0 -> kill before 2026-08-15

  - name: Enrichment2
    accountable: null
    annual_cost: 22000
    renewal_date: 2026-09-30
    auto_renew: true
    scores: { usage: 1, unique: 0, revenue_line: 1, owner: 0, switching: 1 }
    # total 3 -> kill, fold coverage into primary waterfall

The rule the job enforces is one line: sum(scores) < kill_threshold and (renewal_date - today) <= review_window_days puts a tool on this quarter’s kill agenda. Everything else is defended data. When finance asks why the stack still has 22 tools, you hand them the file: 22 entries, each with a named human and a score above six.

A worked pass, reconciled to the tiles

Run it on a real slice. The three tools in that config are the same three below, scored line by line so the numbers are not hand-waved.

Two of the three land under the 6 that the tiles at the top call the kill line, and both are orphans with no accountable name, which is the R2 detector doing its job before any usage export loads. The one keep scores 10 and has a named owner. That is the whole argument in three rows: ownership and score, not cost, decide the cut.

View as table

Item	Value
Scheduling tool	10
Enrichment #2	3
Intent data	0

Three tools, two dead, one safe. You cut two renewals worth $52K and the stack got smaller without a freeze, without a fight, and without a committee. The scorecard did the arguing.

Why the budget cut and the freeze both fail

A freeze punishes the next person trying to solve a real problem while protecting every orphan already in the stack. A budget cut is the same mistake wearing a spreadsheet: it kills by dollar rank, so it cancels an expensive tool with 70% usage and keeps a cheap orphan nobody logs into. Both optimize the wrong direction. New tools are rarely the sprawl, and cost is rarely the signal. The sprawl is accumulated ownership debt: purchases whose champions left, whose use cases died, whose value nobody has been forced to defend in two years. A freeze cannot see those because they are already inside the wall, and a budget cut mis-ranks them because it never asks who owns them.

	Procurement freeze	Ownership plus ritual
What it stops	New tools arriving	Dead tools renewing
The orphan tool	Renews untouched inside the wall	Fails the scorecard, gets cut
Who it punishes	The next real problem-solver	Nobody; it only requires a defense
Six months later	Stack is the same size	Stack is smaller by the orphans
Adding a needed tool	Blocked by policy	Arrives with an owner and a scorecard slot

Ownership plus a ritual sees the orphans by construction. The RACI names them. The quarterly scorecard makes every renewal a defended decision instead of a silent charge. You will still add tools, because sometimes you should, and now each addition arrives with an owner and a place on the next scorecard instead of joining the graveyard.

The other thing the ritual buys you is a paper trail for the renewals you keep. When finance asks why the stack still has 22 tools after a year of governance, the answer is 22 scorecards with a named human who argued to keep each one. That ends the annual sprawl panic, because the conversation is no longer “why do we have so many tools” but “which of these scored below six,” and that list is already sitting in the config.

Here’s how I’d build it: the week-one version

The ladder is the shape. This is the order I would stand it up in, and you can get through rung R2 in an afternoon without waiting on a single usage export.

1. 1

   Step 1, list every tool and its renewal date

   One row per tool: name, annual cost, contract renewal date, auto-renew yes or no. This is rung R1, the spine. The renewal date is what schedules the ritual.

2. 2

   Step 2, force one name into Accountable

   Fill the RACI Accountable column with a single human for every row. The rows where no name fits are your kill list this week, found with zero usage data. This is rung R2.

3. 3

   Step 3, score every tool zero to ten

   Run the five-question scorecard. Anything under 6 goes on the kill list unless the accountable owner writes a case. This is rung R3, where overlap and dead champions surface as numbers.

4. 4

   Step 4, cancel before the auto-renew fires

   For every kill, give notice ahead of the renewal date. Rung R4. A scorecard that lands after the auto-renew is a note for next year, not a saved dollar.

5. 5

   Step 5, make the ritual recurring

   Every quarter, run the scorecard on tools renewing in the next 90 days, in front of the accountable owner. Rung R5. New tools enter the RACI on purchase, and the stack governs itself.

Start with rung R1, not the scorecard. One row per tool, one name forced into the Accountable column for every one. The rows where no name fits are the orphans, and you will have that list inside an hour without pulling a single usage report. For the scoring rubric that decides a single purchase before it ever joins the stack, see the tool evaluation scorecard. And if the ladder leaves you wondering how small the stack can get, see the five-tool stack.