Brought to you by ExecReps.ai, AI-powered executive presence coaching for teams.
Six years ago I sat in a room in Holborn talking about technical debt with two engineers. I said then that monetary debt gets documented, logged and qualified, and that technical debt is an IOU written on a post-it note. It gets lost, or forgotten, or never written down at all.
Nothing since has changed my mind. Every team I advise can tell me what their next feature is worth. Ask the same people what their debt is costing this quarter, and the room goes quiet.
"You're rushing to release new product features, while taking out a loan from your 'future self'." Aleks Ritov, writing in Product Coalition
The Borrowing Is Deliberate, the Record Is Missing
Benny Reich sets out the mechanism in the flattest possible language. Technical debt, he writes, "usually reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer."
Read that again as a finance person would. You take delivery today, you pay later, and the repayment is larger than the original saving. That is a loan with interest, agreed by people who would never call it one.
Reich then names the thing that makes debt lose every prioritisation fight it enters. "While for a regular feature you usually ask what value you will gain, for a technical debt you usually ask what value you will lose if you do not handle it."
Gain and loss are not scored the same way in any planning session I have run. A feature arrives with a revenue story and a launch date. A debt ticket arrives with a warning, and warnings lose to launches until the day they stop being warnings.
Vishal Soni is blunt about the part people get wrong in the other direction. There is, he writes, "nothing wrong in this approach of creating a deliberate tech debt" when the situation genuinely calls for it.
He is right, and this is where product people tie themselves in knots. Borrowing to hit a market window is a commercial decision, often a good one. The failure sits one step later, when nobody records what was borrowed, from whom, or when it falls due.
Terms, Schedule, and Somebody's Signature
Prateep Krishnan writes about the moment the debt bill arrives as a proposal to rewrite everything. His instruction to the product manager receiving it is one sentence long. "Try to get a list of detailed quantifiable reasons and projected quantifiable benefits from the source."
That single demand changes the conversation from faith to figures. A rewrite request without numbers is an engineer telling you they are unhappy, which matters, and is a different problem with a different fix.
Ritov goes further and gives the repayment its shape. "Put together a payment schedule. Payments need to be regular and equal."
Regular and equal is the whole trick. Irregular repayment is how debt work becomes a favour that engineering asks for, rather than a commitment the business already made.
Three writers in this archive reach for roughly the same allocation. Krishnan says "it is common to dedicate 20% of team capacity to handle tech debt or architectural improvements over time." Soni suggests you "reserve at least 15% of your sprint capacity towards fixing them gradually, and every 3-4 sprints, keep one sprint dedicated to fixing the tech debts." Joe Van Os advocates "around 20% of your time to be spent on proactively fixing technical debt, and learning."
None of the three shows any working. No sample, no study, no method, and I am not going to dress three practitioners agreeing with each other up as a benchmark. What the agreement is worth is the shape of the answer. Experienced people set the rate in advance and hold it, rather than deciding case by case while under delivery pressure.
The Bill Arrives Whether or Not You Booked It
Van Os watched this run its course on teams that thought they were moving fast. "Cutting corners on quality may lead to short-term velocity, but it also builds a mountain of technical debt that will need to be addressed at some point."
At some point is doing a lot of work in that sentence. In practice the date is chosen for you, usually by a customer commitment that turns out to be impossible inside the system you have.
I wrote in June about what a pivot costs, and debt was one line in a much longer bill. The narrower point is the one that kept nagging at me afterwards. Every other cost in that piece arrived with an invoice attached. This one never does, which is precisely why it grows in the dark.
There is a second reason the number stays invisible. Debt does not have to be repaid to disappear from your view of it, because it can simply move somewhere else in the organisation.
What I'm Hearing on the Podcast
James Charlesworth is the engineer who was in that Holborn room. He told me he had been an engineer for about fifteen years at that point, and he split the problem three ways before we got far into it.
"I mean, there's three types of technical debt, right? Technical debt that you do deliberately, which is what we've just been talking about, where you deliberately cut corners to get something out."
The other two, in his account, are the debt you take by accident when requirements change mid-build, and the debt you cannot control at all, which arrives as somebody else's API change or a security patch. Only the first one is borrowing. The register I am arguing for covers that one, and the honest version of the other two is a maintenance cost you budget for like rent.
He had also watched debt travel between teams rather than get paid off.
"So you might have one team that looks like a really high-performing team because they haven't got any tech debt, but what they're actually doing is they're passing it off to another team. They're selling their debt."
Any finance director would recognise that immediately, and would want to know who now holds the liability. In engineering it passes as a performance difference, and the team with the clean burndown gets held up as the example to follow.
Then he described what taking the loan properly sounds like, out loud, in front of the people who benefit from it.
"But you are going to have this tech debt. It's going to look like this. And in a year's time, this is what your system is going to look like unless we spend this amount of time."
That is a term sheet, delivered verbally, six years before anyone was calling it product finance. The experiment still ships in a week. What changes is that the cost lands in the room where the benefit was claimed, on the same day, in front of the same people.
So What Does This Mean for You?
Open a debt register this week and keep it to four columns. What the debt blocks, what the delay costs in money or time, who owns it, and the date it gets repaid. Anything that cannot fill all four columns is not debt you are managing, it is damage you are hoping about.
Then score those items with Reich's question rather than the usual one. Ask what the business loses each month the debt stays in place. A support burden, a release that takes an hour, an integration you cannot sell against. Those are numbers your finance team already knows how to read.
Set the repayment rate before the next crunch, because a rate agreed under pressure is not a rate, it is a concession. Fifteen or twenty per cent is where the practitioners land, and your own delivery history is better evidence than any of them.
So look at the oldest deliberate shortcut still live in your product. Who agreed to pay it back, and what has it charged you since?
Got a product story worth telling? Whether you're an exceptional talent shaping the future of product, or you've got a career journey others can learn from, I want to hear from you. Apply to be a guest on the Product Coalition podcast.
👋 Jay
Product Coalition is a reader-supported publication. Paid subscribers get every issue on the day it lands.