Tech Debt Governance & Policy
Last updated . Sources are named and dated inline - how we source claims.
Organizational governance frameworks for managing technical debt at scale - classification, capacity allocation, tracking, and accountability
What This Page Covers
This page covers technical debt governance that has nothing to do with AI: definitions of done that stop new debt at the source, the debt budget and how capacity is protected, the debt register, P1 to P4 classification, escalation paths, the exception process, and the reporting cadence that keeps leadership engaged. If your question is about debt in general - how it gets found, ranked, funded, and reported - you are in the right place.
For AI coding policy - approved tools, acceptable use, approval gates by code sensitivity, policy templates, rollout phases, and governance metrics for AI-assisted development - see the AI Coding Governance Framework. That is the canonical page for it, and this page deliberately does not repeat it.
For the engineering practice around AI-generated code - what a reviewer does differently, pull request checks, diff-size limits, and prompt hygiene - see Managing AI Code Quality at Scale.
Why Governance Matters
Without Policy, Debt Decisions Are Ad Hoc
In most organizations, technical debt decisions happen in the moment - during sprint planning, in code reviews, or as side conversations between engineers. Every team makes different tradeoffs. One team pays down debt religiously while another accumulates it without tracking. The result is inconsistency that compounds across the organization.
Governance creates consistency without bureaucracy. It establishes shared language for talking about debt, agreed-upon criteria for prioritization, and guaranteed capacity for addressing it. Teams stop arguing about whether to fix debt and start executing against a clear framework.
The goal is not to add process for its own sake. The goal is to make debt management predictable, measurable, and sustainable - so it actually happens instead of being perpetually deferred.
Without governance, every team uses different criteria to decide what debt to fix and when
With governance, shared classification and capacity rules create predictable debt management
Governance makes debt reduction a habit, not a heroic effort that happens once a year
Definition of Done: Where New Debt Stops
Every governance framework that starts with the backlog is already losing. A debt register tells you what you owe; a definition of done decides how fast the balance grows. It is the single cheapest governance artifact you will write, because it is enforced by people who are already reviewing the work, and it needs no committee to operate.
What Belongs in It
- - Tests exist for the behaviour changed, including the failure path
- - Monitoring and alerting cover the new code path in production
- - Documentation and runbooks updated in the same change, not "later"
- - No new dependency added without a recorded reason and a licence check
- - Any shortcut taken is filed in the debt register before merge, with an owner
- - Feature flags carry a removal date at the moment they are introduced
What Makes It Fail
- - A list so long nobody reads it past the fourth item
- - Criteria nobody can check without a meeting
- - A standing culture of waiving it whenever a date is close
- - Written by leadership, never shown to the engineers it binds
- - No mechanical enforcement, so compliance depends on memory
- - One global list applied identically to a prototype and a payments service
The Deliberate Shortcut Clause
Teams will ship shortcuts, and a policy that pretends otherwise just drives them underground. Make the shortcut legitimate and visible instead: any item that fails the definition of done may still merge, provided a register entry exists before merge, with a named owner, a severity, and the condition under which it must be revisited. Nothing is refused; everything is recorded.
This one clause is what converts invisible debt into tracked debt. Teams that adopt it typically discover that the register grows quickly for a quarter and then stabilises - which is not new debt appearing, it is existing debt becoming visible for the first time. Expect that, and warn leadership before the first monthly report lands on their desk.
Debt Classification System
A classification system gives your organization a shared language for debt severity. Without it, one developer's "critical" is another's "nice to have." Use these four priority levels to create consistency across teams.
Critical - Fix Within 24 Hours
Active security vulnerabilities, data loss risks, system stability threats
P1 debt poses immediate risk to security, data integrity, or system availability. These items bypass normal sprint planning and get addressed immediately. Examples: unpatched known vulnerabilities, memory leaks causing production outages, authentication bypass bugs, data corruption risks.
Decision Criteria
- Is there a known exploit in the wild?
- Could this cause data loss or corruption?
- Does this affect system availability?
- Does this violate compliance requirements?
Response
- Drop current sprint work immediately
- Assign senior engineer as owner
- Daily status updates to leadership
- Post-mortem after resolution
High - Fix Within Current Sprint
Significant developer productivity impact, growing risk, blocking improvements
P2 debt causes measurable harm to developer velocity or system reliability. These items go into the current or next sprint. Examples: flaky test suites causing false failures, build times over 10 minutes, outdated dependencies with known bugs, missing monitoring for critical paths.
Decision Criteria
- Does this slow down multiple developers daily?
- Is the risk increasing over time?
- Does this block planned improvements?
- Are workarounds creating more debt?
Response
- Add to current or next sprint backlog
- Assign owner and estimated effort
- Track in weekly standup
- Escalate to P1 if risk grows
Medium - Fix Within Quarter
Noticeable friction, increasing maintenance cost, architectural drift
P3 debt causes ongoing friction without immediate crisis. These items get scheduled within the current quarter. Examples: inconsistent coding patterns across modules, outdated documentation, missing integration tests, deprecated API usage that still works but will eventually break.
Decision Criteria
- Does this cause recurring friction for developers?
- Is the maintenance cost growing gradually?
- Does this contribute to architectural drift?
- Will delaying make the fix significantly harder?
Response
- Add to quarterly planning backlog
- Assign owner for scoping and estimation
- Review in monthly debt review meeting
- Bundle with related work when possible
Low - Track and Revisit
Minor friction, cosmetic issues, nice-to-have improvements
P4 debt is real but not urgent. These items get tracked in the debt register and revisited quarterly. Some will get bundled with related work. Some will be promoted to P3 if conditions change. Some will be closed as no longer relevant. Examples: minor code style inconsistencies, slightly inefficient queries that perform fine at current scale, old TODO comments.
Decision Criteria
- Is the impact minimal at current scale?
- Would the fix be a "nice to have"?
- Is the current state functional and safe?
- Can this be addressed opportunistically?
Response
- Add to debt register for tracking
- Revisit quarterly during debt review
- Promote to P3 if conditions change
- Address opportunistically alongside related work
Capacity Allocation Policy
The 20% rule is the industry standard: allocate 20% of engineering capacity to technical debt reduction. The challenge is not the number - it is making the allocation stick. Here are three models that work in practice.
Time-Boxed Model
Every Friday is Debt Day
One dedicated day per week for debt work. Developers pick from the prioritized debt backlog and focus exclusively on paying it down. No feature work, no meetings, no distractions.
Pros
- Simple to implement and track
- Creates a ritual and rhythm
- Developers look forward to it
Cons
- Large debt items do not fit in one day
- Context switching on Monday morning
- Easy to cancel when deadlines loom
Story-Based Model
2 Debt Stories Per Sprint
Include a fixed number of debt stories in every sprint alongside feature work. Debt stories are sized, estimated, and tracked like any other work. They go through the same review and deployment process.
Pros
- Integrates into existing sprint workflow
- Can handle multi-day debt items
- Visible in sprint metrics and burndowns
Cons
- Debt stories get deprioritized under pressure
- Requires product owner buy-in
- Estimation of debt work is often inaccurate
Rotation Model
Debt Champion Rotates Weekly
One developer per week is the "debt champion" - their primary focus is debt reduction while the rest of the team works on features. The role rotates so everyone shares the responsibility and builds context across the codebase.
Pros
- Deep focus on debt without distraction
- Spreads knowledge across the team
- Can tackle large items in a single week
Cons
- Requires team size of 5+ to be practical
- Onboarding to unfamiliar debt takes time
- Can feel isolating for the champion
Debt Inventory & Tracking
A debt register is the single source of truth for all known technical debt. Without it, debt is invisible - scattered across TODO comments, Slack messages, and individual memories. Here is what to track and how to maintain it.
What to Track in Your Debt Register
Description
What is the debt? Clear, specific description that someone unfamiliar could understand.
Category
Code debt, architecture debt, test debt, infrastructure debt, documentation debt, dependency debt.
Severity (P1-P4)
Classification using the priority system defined above. Review quarterly for re-classification.
Estimated Cost to Fix
T-shirt sizes (S/M/L/XL) or story points. Refine estimates when items enter sprint planning.
Affected Systems
Which services, modules, or components does this debt impact? Helps prioritize by blast radius.
Age
When was this debt first identified? Aging debt often indicates a governance failure or incorrect prioritization.
Owner
Who is responsible for this item? Unowned debt is invisible debt. Every item needs a name attached.
Tracking Integration
Link to Jira, Linear, or GitHub issue. Debt not in your issue tracker does not exist in practice.
For detailed guidance on quantifying and measuring your debt inventory, see our Measuring Technical Debt guide with metrics, formulas, and dashboard templates.
The Exception Process
Any policy strong enough to be useful will occasionally be wrong for a specific situation. If there is no way to say so formally, teams will simply ignore the policy quietly instead - and you lose both the standard and the visibility. A working exception process is what keeps governance honest, and the volume of requests is one of the most useful signals you have about whether the rules are right.
What a Request Must Contain
- - The specific rule being waived, quoted, not paraphrased
- - The business reason, and what happens if the exception is refused
- - An expiry date - no exception is ever granted indefinitely
- - The compensating control that reduces risk while it is in force
- - A named owner accountable for closing it, not a team name
- - A register entry, so the exception is tracked like any other debt
Who Approves What
- - Up to one sprint: the tech lead, recorded but not escalated
- - Up to one quarter: the engineering manager, reviewed monthly
- - Beyond one quarter: VP Engineering, with a written remediation plan
- - Anything touching compliance obligations: never at team level
- - Renewals count as new requests and need fresh justification
- - Turnaround target of days, not weeks, or the process gets bypassed
Read the Volume, Not Just the Requests
A steady trickle of exceptions means the policy is roughly right and people are engaging with it. A flood against one specific rule means that rule is wrong - fix the rule rather than approving the same waiver forty times. Near-zero requests are not a success either; they usually mean teams have found it easier to route around the process entirely. Track expired-but-still-open exceptions as a first-class number in the monthly report, because that is where a governance framework quietly stops being enforced.
AI-Assisted Development Is Governed Separately
AI-generated code carries a different risk profile from human-written code, and the controls it needs - approved tool lists, acceptable use rules, approval gates tiered by code sensitivity, provenance and audit trails, and intellectual property review - do not fit inside a general debt policy. They are covered in full on the canonical page rather than summarised here, so there is one place to maintain and one place to cite.
Read the AI Coding Governance Framework for the layered controls, policy templates, rollout phases, and governance metrics. For what changes in a pull request, see Managing AI Code Quality at Scale.
Reporting & Accountability
Governance without reporting is governance without teeth. Regular reporting creates visibility, drives accountability, and gives leadership the data they need to support debt reduction efforts.
Monthly Debt Reports for Leadership
A one-page monthly report showing: total debt items by priority, debt resolved this month, new debt introduced, aging items that need attention, and capacity utilization versus the 20% target. Keep it visual - charts and trends, not spreadsheets.
Key metrics: Debt count by severity, items resolved vs. introduced (net change), average age of open items, capacity allocation vs. actual usage.
Quarterly Debt Reviews
A deeper quarterly review with the engineering leadership team. Re-classify debt items, assess whether the capacity allocation is sufficient, review the effectiveness of governance processes, and adjust policies based on what is working and what is not.
Agenda: Debt trend analysis, reclassification of aging items, capacity model assessment, policy adjustment proposals, team feedback review.
Annual Debt Audit
A comprehensive annual audit of the entire debt register and governance process. Review every open item for relevance, validate the classification system, assess governance effectiveness across teams, and set debt reduction goals for the coming year.
Deliverable: Annual debt health report with year-over-year trends, ROI of debt reduction efforts, and strategic recommendations for the next year.
Ownership and Escalation
Every debt item needs an owner. Ownership does not mean the person fixes it - it means someone is accountable for tracking progress and escalating if needed. Define escalation paths: P4 items aging past 6 months escalate to the tech lead. P3 items aging past one quarter escalate to the engineering manager.
Escalation path: Owner (tracks) -> Tech Lead (unblocks) -> Engineering Manager (resources) -> VP Engineering (strategic decisions).
Governance Anti-Patterns
Governance can fail in both directions - too much process that stifles teams, or too little that provides no real structure. Watch for these four anti-patterns that undermine even well-intentioned governance programs.
Too Much Process
Symptom: Every debt item requires a committee review, three levels of approval, and a business case document before anyone can fix a typo in a variable name.
Fix: Right-size process to severity. P4 items need a ticket and an owner. P1 items need a committee. Everything in between should be handled by the team with lightweight tracking.
Too Little Structure
Symptom: The debt policy says "teams should address debt regularly" without defining how much capacity, what classification to use, or how to track progress. Everyone interprets it differently.
Fix: Define specific capacity percentages, a classification system, and a tracking mechanism. Vague policies produce vague results. Be concrete about expectations.
Governance Theater
Symptom: Monthly reports get generated, dashboards exist, and meetings happen - but nothing changes. The debt register grows, capacity allocation gets raided for features, and reports go unread.
Fix: Tie governance to real decisions. Reports should drive action items. If a metric worsens, there must be a response. If nobody reads the reports, simplify them or stop generating them.
Blame-Oriented Governance
Symptom: Debt reports are used to assign blame. Teams that report more debt get criticized. The result: teams stop reporting debt, and the invisible debt grows unchecked.
Fix: Treat debt discovery as a positive contribution. Teams that identify and track debt are being responsible, not negligent. Celebrate transparency and reward debt reduction, not debt concealment.
Implementation Roadmap
Rolling out governance in phases prevents overwhelm and builds momentum. Each month adds a layer of capability. By month 6, you have a mature, self-sustaining governance framework.
Month 1: Inventory and Classify
Build your initial debt register
Survey all teams to identify known debt. Compile the initial debt register with descriptions, categories, and preliminary severity classifications. Do not try to fix anything yet - the goal is visibility.
Activities
- Team-by-team debt identification sessions
- Compile initial debt register in Jira/Linear
- Apply P1-P4 classification to all items
- Assign owners to every item
Deliverables
- Complete debt register with all known items
- Classification guide document
- Baseline metrics (total debt, severity distribution)
Month 2: Set Capacity Policy
Establish and protect debt reduction capacity
Choose and implement your capacity allocation model (time-boxed, story-based, or rotation). Get leadership sign-off on the 20% commitment. Start executing against the prioritized debt backlog.
Activities
- Select capacity allocation model
- Get leadership approval for 20% allocation
- Begin executing against P1 and P2 items
- Track capacity utilization from day one
Deliverables
- Capacity allocation policy document
- Leadership sign-off on capacity commitment
- First sprint with debt capacity included
Month 3: Reporting Cadence
Establish regular reporting and accountability
Set up the monthly reporting cadence. Create dashboards showing debt trends. Hold the first quarterly debt review meeting. Build the feedback loop that keeps governance alive and responsive.
Activities
- Create monthly debt report template
- Build debt tracking dashboard
- Hold first quarterly debt review
- Define escalation procedures
Deliverables
- First monthly debt report
- Debt tracking dashboard (live)
- Quarterly review meeting minutes
Months 4-6: Refine and Automate
Mature the framework based on real experience
Use the data from the first three months to refine your approach. Automate what you can - debt detection in CI, report generation, classification suggestions. Adjust the capacity model based on actual results. By month 6, governance should feel like a natural part of your workflow, not an add-on.
Activities
- Add automated debt detection to CI pipeline
- Automate monthly report generation
- Adjust classification criteria based on experience
- Expand governance to include AI-specific policies
Deliverables
- Automated debt detection rules in CI
- Refined governance policy v2.0
- 6-month effectiveness report
- Goals and roadmap for the next 6 months
Frequently Asked Questions
Start with the pain points teams already feel. Show them governance solves real problems like inconsistent prioritization, endless debates about what to fix next, and technical debt that never gets addressed. Co-create policies with team leads rather than imposing them top-down. Pilot with one team, prove the value with concrete metrics, then expand. Teams adopt governance when they see it makes their work easier, not harder.
Track four key metrics. Debt age trend: is old debt getting addressed or aging indefinitely? Capacity utilization: is the 20% allocation actually being used or getting raided for features? Defect escape rate: are debt-related bugs reaching production less often? Developer satisfaction: does the team feel the process helps rather than hinders? If all four are trending positively, governance is working. See our Measuring Technical Debt guide for detailed metrics.
The industry standard is 20% of engineering capacity. Some teams need more during catch-up periods and less once debt is under control. The allocation holds only when it is written into policy and defended by whoever owns the roadmap, not renegotiated each planning session. When debt capacity is guaranteed, teams stop hoarding technical shortcuts because they know they will have time to address them. Start with 20%, measure the results, and adjust based on your specific situation.
Build Your Governance Framework
Governance is the foundation. Combine it with AI-specific policies, management buy-in, and measurement to make debt reduction sustainable.