EM: People Management

What is your approach to managing technical debt within a team?

By Interview Clozo · Published 27 October 2026 · Last verified 26 October 2026 · 11 min read

What is your approach to managing technical debt within a team? Record every item in the backlog, price it in extra days per change, and pay down only the debt that sits in code the team keeps changing. Technical debt is the cruft earlier shortcuts leave in code; its interest is the extra effort each later change costs. The next question an interviewer asks is which debt you will deliberately leave unpaid, and why.

In this article

Before you start
Why interviewers ask this
Technical debt management from first principles
The Staff-level answer
The rubric
Three variants of this question
Common mistakes
Follow-up questions
Sources

Before you start

This page is one answer in the engineering manager interview questions guide, which maps the whole loop.

Why interviewers ask this

A vague answer to the technical debt question tells an interviewer that your team's speed will either decay slowly or stall under endless cleanups. Candidates report this question in engineering manager (EM) loops, usually as a test of judgment rather than of coding knowledge.

The question separates people who treat debt as a feeling from people who treat it as a cost they can see and trade. A weak answer says "we refactor when we can" or "we never let it build up." A strong answer names how debt becomes visible, how you compare it with feature work, and what you refuse to fix. It also shows how you talk to product partners, which connects it to your management philosophy and to the wider people management round. A Staff-level answer adds the boundary: some debt is never repaid, and saying so openly is part of managing it.

Technical debt management from first principles

Technical debt: Technical debt is a metaphor, coined by Ward Cunningham, that frames the cruft left by earlier shortcuts in code or design as a financial debt: the shortcut is a loan, the cleanup is the repayment, and the extra effort every later change costs is the interest.
Debt interest: Debt interest is the extra effort each new change costs because of existing cruft, counted here in extra days per change. It is paid again on every change that touches the affected code, whether or not anyone repays the original loan.

In plain words

Think of a credit card balance. Buying now gives a benefit today and leaves a balance, and interest is added while it stays unpaid. A shortcut works the same way: it speeds up this release, and later changes cost more.

The analogy breaks in two places: no statement shows the exact balance, and some debt is taken on unknowingly, because people learn as they build.

Fowler's quadrant uses two axes. Prudent or reckless asks whether the choice was sound for what the team knew; deliberate or inadvertent asks whether the team knew it was taking on debt. Prudent debt is debt a sensible team would accept given what it knew, either chosen on purpose to ship earlier (deliberate) or discovered once the team learnt the better design (inadvertent). Reckless debt is debt that comes from ignoring good design or not knowing it. The two axes give four cells. Fowler notes that "while you're programming, you are learning."

In one precise sentence: managing technical debt means making its cost visible, then spending team time where that cost is highest.

Step 1: Record each item and price it in days

A team manages technical debt by recording each item in the backlog and giving it two prices in days. Developers already capture debt this way: in the Software Engineering Institute (SEI) study of issue trackers, the most common practice survey participants reported was using issue trackers or existing backlog practices to capture and track debt. The same study found 109 debt examples among 1,246 issues from four trackers, about 8.7% of them, so debt hides among other work unless it is labelled.¹ The SEI's report to Congress lists recording debt items and a culture where developers disclose debt as practices.

A debt register is a tagged list of debt items in the backlog, each with a cost to fix and an interest estimate. Fowler's own example prices a feature at 4 days with a clean structure and 6 days with the cruft. The 2 extra days are the interest, and the 5-day cleanup is the principal, which is the cost of paying the debt itself off.¹ Your estimates will be rough. A rough number in days still beats an argument about taste.

Step 2: Decide which debt to leave unpaid

A team pays first the debt in code that changes often, and leaves rarely touched debt alone. Interest is charged per change, so code nobody edits charges almost nothing, however ugly it looks. Break-even shows why: the cleanup costs 5 days and saves 2 days per change, so it breaks even at 2.5 changes, meaning the third change that touches the module.¹ The SEI report says it will never be possible to address 100 percent of technical debt, so a team needs a prioritization scheme and should map debt to rework costs. The table applies this to three illustrative items; the figures are assumptions, not measurements.¹

In this illustrative example the payments module repays its cleanup in about half a quarter, while the legacy report module never does, so the team pays the first and leaves the last.
Debt item (illustrative)	Fix cost (days)	Interest per change (days)	Changes per quarter	Payback (quarters)	Net days over four quarters
Payments module	5	2	6	0.42	+43
Build scripts	8	0.5	4	4	0
Legacy report module	10	3	0.25	13.33	-7

The build scripts net zero over four quarters, the break-even case: revisit them when their change rate or interest moves. Leaving the last item unpaid is a decision, not neglect. Write it down with a trigger that reopens it, such as "revisit if this module starts changing monthly."

A five-day cleanup that saves two days per change pays for itself at the third change that touches the code.CC BY 4.0 — source: What is your approach to managing technical debt within a team?

Text description of the diagram

Cleaning first costs 9 days at the first change against 6 days when leaving the cruft.
By the third change cleaning first costs 17 days against 18 days.

The chart restates the break-even. Cleaning first costs 9 days at the first change against 6 days when leaving the cruft, and 17 days against 18 days by the third change.¹

Step 3: Reserve capacity and review it every sprint

A team keeps debt work moving by reserving a share of each sprint for it and reviewing the register at every planning session. The SEI report advises reviewing debt as part of both iteration planning and risk management, and making debt management part of the normal process. A reserved share stops debt from losing every argument against a feature.

The size of the share is your call. As an illustrative assumption, a team of 6 engineers with a 10-day sprint has 60 engineer-days, so a 15% share is 9 days and a 20% share is 12 days.¹ No cited source sets a right share, so present yours as a starting point you adjust.

Agree the share with your product partner before the sprint, and report results in days of interest removed. Engineers disclose debt when it is safe to say so, and regular one-on-ones are where that starts. A cleanup is also a good chance to grow engineers by letting them own a design decision.

Debt management is a flow: make debt visible, price it, choose what to leave unpaid, then protect capacity and review.CC BY 4.0 — source: What is your approach to managing technical debt within a team?

Step-by-step description

Debt items go into the backlog with a cost in days.
Pay first where the code changes often.
Reserve sprint capacity and review each planning session.

A team records each debt item in the backlog and prices it in days.
A team pays first the debt in code that changes often.
A team reserves a share of each sprint and reviews the register at every planning session.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.