RDEL #81: How does learning debt impact engineering teams?

Active learning during task ramp-up is initially high, but seen as invisible work. Code reviews saw social pressure to justify decisions, rather than knowledge share with teammates.

Welcome back to Research-Driven Engineering Leadership. Each week, we pose an interesting topic in engineering leadership and apply the latest research in the field to drive to an answer.

Engineering teams depend on shared knowledge to maintain and evolve complex codebases. Yet, many developers feel isolated in their learning, struggling to extract context and hesitant to ask questions. Over time, this can cause a learning debt, or a cumulative cost of deprioritizing knowledge sharing, documentation, and mentorship in favor of short-term output. This week we ask: How does learning debt impact engineering teams, and how can leaders resolve it?

The context

Software development is often framed as a knowledge-sharing discipline. Codebases are collaborative artifacts, intended to be maintained, extended, and understood by multiple contributors over time. In this environment, learning is not just an individual activity but a team responsibility, crucial for onboarding, debugging, and long-term code quality.

However, engineers often face pressure to deliver quickly, which leads them to optimize for short-term output rather than long-term understanding. Activities essential for effective learning—exploratory debugging, asking questions, documenting decisions—are often invisible work that goes unnoticed and unrewarded. As a result, engineers operate in a cycle of "learning debt", where knowledge remains siloed, documentation is neglected, and new contributors must struggle through the same challenges repeatedly.

The research

A qualitative study of 25 full-time engineers explored their experiences onboarding to unfamiliar, collaborative codebases. Participants of the study first narrated their way through a debugging task, then completed a semi-structured interview about their overall problem-solving and learning experiences.

An overview of the top themes identified across 25 interviews

The study identified three major challenges that prevent effective learning in engineering teams:

• Active learning is undervalued: Engineers rely on hands-on exploration, mental modeling, and breaking things to understand codebases. However, this "invisible" work is often not recognized as productive, leading engineers to deprioritize or hide it.

• Code review discourages disclosure: Instead of fostering discussion and shared learning, many engineers experience code review as a performance evaluation, where they must prove competence rather than seek improvement. This discourages open conversations about problem-solving and trade-offs.

• Time pressure reinforces bad habits: Documentation, pair programming, and mentorship are frequently the first sacrifices in fast-moving teams. Engineers reported that sharing knowledge was seen as extra work rather than a core responsibility, leading to an ongoing cycle of "coding in the dark."

A high-level model of how learning debt accumulates

The application

Engineering leaders have a direct role in breaking the cycle of learning debt and fostering a culture where knowledge sharing is valued. Here are three practical ways how:

• Make knowledge work visible and rewarded: Recognize learning activities—debugging, documentation, and mentorship—as valuable contributions. Treat documentation updates as first-class deliverables, not afterthoughts.

• Decouple learning from performance evaluation: Code review should be a space for developmental feedback, not just correctness checks. Encourage engineers to explain decisions and highlight areas where they learned something new.

• Create structured time for collaborative learning: Prioritize pair programming, mentoring, and problem-solving discussions. Provide team-wide incentives for sharing knowledge instead of just delivering code.

By shifting how learning is treated within engineering teams, leaders can reduce onboarding friction, improve long-term productivity, and create a more supportive, engaged developer culture.

—

Happy Research Tuesday,

Lizzie