Development & Code · master area
Technical Debt Management
Not bad code — unresolved decisions in the chain. The accumulated cost of gaps that were not closed when they were found. Tracked by chain level, named, sized, paid down deliberately.
Owners: Tech Lead, PO Phase it lives in: After We Build (Volume V) The corpus principle this enacts: Technical debt is unresolved decisions in the chain.
Where it lives in the chain
How to do this
- Naming — every piece of debt has: what it is, which chain level produced it, what it blocks, what it costs to pay down, what it costs to leave.
- Tracking — debt lives in the same backlog as features, labelled
chain-level/<L>. Hiding debt in a separate list is hiding the cost. - Cadence — portfolio review reads the debt distribution. Concentration in one chain level (most often Discovery or Operation) is a signal to invest in the chain at that level — not just to pay down items.
What good practice looks like
Debt is named, not vague:
- "The grading event has no version field. Adding a v2 event will break consumers silently. Cost to fix: 2 days. Cost to leave: every consumer change risks production. Chain level: Architecture."
- "The
submissionmodel conflates draft and final state. Six bugs traced to confusion between the two. Cost to fix: 1 week. Cost to leave: every grading feature inherits the confusion. Chain level: Scope." - "Three feature flags from Q1 still wrapping behaviour. Two paths still maintained. Cost to fix: 1 day each. Cost to leave: ongoing maintenance + risk of stale path drift. Chain level: Operation."
A team that spends 100% of capacity on new features and 0% on debt is a team whose chain will degrade until new features take twice as long — because every change has to work around the accumulated gaps. The portfolio's job is to keep the ratio honest.
Related crafts
- Financial Translation — debt has a cost number
- System Signal Tracking (DORA) — debt shows up in lead time and change failure rate
- Refactoring — the in-flight repayment mechanism