The hidden cost of knowledge loss and how to prevent paying it

Knowledge loss becomes a business risk when critical system understanding exists mainly in the heads of a few software engineering experts. Architecture decisions, undocumented dependencies, operational workarounds, and historical context can all become difficult to recover when those people change roles or leave.

The warning signs often appear earlier. Cortex survey found that 40% of developers struggle to find the context they need [1]. When knowledge is already difficult to access, losing the people who hold it can further slow delivery, increase change risk, and make parts of the system harder to maintain. And in the age of AI-assisted engineering, it's not only people but also AI tools that accumulate—and lose—knowledge and reasoning behind the decisions.

This article shows how to measure that cost before the departure happens and what changes when the departing party is an AI agent instead of a person.

What knowledge loss looks like

Knowledge loss is usually described as a people-related risk: someone leaves, and what they knew leaves with them. The gap isn't unique to engineering: APQC's 2025 research on the "Great Retirement" found that only 8% of organizations consistently capture knowledge from departing employees, while 16% don't attempt it at all [2].

In engineering teams, key person departures also create architecture complications because senior engineers own more than code. Over years, they accumulate the mental model behind design tradeoffs, hidden constraints, integration behavior, and the reasons certain abstractions exist. Some of that reasoning is documented and easily transferred—it's known as explicit knowledge. Much of it remains tacit knowledge—built through years of experience and rarely written down anywhere. It's the tacit half that disappears with the key person.

Deloitte's research on institutional knowledge makes the same point at the organizational level: critical knowledge frequently lives in people rather than systems. When that person leaves, the code stays [3]. The judgment required to change it safely doesn’t. 

In engineering specifically, this risk of knowledge loss traces back to triggers like voluntary turnover, retirement, layoffs, internal role changes, and vendor or team transitions. The most valuable context often stays tied to specialist experience unless teams deliberately capture and transfer it through a structured knowledge transfer plan. If this transfer isn’t happening, the organization may face a pattern we at N-iX call the Knowledge Orphan [4].

The Knowledge Orphan: What departure exposure looks like in data

By Knowledge Orphan, we mean a module, subsystem, or file cluster whose last strong holder of the relevant mental model has left the organization. The code exists. The tests pass. The builds are green. The complication appears when someone needs to change the code. They often discover that the reasoning required to change it safely is no longer available.

A Knowledge Orphan often has several signals:

• The code sits in a frequently changed module with substantial downstream coupling;
• Commit history is heavily concentrated around one former contributor;
• Active engineers show little recent co-ownership of the same files;
• Pull request history shows limited review participation from current team members;
• Architecture decisions and constraints are weakly documented or disconnected from the code.

N-iX expertise in action:

For an industrial technology client facing a senior engineer's known retirement date, N-iX analysed 67,000 commits, 6,700 CI builds, and 725 pull requests to measure the exposure before the departure. The analysis found roughly 1,000 files whose architectural reasoning rested with one departing contributor, and two services in the same codebase (built by the same team) sitting at 40.9% and 9.3% propagation cost. The gap showed exactly where an interface boundary needed to go, and the retirement date set the deadline for building it.

That is where knowledge silos become measurable. Instead of treating them only as a cultural concern, engineering leaders can identify specific code surfaces where concentrated ownership intersects with high change impact. The question is what happens to the architecture, specifically and measurably, when a key contributor leaves? Most importantly, what would it cost the organization? Here's how to calculate the risk and measure the impact.

How to calculate departure exposure from engineering data

For most engineering organizations, estimating the cost of knowledge loss is not a standard part of workforce or delivery analysis. Teams may track developer productivity through frameworks such as DORA, SPACE, or DevEx, while workforce analytics covers attrition, retention, and skills gaps. What these approaches don’t show is where the loss of one person’s knowledge could make a specific part of the system more expensive or risky to change. The good news is that much of the data needed to estimate that exposure already exists in engineering systems.

A first-pass calculation uses data most engineering organizations already have. The measure is propagation cost, a metric offered by Adam Tornhill in his Your Code as a Crime Scene (2015) book: the percentage of a codebase that changes alongside a given module over a rolling window, typically 90 days [5].

The distinction that matters is that propagation cost is measured from behaviour, not from architecture diagrams. A dependency graph shows what the code declares. Commit history shows what actually changes together, including the shared build scripts, configuration files, and the undocumented contracts that no diagram captures. The second number is the one that predicts coordination cost.

The calculation has three steps:

1. Rank modules by propagation cost. Pull the last 90 days of commit history and record which files change in the same commits. Group by module. A module whose changes pull in 40% of the codebase behaves very differently from one whose changes stay inside 9%. In practice both figures turn up in the same repository, built by the same team.
2. Calculate recent contribution concentration by author. For each of those modules, look at commit history over the last 12 months and ask: what percentage of commits came from a single engineer? If one person authored 90% of the commits to a module, that is a high concentration score and a signal worth flagging.
3. Add review concentration to see whether the same engineer also dominates change validation. Commit data identifies who wrote a module. Code review data identifies who understood the tradeoffs behind it. Architectural memory lives in the review data, and the commit history does not record it. An engineer with few commits and most of the code reviews is the higher exposure, not the lower one.

Multiplying the concentration signals by propagation cost gives a single screening heuristic. Using propagation cost as a departure-risk multiplier rather than a refactoring priority is the extension N-iX developed, carrying the Tornhill's metric across from code health into workforce planning [4].

Departure exposure = (higher of contribution or review concentration) × propagation cost

Review concentration is the stronger of the two inputs. Commit data identifies who wrote a module. Code review is where the reasoning behind a change gets transferred, and the pull request is only the authorization gate it happens to pass through. When one engineer owns most of the code reviews on a module, that reasoning has been accumulating in one head, not in the team's. Above 40% review ownership by one engineer, that person holds architectural memory the team cannot reconstruct from documentation.

The logic mirrors what Deloitte recommends for institutional knowledge capture more broadly: rather than trying to document everything, score knowledge areas by business criticality and existing documentation gaps, then act on the highest-risk intersection first [3]. The same principle applies to a codebase, only with propagation cost and commit history standing in for the criticality-and-documentation heatmap.

Once you have the list of where you may have critical knowledge loss, choose the right approach to address each.

N-iX’s tips on how to manage loss of institutional knowledge in software development

Losing institutional knowledge rarely happens all at once. Usually, it shows up first in the decisions nobody remembers the reasoning for. These are the practices N-iX uses to keep project information.

Validate the ranked risks

Before acting on the ranked risks, validate them. Commit and review data are proxies, not direct measures of expertise. Someone can show up as the "sole author" simply because they did a large refactor, not because they are the only one who understands the module. Cross-check the ranked list against what engineering leads actually know, repository ownership rules, incident ownership, and architecture records to catch these false positives.

Move from key person risk management to architecture risk management

The departure-exposure score from the previous section changes what continuity planning is actually about. Continuity planning usually starts with roles, skills, and replacement availability. Attaching key person risk management practices to code surfaces and dependency structures makes that discussion more precise.

N-iX expertise in action:

For an industrial automation client working with a 15-year-old switch and no reliable record of which code variants were deployed in the field, N-iX reverse-engineered the device binaries and redesigned the solution around a defined interface boundary. While the knowledge gap came from legacy system history rather than employee departure, the architectural response was similar: reduce dependency on undocumented internal complexity by establishing clearer system boundaries.

Connect workforce planning to architecture data

The measurement methods already exist. Tornhill's Software Design X-Rays (2018) established how to read contributor concentration from author statistics, and the socio-technical research literature has studied how team structure maps onto system structure for two decades [6]. What neither line of work does is connect a specific departure to a specific architectural cost. That is the gap this method occupies, and four signals close it:

• A repository can show who changes a module;
• Code review history shows who understood the tradeoffs behind those changes;
• Dependency analysis can estimate how far changes may propagate;
• Architecture records can reveal whether a stable boundary exists.

Together, those signals answer a more useful question than "who are our key people?": If this engineer became unavailable tomorrow, which parts of the architecture would become materially more expensive or risky to change? The answer to that should influence succession planning, review rotation, documentation priorities, pairing, modularization, and refactoring investment.

Start key person risk assessment with the codebase

For critical engineering roles, answering that question means starting with the code itself: map contributor and review concentration to the modules that matter most, then check whether other engineers could safely operate them today. The highest-priority cases are the ones where one person dominates recent activity, the module has high propagation cost, and no stable interface limits how much of the system a replacement would need to understand.

That reframing helps leaders choose the right intervention. Pairing, documentation, review rotation, ownership redistribution, and interface redesign can all reduce exposure, but each addresses a different part of the risk. This approach turns a broad continuity concern into a ranked engineering backlog rather than a generic retention conversation.

N-iX expertise in action:

For a large US transportation provider, N-iX took over four business-critical platforms from a previous vendor with no documentation in place. The intervention matched the logic above: structured knowledge-transfer sessions, a centralized knowledge base in Confluence, and documented remediation procedures for each platform. This way, we turned an undocumented handover into a repeatable, low-risk transition instead of four separate Knowledge Orphans in the making.

Make the abstraction layer investment

When departure exposure is concentrated in a high-propagation-cost module, one intervention is to place a defined interface boundary between that module and its consumers.

The abstraction layer doesn’t need to capture everything the departing engineer knows. It codifies the contract the rest of the system depends on: supported inputs and outputs, invariants, failure behavior, integration rules, and stable seams for future change.

In one of the N-iX engagements, the estimated onboarding effort from field analysis was approximately:

• Without the abstraction layer before departure: About 100 developer-days to reconstruct the mental model, with higher regression exposure during the transition.
• With the abstraction layer in place before departure: About 30 developer-days to work through a defined interface with less surface area to understand immediately.
• Estimated delta: About 70 developer-days.

These figures illustrate how knowledge loss can be converted from a vague continuity concern into a time-bound engineering investment decision.

The tradeoff is straightforward to model. Compare the one-time cost of creating the boundary with the ongoing coupling cost of the current design and the estimated departure exposure. If the intervention is justified, the departure date becomes the deadline to do the work while the original expert is still available.

Managing loss of institutional knowledge gets more complex when organizations adopt AI tools that help engineers make architectural decisions.

The AI extension and knowledge loss

Human departure risk usually comes with some notice. Even a short transition can create time for handoffs, architecture reviews, open-decision capture, and targeted documentation. Agentic development changes that timescale. For continuity planning, an agent's effective notice period is measured in milliseconds.

An AI coding agent can complete a task and immediately terminate its working context. If the implementation survives but the relevant decision record doesn’t, the team faces a smaller version of the same knowledge loss issue. The code remains, but the context that shaped it may be hard to reconstruct.

This creates a structural challenge for organizations investing in agentic development: every agent session generates a Zero-Notice Departure [4]. Architectural decisions made by the agent, tradeoffs embedded in the code, constraints that shaped the implementation—none of these are accessible after the session closes unless they were explicitly documented in that session. Here's what you can do about it.

How to deal with organizational knowledge loss when you have AI coding agents

• Treat AI agent tasks as a Zero-Notice Departure. Preserve durable engineering artifacts that humans can inspect and maintain after every task run. Depending on task complexity, these can include concise decision summaries, architecture decision records for material structural choices, PR-level rationale, traceability between requirements and tests, and explicit assumptions or unresolved risks.
• Define an approach for when AI agent interactions may cause risky knowledge loss. Establish a task-complexity threshold for agentic work. Requiring an architecture decision record for a one-line formatting change creates bureaucracy. Allowing an autonomous agent to restructure a core domain module without persistent rationale creates avoidable maintenance risk. To find the middle ground, you can apply the same analytical frame: knowledge concentration, propagation cost, and departure exposure.
• Fold agent-authored concentration into the departure-exposure score. Track what percentage of a module's recent changes came from agent sessions with no attached decision record, and add that as a signal alongside contribution and review concentration. A module that's 80% agent-written with zero durable rationale is now a high-exposure module, even if no human is actually leaving.
• Require a human record owner for every module agents touch, regardless of who wrote the code. Someone accountable for explaining the module later prevents accountability from diffusing across a string of agent sessions where no single person ever held the full picture.
• Extend the abstraction layer investment to agent-heavy modules proactively. If a module will experience frequent agentic changes, place the interface boundary before that starts rather than after. The same ROI logic applies here: the contract lives in the interface instead of in a transient context window that disappears the moment a session ends.
• Gate high-complexity agentic PRs in CI on the presence of a decision record. Rather than relying on developers to remember the threshold, enforce it mechanically: a PR that modifies a high-propagation-cost module and lacks an attached ADR or decision summary fails the check automatically.
• Retain raw agent session logs as a fallback, not just the final diff. Even with a threshold in place, some sessions will fall through the cracks. Keeping the underlying reasoning trace tied to the commit hash, even unstructured, gives a team something to mine later if the structured decision record was never written.
• Use AI tools to retrieve undocumented logic that already exists. The same generative capability that risks losing an agent's reasoning after each session can also recover reasoning that was already lost from human-written legacy code. Pointing an AI coding assistant at an undocumented module to reverse-engineer its business logic and generate documentation retroactively closes existing Knowledge Orphans, even as the practices above prevent new ones from forming.

N-iX expertise in action:

For an automotive claims management platform running three undocumented legacy Java applications, N-iX used Cursor to reverse-engineer the business logic and generate comprehensive technical documentation automatically. Then, we built AI-generated integration test suites to cover the discovered use cases before migrating all three applications to .NET. The full analysis, documentation, testing, and migration were completed in three months, with gen AI accelerating delivery by 20–30%.

The intervention changes from preparing for a known exit date to creating persistence requirements at the boundary of each material agentic task.

Three checks to run before the next key departure

Before the next senior engineer leaves, run three checks:

• What is the propagation cost of the modules this engineer primarily maintains?
• What percentage of code reviews in the last six months did this engineer own?
• Is there a defined interface between those modules and the rest of the codebase?

If the first two answers show high concentration and the third answer is no, the organization already has a transition cost built into the architecture.

The 70-developer-day delta from that N-iX engagement will not apply to every system. However, the principle does: architecture work performed while the original mental model is still available can be substantially cheaper than reconstructing that model after departure. 

Every engineering organization produces traces of ownership, review, and dependency. Treating those traces as workforce-risk data makes knowledge loss visible early enough to act.

How N-iX can help you with knowledge retention

N-iX helps organizations preserve critical technical knowledge, reduce dependency on individual experts, and maintain continuity across team changes, vendor transitions, and modernization initiatives. Our knowledge retention expertise includes:

• Structured knowledge transfer. We establish documentation, onboarding materials, workshops, feedback sessions, lessons learned, and regular reviews to keep critical project knowledge circulating across the team.
• Technical documentation and knowledge base development. We create and maintain centralized repositories for architecture decisions, business requirements, operational procedures, migration processes, and other project-critical information.
• Legacy system reverse engineering. When documentation is incomplete or unavailable, our engineers analyze source code, binaries, system behavior, and integrations to reconstruct business logic and recover missing technical context.
• Knowledge recovery during project transitions. We help organizations take over undocumented or poorly documented systems by mapping their architecture, dependencies, operating procedures, and accumulated domain knowledge before further development begins.
• AI-powered documentation and knowledge extraction. We use gen AI to analyze existing systems, reconstruct business logic, and accelerate technical documentation creation when manual knowledge recovery would be time-consuming.
• AI-powered knowledge portals and assistants. N-iX builds searchable corporate knowledge platforms and conversational assistants that help teams retrieve relevant technical and organizational information through natural-language queries.
• Architecture and dependency documentation. We capture system boundaries, interfaces, dependencies, and architectural decisions so critical context does not remain concentrated in the knowledge of a small number of engineers.
• Onboarding and engineering enablement. We develop onboarding guides, technical training materials, and reusable project knowledge that help new engineers become productive without relying heavily on individual team members.
• Maintainability and ownership improvement. Through documentation, test automation, shared engineering practices, and clearer ownership structures, we reduce the risk of systems becoming dependent on undocumented expertise.

These capabilities have been applied across transportation, telecommunications, industrial automation, energy, insurance, automotive, manufacturing, and other enterprise environments. We also demonstrated them while working on cases where N-iX had to recover knowledge from undocumented legacy systems and establish processes to prevent similar gaps and knowledge silos from recurring.

N-iX expertise in action:

When a public bike-sharing operator lost its previous vendor with no documentation after a data leak, N-iX took over support with no handover. We reverse-engineered the entire back-office system and hardware integration within six months. Then, we documented it for transfer to the client's new parent company and re-architected it to remove a costly hardware dependency. That six-month reconstruction is what a Knowledge Orphan costs in practice when nobody catches the pattern early enough to prevent it.

Final thoughts

Most organizations measure the departure in salary and recruiting fees. They rarely measure what actually leaves—the mental model that made a piece of the codebase tractable in the first place. By combining contributor and review concentration with propagation cost, engineering leaders can identify where that risk sits before a departure happens. From there, documentation, shared ownership, clearer interfaces, and targeted architecture work can turn knowledge retention into a manageable engineering investment. The same principle applies to AI-assisted development, where important reasoning can disappear with every completed agent session unless teams deliberately preserve it.

Preventing knowledge loss therefore requires more than capturing information at handover. It means designing systems and engineering practices so critical context remains accessible as people, vendors, and development tools change. N-iX helps enterprises do this through structured knowledge transfer, legacy system reverse engineering, technical documentation, architecture improvements, AI-powered knowledge extraction, and project transition support. If you want to preserve critical engineering knowledge and reduce dependency on individual engineers, talk to N-iX experts, and let's find the solutions and frameworks you can adopt to ensure smooth business continuity.

FAQ

What is the loss of institutional knowledge in software engineering?

The loss of institutional knowledge is the loss of tacit technical context when people who understand a system's design decisions, constraints, dependencies, and operational history become unavailable. Documentation preserves explicit facts, while shared ownership and durable decision records help retain the reasoning required for safe change.

How can organizational knowledge loss be measured?

Map contribution and review concentration to important modules, then combine those signals with dependency or propagation analysis. The goal is a ranked view of where staff unavailability would make the architecture harder and riskier to change.

What should a key person risk assessment include for an engineering team?

It should include the assessment of code ownership, code review concentration, incident ownership, architecture decision ownership, module propagation cost, backup expertise, and interface quality. Validate repository-derived signals with engineering leads because commits don’t capture every form of technical knowledge.

How should companies reduce departure exposure before a senior engineer leaves?

Prioritize the highest-exposure modules. Rotate reviews, pair engineers on consequential changes, document non-obvious decisions, redistribute ownership, and introduce stable interface boundaries where coupling makes onboarding expensive. Complete the most valuable interventions while the departing engineer can still validate the transferred mental model.

Sources:

1. The 2024 State of Developer Productivity | Cortex
2. Navigating the Great Retirement with KM & AI | APQC
3. The $9 trillion knowledge exodus: How organizations can turn baby boomer retirements into a competitive advantage | Deloitte
4. Tereshchenko, M. Engineering Intelligence series, 2026
5. Tornhill, A. Software Design X-Rays. Pragmatic Bookshelf, 2018
6. Tornhill, A. Your Code as a Crime Scene. Pragmatic Bookshelf, 2015