Every team I’ve led has carried some tech debt. Honestly, I don’t see it as a bad thing, it’s usually the trade-off you make to move fast early on. The real problem is knowing when that debt shifts from being “a cost of doing business” to being the thing that slows the whole team down.
That’s always been a tough call for me. The signs I’ve looked at are things like:
Sprint velocity dipping because engineers spend more time wrestling with code than shipping new work
Recurring bugs/incidents from the same fragile systems
Engineers telling me “everything feels harder than it should” (that one always worries me most)
Features taking longer and longer because we’re propping up old decisions
I don’t think there’s a universal metric for this. Some leaders try to quantify tech debt in story points or hours. Others look at long-term cycle time trends. I’ve even seen teams run “tech debt retros” where the devs themselves vote on which areas hurt the most.
Personally, I’ve come to think the tipping point is when tech debt consistently shows up in planning conversations. If it’s on the table every sprint, it’s probably already too much.
I’d love to hear how others here think about this.
Totally agree , debt itself isn’t the issue, it’s when it starts surfacing in every sprint conversation that it becomes a drag. For me, the team’s “this feels harder than it should” signal is the biggest red flag.
Well put. I’ve found the clearest signal is when tech debt starts shaping roadmaps instead of the other way around. That’s when it’s no longer just background noise.
tbh I feel like tech debt sneaks up on you… by the time everyone’s complaining, it’s already late. do any of you track it more proactively, like some lightweight scorecard, or is it all gut feel?