The Short Answer
Technical debt isn't measured by code quality but by the cost it imposes on future changes. Therefore, prioritization isn't about "what's ugliest" but what makes the next piece of work most expensive.
The quickest sorting rule: An item that causes every change in its vicinity to require extensive regression testing goes first. It multiplies the cost of every other activity in your plan.
Scoring Across Four Dimensions
| Dimension | Question | Weight |
|---|---|---|
| Business Exposure | What happens if this fails at peak load? | High |
| Frequency | How many times a day is this touched? | High |
| Dependency | How many other areas are blocked because of it? | Medium |
| Effort | How much does it cost to fix in a controlled environment? | Inverse |
Scoring isn't an exact science. Its true value lies in forcing an explicit conversation between those who understand the technical risk and those who feel the business pain – creating an order that can be defended to management.
Three Types of Debt That Jump the Queue
Regardless of the score, three types always come first:
- Debt that blocks testing – The absence of a proper Sandbox environment or test data. Any other fix made without it is done in the dark.
- Permissions debt – A visibility model that has lost all logic is an active regulatory exposure, not an inconvenience.
- Debt concentrated in one person – When only one person understands a component, the risk is organizational, not technical.
How to Present Debt to Secure Budget
Management doesn't fund "clean up automations." They fund reduced time and cost. The translation is done in three lines for each item: how many support hours it consumes per quarter, how many days it adds to every change in its area, and what the exposure is if it fails.
Someone who presents "three change requests per quarter, each extended by two weeks due to the same component" gets approval. Someone who presents a dependency diagram does not.
A Fixed Quota, Not a One-Time Event
The failed pattern: A big cleanup project every two years. The working pattern: A fixed quota of 15%-20% of each wave dedicated to debt, determined in advance and non-negotiable every sprint.
Alongside the quota, at least one prevention rule is required – for example, prohibiting the addition of new automation to an object that already has several, before consolidating them. Without prevention, the rate at which debt is created outpaces the cleanup rate. The connection to development infrastructure is detailed in Salesforce Sandbox and DevOps Strategy.
Summary
Prioritizing technical debt is an exercise in economics, not aesthetics: fix what makes the next change more expensive, address what blocks testing and what creates exposure, and establish a quota to prevent recurrence. A ranked list of ten items is worth more than a mapped list of one hundred.