Engineers say "technical debt" and managers hear "we want time to tidy up". That is the wrong conversation. The code is not the point. The point is that some parts of the software make every change slower or riskier than it should be, and that this has a price the company is already paying.
This article shows how to describe that price on one page, in the language leadership uses to decide: hours, money and risk. If you already know how large a share of capacity to reserve, see how to set a technical debt budget per sprint and explain it to finance. This article comes one step earlier: how to make the case at all. For background on what debt is and where it comes from, see the hidden cost of technical debt.
Start from what leadership already feels
Nobody in management needs a definition. They already notice the symptoms: a small change takes weeks, the same bug returns, only one person dares to touch a certain system, a launch slips because of "something in the old part". Start the page with two or three of these, in their words. It shows you are describing their problem, not asking for a hobby.
Turn each item into hours
For every debt item, answer one question: how many hours per month does it cost us today? Count only things you can point to:
- Workarounds. A manual step that exists because the system cannot do it. Hours per week times four.
- Repeated fixes. A problem that comes back. Number of occurrences per month times the time to fix it.
- Slow changes. The extra time a typical change takes in this area compared with a clean area. Ask the team for a rough ratio and the number of changes per month.
- Waiting and coordination. Time spent asking the one person who understands it.
Multiply hours by an average hourly cost that finance gives you, so the number is not yours alone. If finance does not want to share a rate, show hours only. Hours are already enough to compare items.
Name the risk in one sentence
Hours show the cost of today. Risk shows the cost of a bad day. For each item write one sentence in the form: "If X happens, then Y, and it would take about Z to recover." Examples of X are the one expert leaving, a library reaching end of support, a certificate expiring or a peak season with ten times the usual load.
Keep the sentences plain. "The invoicing export is run by hand by one person; if they are away at month end, invoices go out late." That is clear to everyone. "The export lacks automation and has a bus factor of one" is not.
Keep the table small
Pick the three to five items that matter most. A page with twenty items looks like a complaint; a page with four looks like a plan. A simple table is enough:
| Item | Hours lost per month | Risk if left alone | Effort to fix | Confidence |
|---|---|---|---|---|
| Manual month-end export | A | One person is a single point of failure | B | Measured |
| Slow release process | C | Fixes reach customers late | D | Estimate |
| Outdated library | E | Security fixes stop | F | Known date |
The letters stand for numbers you collect from your own team. Do not fill the table with guesses presented as facts. The last column matters: marking each number as measured, estimated or a known date makes the rest of the page believable.
A worked example of the arithmetic
The example below shows only the method, with deliberately simple numbers that do not describe a real client.
Suppose a manual export takes 2 hours each week. That is about 8 hours per month. If finance gives an average cost of 40 per hour, the export costs 320 per month, or 3,840 per year. Suppose a rewrite as an automatic job would take 24 hours of work, once. Then the work pays for itself after 24 / 8 = 3 months, counting only the saved hours. The risk sentence is a bonus on top: the month-end invoices no longer depend on one person.
Change the numbers to your own and the logic stays the same: hours lost per month, one-time effort, and the time to break even. Leadership can check this in their head, which is exactly the goal.
End with one request
The page is not a report, it is a request. Finish with one decision, small and specific:
- "Reserve one day per sprint for these four items during the next quarter."
- "Approve 24 hours to automate the export before month end."
- "Let us replace the library before support ends in the spring."
Say what you will report back and when: the hours saved, measured the same way as the baseline. This is what turns a single yes into trust for the next request.
Mistakes to avoid
- Too much technical detail. Put it in an appendix for those who want it.
- Fear without numbers. One concrete risk beats five vague warnings.
- Asking for everything. A large, open-ended request is easy to postpone. A small, bounded one is easy to approve.
- Mixing debt with new features. Keep this request separate, or it will lose to the feature every time.
- No follow-up. If you do not report the result, the next request starts from zero.
What to do this week
Ask your team for their three most annoying areas of the software. For each, write the hours lost per month and one risk sentence, and mark every number as measured or estimated. Put the result in a table, add one request, and read it aloud to someone outside the team. If they understand it without questions, the page is ready.
Sources
- Our related articles linked above.
- The worked example is invented to show the method and does not describe a real client or system.