Ask Your Dev Team how they handle technical debt
Technical debt is inevitable. The question is whether your developer acknowledges it, tracks it, and plans for it — or pretends it doesn't exist.
If you’ve been reading along since the beginning, you’ve heard us talk about brownfield projects in issue 3 and maintenance in issue 4. Technical debt ties directly into both.
What is technical debt?
Technical debt is what happens when developers take shortcuts to ship faster. Sometimes those shortcuts are intentional and strategic: you cut a corner to hit a deadline, knowing you’ll come back and fix it later. Other times they’re accidental: code gets messy over time as features pile up and requirements change.
Think of it like financial debt. A little bit, managed well, is fine. It lets you move faster when speed matters. But if you ignore it, it compounds. Eventually you’re spending all your time paying interest, and every new feature takes twice as long to build.
Your developer should flag it
Here’s what matters: your developer should be proactively telling you about technical debt.
Not every piece of debt needs to be addressed immediately. That’s okay. Sometimes you need to ship the feature, hit the milestone, and move on. But the debt should be documented. It should be filed in the backlog. And it should be part of the conversation when you’re planning the next phase of work.
A good developer will say something like, “We took a shortcut here to meet the deadline. It works, but we should revisit it in the next cycle. Here’s what it’ll cost if we don’t.”
That’s professional. That’s transparent. That’s what you want.
The red flag
If your developer never mentions technical debt, run.
Every codebase accumulates technical debt. Every single one. A developer who never brings it up is doing one of two things:
- Creating it silently. They’re cutting corners and hoping you won’t notice. You will, eventually, when everything starts taking longer and costing more.
- Pretending it doesn’t exist. They either don’t recognize it, which is a competence issue, or they don’t want to have an uncomfortable conversation, which is a trust issue.
Both are dangerous for the long-term health of your product.
What to ask
- “How do you track technical debt?” Look for a real answer: a backlog, a tag in their issue tracker, a standing agenda item in planning meetings. Not a blank stare.
- “How do you decide when to address it?” Debt should be prioritized alongside features and bugs. Some debt is low risk and can wait. Some is a ticking time bomb.
- “Is technical debt included in your estimates?” If they’re estimating new work without accounting for the debt they’ll need to work around, the estimates are wrong.
- “Can you give me an example of technical debt in our project?” If they can’t point to anything, revisit the red flag section above.
Plan for it
Technical debt isn’t a failure. It’s a reality. The best teams treat it like any other work item: they identify it, document it, estimate the cost of fixing it, and schedule it when the time is right.
Your job is to make sure your developer is having that conversation with you. Not hiding it. Not ignoring it. Including it in the plan.
Expect better. Build better.