Update to Headcount: Technology

{
  "description": "Makes technical debt visible and decidable — distinguishing real debt from mess, quantifying its cost, and arguing for remediation in business terms. Use this to assess and prioritize debt, decide whether to fix or live with something, justify remediation work to non-engineers, or plan a migration off a system nobody wants to touch.",
  "included_files": [
    {
      "relative_path": "references/sources.md",
      "size_in_bytes": 863
    }
  ],
  "name": "technical-debt-management",
  "skill_md_contents": "---\nname: technical-debt-management\ndescription: Makes technical debt visible and decidable — distinguishing real debt from mess, quantifying its cost, and arguing for remediation in business terms. Use this to assess and prioritize debt, decide whether to fix or live with something, justify remediation work to non-engineers, or plan a migration off a system nobody wants to touch.\n---\n\n# Technical debt management\n\nDebt is a deliberate trade: taking on future cost to move faster now. Most of what gets called debt\nis not that — it is mess, which was never a decision, or drift, where the world moved and the code\ndid not. The distinction matters because the arguments and remedies differ.\n\n## Classify before prioritizing\n\n- **Deliberate debt** — a known shortcut with a reason. Has a principal and interest. Legitimate.\n- **Mess** — nobody chose it; it accumulated. No trade was made, so there is nothing to defend.\n- **Drift** — the code was right for a context that has changed. Neither shortcut nor carelessness.\n- **Not debt at all** — code someone dislikes, or would have written differently. Taste is not debt,\n  and rewriting on taste is how remediation budgets get spent with nothing to show.\n\n## Cost is a rate, not a total\n\nDebt matters proportional to how often you pay it. Ugly code in a module nobody has touched in three\nyears costs nothing; a moderate awkwardness in the file every feature crosses costs continuously.\n\nMeasure by contact: change frequency, how long changes there take relative to elsewhere, how often\nchanges there cause incidents, and how many people avoid the area. Overlay change frequency on\ncomplexity and the priorities become obvious and defensible — the expensive parts are where both are\nhigh, which is rarely where intuition points.\n\n## Argue in the language of the decision-maker\n\n\"The code is bad\" loses to any feature request. What wins is the rate: this area consumes a\ndisproportionate share of delivery time, causes a disproportionate share of incidents, and the gap\nwidens.\n\nFrame remediation as capacity recovery with a payback period — the same terms as\n`finance:capital-allocation`, which is where any large migration will eventually be judged.\n\n## Remediate incrementally\n\nLarge rewrites fail at a well-documented rate: they take longer than estimated, deliver no value\nuntil the end, and are canceled halfway leaving two systems. Prefer strangling the old system\ngradually behind a stable interface, so value lands continuously and the work can stop at any point\nwithout leaving a mess.\n\nImprove opportunistically where you are already working — the code you are touching anyway is the\ncheapest code to improve, and it is by definition the code that is being touched.\n\n## Sources\n\n`references/sources.md` in this skill lists the outside authorities that settle the questions\nhere — what each one is authoritative for, and what you may do with it. Check them before\nanswering on anything they cover, and cite what you used. Most are free to read and not free\nto reproduce; the use note on each is binding.\n\n## Never\n\n- Present debt as a quality argument to someone accountable for delivery dates.\n- Prioritize by how bad code looks rather than how often it is paid for.\n- Start a rewrite with no value delivered until completion.\n- Classify taste as debt.\n"
}