Quick Navigation
- Start here — What technical debt is
- Types of debt
- The cost of debt
- Legacy systems
- Rationalisation strategies
- Prioritising debt reduction
- The politics of technical debt
- Debt interest rate
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
All systems accumulate technical debt. The question isn't whether you have debt — you do. The question is whether you're managing it or ignoring it. Ignored debt compounds — every change becomes slower, riskier, and more expensive until the system becomes legacy, where change isn't just slow but dangerous. I've seen leadership ask why delivery is slowing while keeping the same number of engineers. The answer is always debt — invisible, unmanaged debt.
Technical debt is the accumulated cost of shortcuts, outdated decisions, and deferred maintenance. Rationalisation is the disciplined process of reducing it — through modernise, replace, retire, or tolerate decisions — before it becomes unmanageable.
Not all debt is bad. Sometimes taking on debt is a deliberate, time-limited choice — ship fast now, pay later. The problem isn't debt itself — it's unmanaged debt. Debt you don't track, don't prioritise, and don't plan to repay.
Keep it in mind.
1. What technical debt is — And why the metaphor is useful and limited
The term "technical debt" is used loosely — sometimes for any code the team doesn't like, sometimes for any system older than two years. Without a clear definition, debt becomes a catch-all complaint rather than a manageable category.
Technical debt has a specific meaning — it's the cost of rework caused by choosing an expedient solution now instead of a better approach that would take longer. Like financial debt, it accrues interest — the longer you wait to address it, the more expensive it becomes.
flowchart LR
FAST["⚡ Expedient Solution\nFast now"] --> DEBT["📉 Technical Debt\nCost of rework\nAccumulates over time"]
DEBT --> INTEREST["📈 Interest\nEvery change becomes\nslower and riskier"]
INTEREST --> LEGACY["💀 Legacy\nChange is dangerous\nNot just slow"]
Where the metaphor works: Debt accumulates — just like financial debt. Debt has interest — the cost of not paying it grows over time. Debt can be deliberate — taking on debt strategically can be the right choice. Debt must be repaid — eventually, the interest becomes unsustainable.
Where the metaphor breaks: Technical debt doesn't have a clear interest rate — it's hard to quantify precisely. Technical debt isn't always visible — unlike financial debt, it hides in the code. Technical debt isn't fungible — you can't "pay down" any debt with any effort. Different debts have different urgency — some are critical, some are tolerable.
The technical debt quadrant (Martin Fowler): Deliberate + Prudent — "We know it's not ideal but the trade-off is acceptable." Acceptable — plan to repay. Deliberate + Reckless — "We don't have time for design." Dangerous — high interest. Inadvertent + Prudent — "Now we know how we should have done it." Normal — learning debt. Inadvertent + Reckless — "What's layering?" Preventable — education gap.
Debt = cost of expedient choices — useful metaphor, but know where it breaks down.
Try it yourself — The debt check
What kind of debt does your team carry?
| Quadrant | Example from your team | Managed or ignored? |
|---|---|---|
| Deliberate + Prudent | ||
| Deliberate + Reckless | ||
| Inadvertent + Prudent | ||
| Inadvertent + Reckless |
If you can't name examples, your debt is invisible — and that's the most dangerous kind.
2. Types of debt — Deliberate, accidental, bit rot, and architectural
Not all debt is the same. A missing test is different from a wrong architecture. A deprecated library is different from a shared database. Treating all debt the same leads to wrong priorities.
Four types of debt require different management approaches:
flowchart TD
DEBT["📉 Technical Debt"] --> DEL["🎯 Deliberate\nConscious shortcut\nPlanned repayment"]
DEBT --> ACC["🐛 Accidental\nUnintended consequence\nDiscovered later"]
DEBT --> ROT["🦴 Bit Rot\nTechnology ages\nSupport ends, versions stale"]
DEBT --> ARCH["🏗️ Architectural\nWrong boundaries\nStructural problems"]
DEL --> MANAGE["Manage: Track and\nplan repayment"]
ACC --> MANAGE2["Manage: Refactor\nwhen discovered"]
ROT --> MANAGE3["Manage: Upgrade\non schedule"]
ARCH --> MANAGE4["Manage: Restructure\nstrategically"]
The four types:
| Type | What it is | Example | Management |
|---|---|---|---|
| Deliberate | Conscious shortcut with planned repayment | "We'll skip caching for MVP" | Track in backlog; repay before interest grows |
| Accidental | Unintended consequence discovered later | "The data model doesn't support this use case" | Refactor when discovered; document learning |
| Bit rot | Technology ages — support ends, versions stale | "We're on Java 11; Java 17 is current" | Upgrade on schedule; track support end dates |
| Architectural | Wrong structural decisions — boundaries, coupling | "Two services share a database" | Restructure strategically — highest cost, highest value |
Detailed taxonomy: Code debt — duplicated code, complex methods, missing tests. Detected by code analysis, test coverage. Medium cost — slows development. Design debt — wrong abstractions, tight coupling, god classes. Detected by architecture review, coupling analysis. High cost — limits change. Architecture debt — wrong boundaries, shared databases, missing patterns. Detected by architecture assessment. Very high cost — requires restructuring. Infrastructure debt — manual processes, outdated environments, no IaC. Detected by operational review. Medium cost — slows delivery, increases risk. Documentation debt — missing or outdated docs, tribal knowledge. Detected by onboarding feedback. Low-medium cost — slows onboarding. Process debt — missing reviews, no CI/CD, manual testing. Detected by process audit. Medium cost — quality and speed impact. Knowledge debt — key-person dependencies, no cross-training. Detected by team assessment. High cost — risk when people leave.
The debt register:
| ID | Type | Description | System | Impact | Interest | Priority | Owner |
|---|---|---|---|---|---|---|---|
| TD-001 | Architectural | Orders and Payments share database | Ordering Service | High — schema changes break both | Growing — more tables added | Critical | Domain architect |
| TD-002 | Bit rot | Running on Java 11 — EOL Dec 2024 | All Java services | Medium — security patches stop | Fixed — deadline approaching | High | Platform team |
| TD-003 | Deliberate | No caching on product search | Product Service | Low — acceptable for current load | Low — manageable until 10x | Medium | Team lead |
| TD-004 | Accidental | Customer ID format inconsistent across services | CRM, Portal | Medium — integration bugs | Growing — more integrations | High | Domain architect |
Four types — deliberate, accidental, bit rot, architectural — each needs different management.
Try it yourself — The register check
Do you have a debt register?
| Type | How many items? | Managed or ignored? |
|---|---|---|
| Deliberate | ||
| Accidental | ||
| Bit rot | ||
| Architectural |
If you don't have a register, you're not managing debt — you're carrying it blindly.
3. The cost of debt — How it slows delivery, increases risk, and demoralises teams
Leadership often doesn't see the cost of debt — because it's invisible in the short term. Features still ship. The system still runs. But the cost accumulates silently — every sprint takes longer, every deployment carries more risk, every new engineer takes longer to onboard.
Debt manifests as specific, measurable costs:
flowchart TD
DEBT["📉 Technical Debt"] --> SPEED["🐌 Slower Delivery\nFeatures take longer\nevery sprint"]
DEBT --> RISK["⚠️ Higher Risk\nMore defects\nMore incidents"]
DEBT --> COST_H["💰 Higher Cost\nMore effort to maintain\nMore infrastructure"]
DEBT --> MORALE["😞 Lower Morale\nEngineers frustrated\nHigh turnover"]
SPEED --> IMPACT["📉 Business Impact\nMissed deadlines\nLost revenue\nCompetitive disadvantage"]
RISK --> IMPACT
COST_H --> IMPACT
MORALE --> IMPACT
The compounding effect: Sprint 1: Feature takes 2 weeks (with debt). Sprint 2: Similar feature takes 3 weeks (debt slows everything). Sprint 3: Similar feature takes 5 weeks (debt compounds). Sprint 4: Feature is blocked — can't add without breaking something. Without debt: Sprint 1-4: Each feature takes 2 weeks (predictable).
Measuring debt cost: Cycle time trend — is delivery getting slower? DORA metrics — lead time for changes. Change failure rate — are more changes causing failures? DORA metrics — % of deployments causing incidents. Defect density — are more bugs appearing? Bug tracking — bugs per sprint or per release. Onboarding time — how long to become productive? HR/team data — time to first meaningful contribution. Rework rate — how much work is redoing previous work? Sprint data — % of stories that are rework.
The debt interest rate metaphor: Low debt — 5%. Small friction — a few extra hours per sprint. Medium debt — 15%. Noticeable slowdown — features take 15% longer. High debt — 30%+. Severe — most effort is fighting the system, not building features. Critical debt — 50%+. Paralysis — change is dangerous; teams afraid to touch the code.
How to frame debt for leadership: "We're currently spending 30% of engineering time working around technical debt. That's 6 engineer-months per quarter — equivalent to £X in salary. If we invest 2 engineer-months in debt reduction, we recover 4 engineer-months per quarter going forward. ROI: 200% in the first year."
Debt costs speed, risk, money, and morale — and the cost compounds over time.
Try it yourself — The cost check
What's your debt costing you?
| Metric | Current | Trend |
|---|---|---|
| Cycle time | ||
| Change failure rate | ||
| Rework rate | ||
| Onboarding time |
If the trend is worsening, your debt interest is compounding.
4. Legacy systems — What makes a system legacy and what it costs to ignore
"Legacy" is often used to mean "old." But age alone doesn't make a system legacy. A 10-year-old system that's well-maintained and easy to change isn't legacy. A 2-year-old system that nobody understands and everyone is afraid to touch is legacy.
A system becomes legacy when change has become dangerous — when the cost and risk of modifying it exceed the cost and risk of replacing it.
flowchart TD
OLD["📅 Old System\nAge alone does not\nmake it legacy"] --> ASSESS{"Is change\ndangerous?"}
ASSESS -->|"No"| HEALTHY["🟢 Healthy\nWell-maintained\nEasy to change"]
ASSESS -->|"Yes"| LEGACY["🔴 Legacy\nChange is dangerous\nHigh cost, high risk"]
LEGACY --> COST["💸 Cost of Ignoring\nIncreasing maintenance\nSecurity vulnerabilities\nTalent drain\nBlocked innovation"]
What makes a system legacy: No one understands it — original developers are gone; no documentation. Technology is unsupported — vendor no longer provides patches or security updates. Change is dangerous — every change risks breaking something unrelated. Testing is absent — no automated tests; manual regression takes weeks. Integration is brittle — connections are undocumented and fragile. Recruiting is hard — no one wants to work on this technology.
The legacy assessment scorecard:
| Dimension | Score 1 (Healthy) | Score 3 (Ageing) | Score 5 (Legacy) |
|---|---|---|---|
| Changeability | Changes deployed in days | Changes deployed in weeks | Changes take months; frequent regressions |
| Technology currency | Current, fully supported | Approaching end of support | Unsupported; security patches unavailable |
| Team knowledge | Multiple people understand the system | One or two experts | Tribal knowledge only; experts have left |
| Test coverage | >80% automated tests | 30-80% tests | <30% or no automated tests |
| Documentation | Current, accurate | Partially documented | No documentation; knowledge in heads |
| Integration quality | Documented, versioned APIs | Some undocumented connections | Point-to-point, fragile, undocumented |
Legacy = change is dangerous — not "it's old." Evaluate by risk, not by age.
Try it yourself — The legacy check
Score your most critical system:
| Dimension | Score (1-5) | Evidence |
|---|---|---|
| Changeability | ||
| Technology currency | ||
| Team knowledge | ||
| Test coverage | ||
| Documentation | ||
| Integration quality |
If your average is above 3, you have a legacy problem — not an age problem.
5. Rationalisation strategies — Modernise, replace, retire, tolerate
Once debt is identified and prioritised, you need a strategy for each item. Not all debt should be paid immediately — some should be tolerated, some should be retired, some should be replaced.
Rationalisation is the structured decision about what to do with each piece of debt:
flowchart TD
DEBT_ITEM["📉 Debt Item"] --> EVALUATE{"Evaluate\nBusiness value\nTechnical health\nStrategic fit"}
EVALUATE --> MODERNISE["🔧 Modernise\nHigh value, fixable\nUpgrade, refactor, re-platform"]
EVALUATE --> REPLACE["🔄 Replace\nHigh value, broken\nBuild new alongside old"]
EVALUATE --> RETIRE["⬛ Retire\nLow value, no dependents\nDecommission"]
EVALUATE --> TOLERATE["🟡 Tolerate\nLow value, stable\nMaintain, no new investment"]
MODERNISE --> RESULT["✅ Rationalised"]
REPLACE --> RESULT
RETIRE --> RESULT
TOLERATE --> RESULT
Rationalisation strategies compared:
| Strategy | When to use | Cost | Risk | Value |
|---|---|---|---|---|
| Modernise | System has value but needs updating | Medium | Low-medium | Preserves value, reduces debt |
| Replace | System has value but is beyond repair | High | High | New value, but migration risk |
| Retire | System has no value or dependents | Low | Low | Cost savings, reduced complexity |
| Tolerate | System is stable, low value, not worth changing | Very low | Low | Avoids unnecessary investment |
The rationalisation decision matrix:
| Business Value → | High Value | Low Value |
|---|---|---|
| Healthy Tech | 🟢 Maintain / Invest | 🟡 Tolerate |
| Ageing Tech | 🔵 Modernise | 🟡 Tolerate / Consider retire |
| Legacy Tech | 🔴 Replace | ⬛ Retire |
The Strangler Fig pattern — for replacement: Identify the most painful capability in the legacy system → Build the new implementation alongside the old → Redirect traffic to the new implementation → Remove the old implementation → Repeat for the next most painful capability.
Modernisation approaches: Re-platform — move to new infrastructure without changing code. Technology is the problem, not the design. Re-factor — restructure the code without changing behaviour. Design debt, coupling issues. Re-architect — redesign the system with new patterns. Architectural debt, fundamental problems. Re-build — rewrite from scratch. System is beyond repair; complete replacement. Re-host — move to cloud without changes. Quick cloud migration; address debt later.
Four strategies — modernise, replace, retire, tolerate — choose based on value, health, and strategic fit.
Try it yourself — The strategy check
Take your top 5 debt items. What's the strategy for each?
| Debt item | Business value | Technical health | Strategy |
|---|---|---|---|
If everything is "modernise," you're not prioritising — you're hoping.
6. Prioritising debt reduction — How to build the case and sequence the work
Not all debt must be paid immediately. Paying the wrong debt first wastes resources. Paying no debt at all lets interest compound. The art is prioritising by impact — which debt, if paid, unlocks the most value or reduces the most risk.
Debt prioritisation uses two dimensions — business impact and technical urgency:
flowchart TD
subgraph MATRIX["Debt Prioritisation Matrix"]
direction TB
HIGH_IMPACT["High Business Impact"]
LOW_IMPACT["Low Business Impact"]
URGENT["Technically Urgent"]
NOT_URGENT["Not Urgent"]
end
HIGH_IMPACT --> Q1["🔴 Pay Now\nHigh impact, urgent\nCritical — fund immediately"]
HIGH_IMPACT --> Q2["🟡 Plan for Next Cycle\nHigh impact, not urgent\nStrategic — schedule"]
LOW_IMPACT --> Q3["🟢 Pay When Possible\nLow impact, urgent\nQuick wins — do alongside"]
LOW_IMPACT --> Q4["⚫ Tolerate\nLow impact, not urgent\nMonitor — may never need paying"]
Prioritisation criteria:
| Criterion | Question | Weight |
|---|---|---|
| Business impact | Does this debt block a strategic outcome? | High |
| Technical urgency | Is the technology end-of-life? Is security at risk? | High |
| Interest rate | How fast is the cost growing? | Medium |
| Dependencies | Do other systems depend on this being fixed? | Medium |
| Effort to fix | How expensive is the repayment? | Low |
Building the business case for debt reduction: Current cost — how much is this debt costing today? (Slower delivery, higher risk, more incidents). Projected cost — how much will it cost in 6/12/24 months if not addressed? (Interest compounding). Investment required — how much effort and money to repay? Return on investment — what velocity, risk, or cost improvement will repayment deliver? Opportunity cost — what features or capabilities are blocked by this debt?
The debt reduction sequencing algorithm: All debt items → Score each item (business impact × technical urgency) → Sort by score (highest first) → Apply dependency ordering (what must be fixed before what?) → Apply capacity constraint (how much can we afford per quarter?) → Sequenced debt plan (quarter by quarter).
The 20% rule: A common heuristic — dedicate 20% of engineering capacity to debt reduction. This prevents debt from growing while still delivering features. Debt crisis — 60% feature work, 40% debt reduction. Aggressive paydown. Debt management — 80% feature work, 20% debt reduction. Sustainable maintenance. Low debt — 90% feature work, 10% debt reduction. Light maintenance.
Prioritise by impact and urgency — not by which team complains loudest.
Try it yourself — The prioritisation check
Take your debt register. Where does each item fall?
| Debt item | Business impact | Technical urgency | Quadrant |
|---|---|---|---|
If everything is in "pay now," you're not prioritising — you're panicking.
7. The politics of technical debt — Communicating debt to leadership and product
Leadership and product teams often don't understand technical debt — because it's invisible to them. Features still ship. The system still runs. Asking for time to "pay down debt" sounds like asking to slow down feature delivery for something they can't see.
Communicating debt requires translating technical concerns into business language — risk, cost, speed, and opportunity.
flowchart TD
TECH["🔧 Technical Language\n'Shared database'\n'No tests'\n'Outdated framework'"] --> TRANSLATE["🗣️ Translate\nInto business language"]
TRANSLATE --> BIZ["📊 Business Language\n'Every change risks\ncross-team outages'\n'30% of engineering time\nis rework'\n'Recruitment is blocked\nby outdated technology'"]
BIZ --> LEADERSHIP["👔 Leadership\nUnderstands the cost\nApproves investment"]
Translation guide:
| Technical concern | Business translation |
|---|---|
| "Shared database between services" | "Every database change risks breaking two teams — and we make 3 per week" |
| "No automated tests" | "Every release requires 2 weeks of manual testing — and we still find bugs in production" |
| "Running on unsupported technology" | "Security patches are unavailable — this is a compliance and security risk" |
| "Only one person understands the system" | "If that person leaves, we can't maintain or change this system for months" |
| "No CI/CD pipeline" | "Deployments take a full day and require coordination across 3 teams" |
The debt interest rate — the most powerful framing: "This debt is currently costing us 30% of our engineering capacity. That's equivalent to £X per quarter in salary. If we invest £Y in paying it down, we recover £X per quarter going forward. The payback period is Z months."
The executive one-pager for debt: Current State — 30% of engineering time is spent on rework and workarounds. 5 systems running on unsupported technology (security risk). Feature delivery velocity has declined 40% over 18 months. Investment Required — 2 engineers for 6 months (£X). Expected Return — 40% improvement in feature delivery velocity. Elimination of 3 critical security risks. Reduced recruitment friction (modern technology stack). Payback Period: 4 months.
Translate debt into risk, cost, speed, and opportunity — leadership doesn't care about "shared databases."
Try it yourself — The translation check
Take your top technical concern. How would you translate it?
| Technical concern | Business translation |
|---|---|
If your translation still uses technical terms, you haven't translated — you've just repeated.
8. Technical debt interest rate — The concept that debt compounds over time
The most powerful concept in technical debt communication is the interest rate — the idea that debt compounds. The longer you wait to address it, the more expensive it becomes. This isn't a metaphor — it's a measurable reality.
Debt interest manifests as increasing effort for each subsequent change:
flowchart TD
subgraph COMPOUNDING["Debt Compounding"]
direction LR
Q1["Q1\nFeature: 2 weeks"] --> Q2["Q2\nFeature: 3 weeks"]
Q2 --> Q3["Q3\nFeature: 5 weeks"]
Q3 --> Q4["Q4\nFeature: Blocked"]
end
subgraph MANAGED["Debt Managed (20% allocation)"]
direction LR
M1["Q1\nFeature: 2 weeks\n+ Debt work"] --> M2["Q2\nFeature: 2 weeks\n+ Debt work"]
M2 --> M3["Q3\nFeature: 2 weeks\n+ Debt work"]
M3 --> M4["Q4\nFeature: 2 weeks\nPredictable"]
end
COMPOUNDING --> RESULT_1["💀 Unpredictable\nVelocity declining\nTeams frustrated"]
MANAGED --> RESULT_2["✅ Predictable\nVelocity stable\nTeams confident"]
The interest rate concept:
| Scenario | Interest rate | What it means |
|---|---|---|
| Low debt | 5% per quarter | Small friction — a few extra hours per sprint |
| Medium debt | 15% per quarter | Noticeable — features take 15% longer each quarter |
| High debt | 30%+ per quarter | Severe — most effort is fighting the system |
| Critical | 50%+ per quarter | Paralysis — change is dangerous |
The leadership message: "Every quarter we delay paying this debt, the cost of paying it increases by approximately X%. The debt we could fix for 2 engineer-months today will cost 4 engineer-months in 6 months. Delay isn't free — it's the most expensive option."
Calculating the interest rate: Interest Rate = (Current cost of change - Baseline cost of change) / Baseline cost of change. Example: Baseline: feature took 2 weeks in Q1. Current: similar feature takes 5 weeks in Q4. Interest rate: (5 - 2) / 2 = 150% over 3 quarters = ~50% per quarter.
The compounding formula: Future Cost = Current Cost × (1 + Interest Rate)^Periods. Example: Current cost to fix: 2 engineer-months. Interest rate: 20% per quarter. Cost in 4 quarters: 2 × (1.20)^4 = 2 × 2.07 = 4.14 engineer-months. Delay doubled the cost.
Debt compounds — delay is the most expensive option. Frame it as interest rate for leadership.
Try it yourself — The interest rate check
What's your debt interest rate?
| Metric | Baseline | Current | Interest rate |
|---|---|---|---|
| Feature delivery time | |||
| Rework rate | |||
| Incident rate |
If you can't calculate it, you can't communicate it to leadership.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
DEBT["📉 Technical Debt\nShortcuts, aging, wrong decisions"] --> TYPES["📊 Types\nDeliberate · Accidental\nBit rot · Architectural"]
DEBT --> COST["💸 Cost\nSlower delivery\nHigher risk\nLower morale"]
DEBT --> LEGACY["🏚️ Legacy\nWhen change becomes dangerous"]
TYPES --> STRATEGY["🔧 Strategy\nModernise · Replace\nRetire · Tolerate"]
COST --> PRIORITISE["🎯 Prioritise\nImpact × Urgency"]
LEGACY --> COMMUNICATE["🗣️ Communicate\nRisk · Cost · Speed"]
STRATEGY --> VALUE["✅ Managed Debt\nPredictable velocity\nControlled risk\nSustainable delivery"]
PRIORITISE --> VALUE
COMMUNICATE --> VALUE
The foundation:
Debt is inevitable — unmanaged debt is the problem. All systems accumulate debt. The question is whether you track it, prioritise it, and plan to repay it. Debt compounds — delay is the most expensive option. Every quarter you wait, the cost of paying it increases. Frame this as an interest rate for leadership. Not all debt should be paid immediately — prioritise by impact and urgency. Use the rationalisation matrix: modernise, replace, retire, or tolerate. Choose deliberately. Good debt management makes change predictable. Bad debt management makes change dangerous.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Technical debt | Cost of expedient choices | Track, measure, and manage it |
| Debt types | Deliberate, accidental, bit rot, architectural | Classify for appropriate management |
| Debt cost | Speed, risk, money, morale | Measure with DORA metrics and velocity trends |
| Legacy systems | Change is dangerous, not "it's old" | Assess by risk, not age |
| Rationalisation | Modernise, replace, retire, tolerate | Decide based on value, health, and fit |
| Prioritisation | Impact × urgency | Use the matrix; don't just follow the loudest voice |
| Communication | Translate to business language | Risk, cost, speed, ROI |
| Interest rate | Debt compounds over time | Frame delay as the most expensive option |
How to know if this landed
You'll know this has landed when someone stops treating debt as a complaint and starts treating it as a manageable portfolio. Has a debt register with classified, scored, and owned items. Delivery velocity is stable or improving — not declining quarter over quarter. Legacy systems are assessed and have rationalisation plans. 20% of engineering capacity is allocated to debt reduction. Debt is communicated to leadership in business language — risk, cost, ROI. Rationalisation strategies are applied — not just identified. And debt interest rate concept is used in investment discussions.
What changes when the mental model clicks
I've run this session with an e-commerce platform with an 8-year-old monolith — 200+ tables, no module boundaries, shared database. Feature delivery had slowed from 2-week sprints to 6-week sprints over 3 years. 40% of engineering time was rework. Leadership didn't understand why delivery was slowing — "we have the same number of engineers." The gap at the start is usually not about understanding debt — it's about not making it visible.
What changes after this session:
Teams stop treating debt as invisible and start treating it as a measurable portfolio. The debt register exercise — "classify, score, own" — is always the moment things click. People stop treating legacy as an age problem and start treating it as a risk problem. Their results get better. They stop asking for time to "pay down debt" and start presenting business cases with ROI.
The interest rate exercise tends to immediately change how teams communicate with leadership. They start framing delay as the most expensive option. Their approval rates go up. They stop getting told "we don't have time for debt" when the real problem was that they hadn't quantified the cost of not doing it.
Book a Workshop
Ready to make technical debt visible, manageable, and communicable?
or
1-day workshop includes debt identification exercise — find and classify debt in your real systems, legacy assessment — score your systems for changeability, currency, and risk, prioritisation workshop — apply the impact × urgency matrix to your debt register, rationalisation strategy — decide modernise, replace, retire, or tolerate for each item, communication exercise — translate your top 5 debt items into business language, debt register creation with scoring, ownership, and sequencing, and technical debt taxonomy + rationalisation prioritisation framework + modernisation criteria.