在组织层面，技术债务是一个需要管理的投资组合，而不是需要消除的待办事项。目标不是零债务；而是将债务保持在不威胁速度、可靠性或交付战略能力的水平。
如何思考这个问题
text
MAKE DEBT VISIBLE AND PRIORITIZED
- Inventory the debt that actually hurts (slows delivery, causes incidents)
- Classify: strategic (deliberate) vs accidental vs decay/rot
- Quantify impact in business terms (velocity, downtime, churn risk)
- Allocate a steady % of capacity to paydown (commonly 15-25%)
并非所有债务都值得偿还。稳定、很少改变的系统中的债务可以放在一边；热门、快速变化的领域中的债务应该首先偿还。
具体例子
一位CTO制定了一条规则：每个团队的容量的20%用于可靠性和债务，然后将其针对导致80%事件的三个系统，而不是到处分散。
权衡与陷阱
- **陷阱：**进行"大重写"以清除所有债务，这通常会超支并重新产生债务。
- **陷阱：**从不偿还，直到速度崩溃。
- 将债务仅仅视为工程关注会失败；将其与业务成果联系起来以获得支持。
为什么这很重要
未管理的技术债务会悄然复合，直到功能需要数月，事件激增。
作为一个深思熟虑的投资组合来管理它，可以在多年内保持组织的速度和可靠性，并将抽象的工程担忧转化为领导层可以推理的量化业务权衡。