Who this is for
Technical leaders who know their systems have accumulated technical debt, but need a structured way to assess, quantify, and prioritise what to address.
Question this answers
How bad is our technical debt really, and what should we fix first?
What you'll leave with
- A four-dimension framework for assessing technical debt
- Specific checklist items for code, infrastructure, process, and knowledge debt
- A scoring model to prioritise what to address first
- How to communicate technical debt to non-technical stakeholders
What is technical debt?
Technical debt is the accumulated cost of shortcuts, deferred maintenance, and outdated decisions in your technology systems. Like financial debt, it compounds — small amounts are manageable, but unchecked accumulation eventually constrains everything you try to do.
It's not just about messy code. Technical debt includes:
- Systems running on unsupported platforms
- Integrations held together by spreadsheets and manual processes
- No documentation for why things work the way they do
- Deployment processes that require a specific person's involvement
- Security patches that never got applied because "it's too risky to change"
Every business with software has technical debt. The question isn't whether you have it — it's how much, where, and what to do about it.
Why assess it?
Most businesses know they have technical debt. What they lack is a structured view of how much, where it sits, and what to prioritise. Without this, technical debt gets addressed reactively — fixing things only when they break — which is the most expensive approach.
A structured assessment gives you:
- Visibility — everyone agrees on what the debt is and where it lives
- Prioritisation — fix what matters most, not what's most annoying
- A business case — translate technical debt into business risk and cost so non-technical stakeholders understand why it matters
- A plan — systematic reduction instead of reactive firefighting
The assessment framework
We assess technical debt across four dimensions. Each dimension has specific checklist items rated on risk (likelihood of causing a problem) and impact (severity when it does).
1. Code and architecture debt
This is what most people think of as technical debt — code quality, architecture decisions, and design patterns.
Code and architecture checklist
- Codebase has areas that developers avoid changing because they're fragile or poorly understood
- Multiple versions of the same logic exist in different places (copy-paste code)
- The application architecture doesn't support current requirements without workarounds
- Third-party libraries or frameworks are significantly out of date (2+ major versions behind)
- No automated tests exist for critical business logic
- The application is a monolith that should have been decomposed years ago
- Custom code exists where a standard library or service would work
- Database structure has grown organically with no clear schema governance
2. Infrastructure debt
The platforms, servers, and environments your systems run on.
Infrastructure checklist
- Systems run on unsupported or end-of-life operating systems or runtimes
- No disaster recovery or backup plan has been tested in the last 12 months
- Deployments require manual steps or specific individuals
- Infrastructure is not documented (server configs, network diagrams, access controls)
- No monitoring or alerting exists for critical systems
- Security patches are significantly behind (3+ months on critical systems)
- Scaling requires manual intervention (provisioning servers, increasing resources)
- Development, staging, and production environments are significantly different
3. Process and tooling debt
The tools, workflows, and practices that your team uses to build, test, and deploy software.
Process and tooling checklist
- No CI/CD pipeline — deployments are manual
- Source control is absent, outdated, or inconsistently used
- No code review process for changes to production systems
- Testing is entirely manual with no automated test suite
- Incident response is ad-hoc — no documented process for outages
- Project management and issue tracking is done in email or spreadsheets
- No consistent development environment setup (every developer has different tools/versions)
4. Knowledge debt
What people know and what's documented. Often overlooked, but one of the most dangerous types of debt.
Knowledge debt checklist
- Critical systems depend on one person's knowledge (bus factor = 1)
- No documentation exists for system architecture, APIs, or deployment processes
- Decisions about why things were built a certain way are undocumented
- Onboarding a new developer takes weeks because there's nothing to read
- The original development team or vendor is no longer available
- Business rules are encoded in code with no external documentation
- Admin credentials or API keys are held by individuals, not managed centrally
Scoring and prioritising
For each checked item, assign a score:
| Low impact | High impact | |
|---|---|---|
| Low risk | 1 — Accept it | 2 — Plan to address |
| High risk | 2 — Plan to address | 3 — Address now |
Risk = how likely is this to cause a problem in the next 12 months?
Impact = if it does cause a problem, how severe is the business impact?
Sum your scores across all dimensions. This gives you a total debt burden and, more importantly, a prioritised list of what to address first.
Common mistakes
- Trying to fix everything — some technical debt is acceptable. A stable system with outdated code comments doesn't need a rewrite. Focus on debt that creates risk or blocks capability.
- Treating debt reduction as a project — it's not. It's ongoing hygiene. Allocate 15–20% of development capacity to debt reduction as a standing commitment.
- Not involving the team — developers know where the bodies are buried. Run the assessment collaboratively with the people who work in the codebase daily.
- Ignoring knowledge debt — code debt is visible. Knowledge debt is invisible until someone leaves. Document critical systems proactively, not reactively.
- Conflating age with debt — old systems aren't automatically debt-ridden. A 10-year-old system that's well-maintained, documented, and secure has less debt than a 2-year-old system built in a rush with no tests.
Next steps
Run through the checklists above with your development team. Score each item, sort by priority, and pick the top 3–5 items to address in the next quarter.
If you'd like an independent assessment, book a technical audit with our team. We'll review your systems, quantify the debt, and give you a prioritised remediation plan — including honest advice about what to fix, what to live with, and what to replace.
Key takeaways
- Technical debt isn't just bad code — it includes infrastructure, processes, tooling, and knowledge gaps
- Not all technical debt needs to be fixed. Some is acceptable. The goal is conscious, prioritised management
- The highest-priority debt is high-risk AND high-impact — security vulnerabilities in critical systems, not outdated comments in stable code
- Use the assessment to build a business case. Translate technical debt into business risk and cost
- Schedule technical debt reduction as ongoing work, not a one-off project. 15–20% of sprint capacity is a common allocation