It builds up quietly, it doesn't show on any board, and it comes due at the worst possible moment, usually when the technology the team never had time to learn becomes the technology the roadmap now depends on.
The same note turns up in audit after audit. A team is building on a framework the way it was used three years ago, unaware of the features that would have saved them months. Nobody was careless. There was simply never a week quiet enough to read the release notes.
That pattern has a name, and the name is not ours. Cat Hicks, who researches the psychology of software teams, calls it learning debt, and she has the study behind it: engineers ramping up on unfamiliar codebases in places where learning was tolerated at best and quietly penalised at worst. Her most uncomfortable finding is the one worth repeating. A team carrying learning debt looks highly productive, because the cost lands somewhere no dashboard is pointed at.
What we can add is the view from outside. Ten years of technical due diligence, more than 180 teams, all of them examined from the position an investor sits in rather than the one the team sits in. That angle is strange and useful in equal measure, because you notice what a team has stopped noticing about itself. Learning debt is among the clearest of those, and almost nobody puts a price on it.
The trade nobody decides to make
No founder sits down and decides their engineers will stop learning. It happens through a thousand individually reasonable choices. There's a deadline this sprint, so the conference gets skipped. There's a customer about to churn, so the engineer who wanted to properly understand the new framework wires it in from a tutorial instead and moves on. The problem is, there will always be a next thing, and learning is the one item on the list with no deadline attached, so it's the one that always gets put on the back burner.
Each of those decisions is defensible in isolation. Delivery is urgent and visible; the business depends on it. Development is important and invisible, and urgent beats important every single time, particularly when there's no structure protecting the important thing. This is the same dynamic that produces technical debt, playing out within the team rather than the codebase. Learning is simply what is left over when shipping has taken everything.
How the interest compounds
Learning debt has a nasty property: the less slack a team has, the harder it becomes to create any. A team that has fallen behind on its skills is slower at everything, under more delivery pressure, and left with even less room to catch up. The gap widens on its own.
It shows up in concrete ways during an audit. In around half the teams we assess, there is no protected time or budget for learning at all. A team using a framework as it was used three years ago, unaware of the features that would have saved them months. Adding security risks to the code. Patterns copied forward long after the reason for them expired. An architecture chosen because it was the only one anyone on the team knew, not because it fit the problem. And the quiet one: capable engineers who haven't genuinely stretched themselves in two years and are starting to feel it, which links straight back to why they'll eventually leave. Learning debt and retention risk are the same problem seen from two angles.
The AI shift makes this sharper than it has ever been: a team with no slack to absorb a monthly change in tooling falls behind at the speed the field moves.
What a buyer is really assessing
When an investor or acquirer evaluates an engineering team, the thing they care about most is not the current skill set. It's the rate of change. Can this team learn what the roadmap will require of them? Because the roadmap always requires something the team can't do yet, that's what a roadmap is.
A team carrying heavy learning debt is a team whose answer to that question is no, or not without help you'll have to pay for. It can execute what it already knows, but stalls the moment the plan requires a capability it never had room to build. From the outside, that caps the company's ceiling at the current team's knowledge. A team that's visibly still learning, by contrast, is one that can grow into whatever the business becomes.
In a technical due diligence, the current skill set is the easy thing to inventory. The rate of change is what we are there to judge, and learning debt is where it hides.
Making room without pretending
The fix is not a mandate to learn, and it is certainly not the classic "20% time" that gets quietly reclaimed by delivery within a month. It is to make development a protected, scheduled thing that delivery is not allowed to raid, and to defend it when the deadline comes. The structural side of that, protected time and growing skills in-house, and the case for learning tied to real work rather than abstract training, we have made elsewhere. The signal that matters is what gets cut first when things get tight. If it is always learning, the team has already decided the real priority, whatever the stated one is.
The debt you can't see in the code
Technical debt is the shortcut you can see, sitting in the code, waiting to be paid down. Learning debt is the shortcut you can't see. It sits in your team, compounding in silence while everything looks fine because the features keep shipping. A team that always chooses delivery over development looks maximally productive right up to the day the work requires something they were never given the room to learn. By then, the debt isn't a line item. It's the ceiling on everything the company can still become.
