Speed borrowed from the future: shortcuts taken to ship fast that must be repaid later, with interest, as slower work.
Why it exists
Shipping fast often means shortcuts that make future changes slower and riskier, and if that cost stays invisible it piles up until progress stalls. Tech debt exists as the name for those accumulated shortcuts, so teams can talk about the trade-off, track it, and decide when paying it down is worth the time.
How it actually works
To ship quickly, teams sometimes take shortcuts, quick fixes, skipped cleanup, structure that no longer fits. That's tech debt. Like financial debt, it's fine in moderation and lets you move fast now, but it accrues interest: every future change in that area gets slower and riskier until it's paid down.
"Refactoring" is repaying it, reworking code to be cleaner without changing behavior, so future work speeds back up.
A senior PM walks you through it
A junior PM, stuck
I asked the engineer to add a second discount type, free delivery above a spend threshold, and it looks like a one-line change to me. He came back with a 3-week estimate. My lead is going to ask me to justify that number in planning, and right now all I can say is "the engineer said so," which is not going to hold.
That 3 weeks is not padding, it is the bill for a shortcut the team took at launch to ship the first discount on time. There is a paper trail that shows exactly what was borrowed and why the interest is coming due now, and reading it takes about two minutes. This is that trail: the launch pull request, the ticket that was meant to repay it, and this week's estimate, stitched into one view. Read it top to bottom, then take the steps with me.
Discount logic: from launch shortcut to this week's estimate
+ // TODO: generalize when we add more discount types
Rafi: shortcut ok for launch, ticket to generalize later. Approved.
The ticket that was meant to repay it
TIF-214 Generalize discount logic to support multiple types
Status: open since launch. Never picked up.
This week's request
New: add a second discount type, free delivery above 500 taka.
Estimate: 3 weeks.
Rafi: the flat 10% is hardcoded through checkout in six places. A second type means untangling all of them first, which is TIF-214.
Click a step to see the lines it points at.
Mistakes I've seen
Reading a large estimate as the engineer padding or sandbagging. Here the 3 weeks is the flat 10% hardcode wired into six places, a real cost with a paper trail, and calling it padding burns trust you will want later.
Letting the paydown ticket sit open forever. TIF-214 has been open since launch, and every sprint it stays there the shortcut spreads further, so the next feature on top of it costs even more than 3 weeks.
Accepting a launch shortcut with no ticket attached. The shortcut with TIF-214 is trackable debt; the same shortcut with no ticket is invisible debt that surfaces only as a mysteriously slow estimate months later.
Framing debt paydown to your lead as "engineering wants to clean up." Framed as "this unblocks every future discount change," it competes for roadmap space on its real value instead of sounding like optional housekeeping.
In planning, say: "The 3 weeks is not the feature, it is paying down TIF-214, a launch shortcut where the 10% discount got hardcoded into checkout in six places. If we fund that paydown, this discount type and the next one get cheap." You just defended an estimate by tracing it to the specific debt it repays, which works on any "why is this so expensive" number.
Where a PM meets this
"Everything's taking longer here" often means accumulated debt; ignoring engineers' requests for cleanup time has a compounding cost.
Balancing new features against debt paydown is a core prioritization tension you'll navigate constantly.
Hear it in a meeting
"We can ship the shortcut now, but we're taking on debt we'll pay for in Q3."