Marie Kondo Your Tech Stack

31 dashboards. Only 6 were needed.

That's not an exaggeration or a rounding error. Across a single reporting tools programme, 31 separate dashboards had accumulated over three years — built by different teams, at different times, for different stakeholders, using different data sources. Some were actively used. Some hadn't been opened in months. A few were generating numbers that directly contradicted each other.

Nobody decided to build 31 dashboards. It happened the way SaaS sprawl always happens: one tool at a time, each solving a real problem, none coordinated with the others. By the time someone asked "wait, how many reporting tools do we actually have?", the answer was already out of control.

The question was never "does this tool spark joy?" It was "does this tool still earn its place — or is it just furniture everyone stopped noticing?"

This article walks through how a reporting tools programme was audited, classified, and consolidated from 31 dashboards down to its essential parts — and the taxonomy that made sure it stayed that way.

The Audit: What Do You Actually Have?

Before you can declutter, you need an honest inventory. Not what's on the procurement spreadsheet — what's actually running, who's actually using it, and what it's actually doing.

The audit starts by pulling three lists:

1. The procurement list — every tool with an active licence or subscription
2. The usage list — actual login data and activity metrics over the past 90 days
3. The dependency list — what feeds into what, which tools are data sources for other tools, and where the integration points are

The gaps between these three lists told us everything. Tools on the procurement list but not the usage list were paying customers of products nobody was using. Tools on the usage list with no clear dependencies were islands — generating outputs that didn't feed into any decision. Tools on the dependency list that nobody logged into directly were infrastructure, and needed to be treated differently from end-user tools.

The audit took two weeks. At the end of it, the picture was clear: 31 dashboards and reporting tools, serving approximately 8 overlapping use cases, maintained by 4 different teams, with no single owner responsible for the portfolio.

The Taxonomy: Five Types of Tool

Once you have the inventory, the temptation is to start cutting. Don't. Cutting without a framework means you'll either cut too aggressively (and break something) or too conservatively (and change nothing).

Every tool was classified into one of five types. Each type has a different lifecycle, a different action, and a different timeline.

Type	Action	What It Means
Type A: Deprecate	Sunset & remove	No longer needed. Redundant, outdated, or replaced by another tool. Turn it off.
Type B: Transition	Migrate users to a different tool	The capability is still needed, but a better tool already exists in the stack. Move users over and decommission the old one.
Type C: Merge	Combine into a single tool	Two or more tools doing the same thing for different teams. Consolidate into one, with shared ownership.
Type D: Enhance	Invest and improve	This is a keeper. It sparks joy. Invest in making it better — better data, better UX, better adoption.
Type E: KTLO	Keep the lights on	Working fine, no investment needed. Maintain as-is. Don't fix what isn't broken.

The taxonomy forces a conversation that "should we keep this?" never does. Instead of a binary keep/kill decision, you're asking a more precise question: what is this tool's future? That question has five possible answers, and each one comes with a clear action plan.

Type A: Deprecate

These are the tools that don't spark joy, don't serve a purpose, and don't have users who would miss them. In this case, 11 of the 31 dashboards fell into this category.

The signs of a Type A tool:

• No active users in 90 days — the login data doesn't lie
• Outputs that duplicate another tool — two dashboards showing the same metrics from the same data source
• No downstream dependency — nothing else relies on this tool's output
• Built for a project that ended — the initiative is over but the tool lives on

Deprecation isn't deletion. Every Type A tool got a 30-day sunset window: notification to any remaining users, a data export option, and a hard shutdown date. No tool was turned off without notice. But every tool was turned off on schedule.

Type B: Transition

Transition tools are the ones where the capability matters but the specific tool doesn't. The users need what the tool does, but a better option already exists in the stack.

In this audit, 6 dashboards were Type B. They were doing legitimate work — tracking metrics that stakeholders actually used — but the same metrics were available (or could easily be added) in one of the flagship dashboards.

The Transition Playbook

Transitioning users off a tool they rely on is change management, not just a technical migration. Here's the four-step process that works:

1. Map the gap. What does the old tool do that the new tool doesn't? List every feature and data point. This becomes the requirements spec for the migration.
2. Build the bridge. Add the missing capabilities to the target tool before asking anyone to move. Nobody transitions willingly to a tool that does less than what they have.
3. Run in parallel. Both tools live side by side for 2–4 weeks. Users can compare outputs, report discrepancies, and build confidence in the new tool.
4. Hard cutover. Set a date. Communicate it. Stick to it. Parallel running without a deadline becomes permanent duplication.

Type C: Merge

Merge candidates are tools that do the same thing for different audiences. In this case, 2 pairs of dashboards were doing identical work — one built by the EMEA team, one by the US team — using different data pipelines to produce the same metrics.

Merging is harder than it sounds because each team believes their version is the correct one. The data might be slightly different (different filters, different date ranges, different aggregation logic), and each team has built workflows around their specific tool.

The merge process:

1. Align on the source of truth. Which data pipeline is authoritative? If neither is, fix that first — you can't merge tools that can't agree on the numbers.
2. Design the combined view. Not "your dashboard plus their dashboard" — a single view that serves both audiences. This usually means adding filters or segments, not duplicating sections.
3. Assign a single owner. Every merged tool needs one team responsible for it. Shared ownership is no ownership.

The 2 merges reduced 4 dashboards to 2, and eliminated the recurring problem of EMEA and US reporting different numbers for the same metric in the same meeting.

Type D: Enhance

These are your flagship tools. The ones that spark joy. The ones that, if they disappeared tomorrow, people would immediately notice and loudly complain.

In this portfolio, 6 dashboards earned the Enhance classification. They were well-adopted, actively used, and directly tied to business decisions. But "well-adopted" didn't mean "perfect" — each had gaps, usability issues, or missing data that limited their effectiveness.

Enhance means investing — not just maintaining. RICE scoring was used to prioritise which enhancements to tackle first, treating each improvement as an initiative competing for engineering time against everything else on the roadmap.

The goal of Enhancement isn't to make the tool perfect. It's to make it good enough that it eliminates the need for shadow tools — the spreadsheets, manual exports, and side-dashboards that people build when the official tool doesn't quite do what they need.

Type E: Keep the Lights On

KTLO tools are the ones that work fine and need no investment. They're not exciting. They don't need new features. They just need to keep running.

In this case, 5 dashboards were classified as KTLO. They served niche but legitimate purposes — compliance reporting, quarterly board metrics, audit trails — and were used consistently by a small audience. No complaints, no feature requests, no issues.

The KTLO classification is important because it explicitly protects these tools from two dangers:

• Over-investment — Nobody is asking for improvements. Don't allocate engineering time to make them "better" when better isn't needed.
• Accidental deprecation — They're quiet and low-profile, which makes them easy to accidentally cut during a cost-reduction exercise. KTLO status means they've been reviewed and intentionally retained.

KTLO is the tech stack equivalent of Marie Kondo's "it sparks quiet contentment." Not every tool needs to be a flagship. Some just need to work.

The Decision Tree

When classifying a tool, walk through these questions in order:

Question	If Yes	If No
Does anyone actively use this tool?	Continue to next question	Type A: Deprecate
Is another tool in the stack already doing the same job?	Type B: Transition users to the better tool	Continue to next question
Is a different team's tool doing the same job for a different audience?	Type C: Merge into a single tool	Continue to next question
Are users requesting improvements or working around limitations?	Type D: Enhance	Type E: KTLO

This decision tree isn't theoretical. It was printed on a whiteboard and every single tool was walked through it during classification sessions. The entire 31-tool portfolio was classified in two 90-minute sessions.

Measuring Success

Decluttering feels good. But "feels good" isn't a KPI. The impact of the consolidation was measured across four dimensions.

Quantitative Metrics

The final portfolio: 6 flagship dashboards (Type D: Enhance) plus 5 maintained tools (Type E: KTLO), with 11 deprecated, 6 transitioned, and 2 merged. That's a reduction from 31 to 11 active tools — a 65% reduction in portfolio size.

Metric	Before	After
Total tools in portfolio	31	11
Flagship dashboards	Unclear	6
Teams maintaining tools	4 (overlapping)	2 (clear ownership)
Conflicting data sources	Multiple	0
Completion rate	N/A	~97%

Qualitative Wins

The numbers tell part of the story. The rest is harder to measure but equally important:

• One version of the truth. When a metric is reported in one place instead of five, the "whose numbers are right?" debate disappears. Meeting time previously spent reconciling conflicting dashboards was redirected to actually discussing what the numbers mean.
• Clear ownership. Every surviving tool has a named team responsible for it. When something breaks, there's no ambiguity about who fixes it. When someone wants a new feature, there's no ambiguity about where to request it.
• Reduced cognitive overhead. New team members no longer need to learn which of the 31 dashboards to use for which purpose. There are 6 flagship tools, they're documented, and that's the stack.
• Engineering time recovered. Maintaining 31 dashboards consumed engineering capacity that was invisible in sprint planning because it was spread across bug fixes, data pipeline issues, and ad-hoc requests. Cutting the portfolio freed up meaningful capacity for enhancement work.

Lessons Learned

If I were running this consolidation again, here's what I'd do the same and what I'd do differently.

What worked

1. The taxonomy prevented analysis paralysis. Without Types A–E, every tool becomes a debate. With the taxonomy, you're classifying, not arguing. The decision tree made sessions fast and consistent.
2. Running transitions in parallel built trust. Users who could see both tools side by side for two weeks didn't resist the migration. Users who were told "your tool is being replaced next Monday" resisted everything.
3. RICE scoring for enhancement priorities kept things objective. When six flagship tools all have improvement requests, you need a way to decide what to build first. RICE provided that.
4. Hard deadlines for deprecation and cutover. Without a fixed date, every sunset gets extended. "We'll turn it off when everyone has moved" means nobody moves.

What I'd change

1. Start with the dependency map, not the procurement list. Time was spent auditing tools that turned out to be trivially obvious deprecation candidates. Starting with dependencies would have surfaced the important tools faster.
2. Involve finance earlier. Licence costs and contract renewal dates should be in the classification sessions from day one. Tools on annual contracts that auto-renew can slip past their cancellation window if finance isn't at the table.
3. Document the "why" for KTLO tools. A year later, someone will ask "why are we still paying for this?" and the context will be gone. Every KTLO classification should include a one-line justification that can be read by someone who wasn't in the room.

Keeping It Clean

Decluttering is a one-time event. Staying decluttered is a habit.

Marie Kondo's clients famously don't relapse — because the process changes how they think about acquiring new things. The same principle applies to tech stacks. After the consolidation, three guardrails were put in place:

1. New tool requests require a taxonomy classification. Before any new tool is approved, the requester must answer: which of the five types will this be? If it's an Enhance or KTLO tool, which existing tool does it relate to? If it's a net-new capability, who owns it?
2. Quarterly portfolio review. Every quarter, the tool portfolio gets a 30-minute check. Any tool that has dropped to zero active users gets flagged. Any Type E (KTLO) tool that has accumulated feature requests gets re-evaluated for Type D (Enhance) or merger.
3. One-in-one-out default. Not a hard rule, but a forcing function: if you want to add a new tool, identify which existing tool it replaces or complements. This prevents the gradual accumulation that created the 31-dashboard problem in the first place.

The goal isn't to prevent growth. It's to make growth intentional. Every tool in the stack should have a classification, an owner, and a reason for being there. If it doesn't, it's already a candidate for the next audit.

Final Thought

Tech stacks don't get bloated because people make bad decisions. They get bloated because people make good decisions — one at a time, without coordination, over years. Each tool solved a real problem when it was introduced. The problem isn't any individual tool. The problem is that nobody is looking at the portfolio.

The taxonomy gives you a way to look at the portfolio. Five categories. One decision tree. A classification session that takes three hours. And then the discipline to maintain it.

The portfolio went from 31 dashboards to 11. The 6 flagships are better than any of the original 31 were individually, because the engineering time recovered from maintaining 20 unnecessary tools went straight into improving the ones that matter.

Keep the tools that spark joy. Deprecate the ones that don't. And build a system that prevents the clutter from coming back.