- Home
- Skills
- Refoundai
- Lenny Skills
- Managing Tech Debt
managing-tech-debt_skill
5
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill refoundai/lenny-skills --skill managing-tech-debt- SKILL.md6.0 KB
Overview
This skill helps product leaders and engineering teams manage technical debt strategically so it becomes a measurable, prioritized part of product work. It guides diagnosis, approach selection (incremental fixes vs. refactor vs. rare rewrite), and stakeholder communication so teams spend less time firefighting and more time shipping value.
How this skill works
I ask targeted questions to understand the nature and business impact of the debt, diagnose urgency and resource allocation, then recommend a practical approach: immediate bug fixes, targeted refactors, or a carefully scoped rewrite only when justified. I help build a business case by quantifying maintenance cost, defining metrics, and proposing experiments or small bets to prove ROI.
When to use it
- You’re facing slow delivery velocity or frequent incidents caused by legacy code.
- You must decide between a full rewrite and incremental improvements.
- You need to get stakeholder buy-in and budget for tech debt work.
- You’re balancing new feature delivery against ongoing maintenance.
- You want to reduce code complexity or safely delete unused code.
Best practices
- Treat technical debt as product debt: include it in priorities and roadmap decisions.
- Prefer incremental evolution and targeted refactors; rewrites are a last resort.
- Quantify the cost of debt with custom metrics and small experiments to show value.
- Fix surfaced bugs immediately or close them; avoid growing a graveyard backlog.
- Allocate regular deletion work (remove unused code) to improve velocity and clarity.
Example use cases
- Build a one-page assessment: type of debt, impact, % engineering time consumed, recommended next steps.
- Create a simple ROI experiment that shows how paying down a module’s debt reduces incident time by X%.
- Design a phased refactor plan that preserves shipping cadence and minimizes dual-system maintenance.
- Draft a stakeholder brief that reframes debt as product risk with measurable outcomes.
- Plan a biweekly deletion sprint to remove unused code and reduce build times.
FAQ
Rarely. Only when the existing system is actively blocking core business goals, incremental fixes are impossible, and you can tolerate a prolonged delivery hiatus with clear plans to support both systems.
How do I get non-technical stakeholders to care?
Translate debt into business terms: show time spent on maintenance, incident cost, lost feature velocity, and run a small experiment that demonstrates measurable gains from paying down debt.