The Real Technical Debt Is Tribal Knowledge

One of the most common mistakes I've seen engineering organizations make is confusing efficiency with resilience.

The logic usually sounds reasonable. A particular engineer understands a domain better than anyone else, so work in that area naturally gravitates toward them. The authentication expert gets the authentication work. The infrastructure expert gets the infrastructure work. The payments expert gets the payments work. Sprint after sprint, this appears to be the most efficient way to operate. The work gets done faster. Fewer mistakes are made. Deadlines become easier to hit.

For a while, everyone involved can point to evidence that the system is working. Then somebody leaves.

I've been through enough startups and acquisitions to know that employee turnover is not an exceptional event. It is a normal one. People get recruited away. People relocate. People burn out. People decide they want to work on something new. Acquisitions happen. Reorganizations happen. Entire teams disappear. Every organization experiences some version of this eventually, yet many engineering cultures quietly build themselves around the assumption that key people will always be available.

The result is a form of technical debt that rarely appears on architecture diagrams or engineering roadmaps.

Knowledge debt.

One of the earliest startups I worked for had an engineer who became the de facto owner of nearly all authorization-related work. The arrangement wasn't formal. Nobody sat down and decided to make him the sole authority. It simply happened because he was good at it. He understood the domain. He solved problems quickly. He introduced fewer bugs than everyone else.

From a short-term perspective, the arrangement was hard to argue with.

If a difficult authorization problem landed in the sprint backlog, assigning it to the expert was almost always the fastest path to a solution. Every ticket reinforced the pattern. Every successful implementation justified the decision. What nobody paid much attention to was what the rest of the team wasn't learning.

The organization's understanding of the system became increasingly concentrated inside a single human being.

At the time, that risk felt theoretical. Then the company was acquired.

Acquisitions rarely unfold the way people imagine. Leadership focuses on systems, products, contracts, and organizational charts. Engineers focus on architecture, tooling, and technical integration. What frequently gets underestimated is how much knowledge walks out the door during the process. Some people leave because they don't like working in larger organizations. Some leave because they see uncertainty ahead. Some receive attractive offers elsewhere. The reasons vary. The outcome is predictable.

When attrition hit, we discovered that nobody really understood large portions of the authorization system.

The code hadn't changed. The business requirements hadn't changed. What changed was the organization's access to context. Decisions that had once seemed obvious now looked mysterious. Certain behaviors existed for reasons nobody could explain. Edge cases appeared without documentation of why they mattered. The team was forced to reverse engineer both the implementation and the intent behind it.

The debt wasn't in the code. The debt was in the missing understanding.

I've watched versions of this story repeat throughout my career. Different companies, different technologies, different products. The same outcome.

An engineer becomes the Kubernetes expert. Another becomes the integration expert. Someone else becomes the person who understands billing. Over time, entire domains become associated with individuals rather than teams. Leadership often interprets this as healthy ownership. Sometimes it is. More often, it's a warning sign.

There is a meaningful difference between ownership and exclusivity.

I've watched plenty of teams convince themselves they had ownership when what they really had was dependency.

Healthy ownership creates accountability. Unhealthy ownership creates bottlenecks. The distinction matters because many engineering organizations have become obsessed with ownership while paying far less attention to stewardship. Ownership answers the question of who is responsible for a system. Stewardship answers the question of whether the organization can survive if that person leaves.

Those are not the same question.

Some of the healthiest engineering cultures I've encountered were surprisingly resistant to exclusive ownership. They encouraged engineers to move between domains. They deliberately rotated responsibilities. They accepted short-term inefficiencies in exchange for long-term resilience. New contributors occasionally moved slower than experts, but that temporary cost was viewed as an investment rather than a problem.

Other organizations took the opposite approach. Work remained concentrated because concentration optimized for immediate velocity. The result was usually impressive right up until the moment somebody resigned.

This becomes particularly painful as companies grow.

In a small startup, tribal knowledge can feel harmless. Everyone sits near each other. Questions are answered quickly. Most of the team can still hold a rough mental model of the system in their heads. As the company expands, that model begins to fracture. New engineers join. Teams split. Products multiply. Context becomes harder to acquire.

At that point, tribal knowledge stops being a convenience and starts becoming a liability.

A service nobody understands becomes an onboarding problem. A deployment process that exists only in someone's memory becomes an operational problem. An undocumented architectural decision becomes a planning problem. A critical dependency known only to one engineer becomes a staffing problem.

Eventually these issues surface as delays, outages, missed estimates, and frustration. By the time leadership notices them, the organization treats them as execution problems when they are really knowledge problems.

Much of what we call technical debt is actually information debt. The code is simply where the consequences become visible.

The healthiest engineering organizations I've worked with were never the ones that eliminated uncertainty. They were the ones that reduced the number of critical things known by only one person. They treated knowledge as infrastructure — something that needed to be maintained, distributed, and made resilient to the loss of any individual contributor.

Most engineering leaders spend significant energy debating technology choices. Frameworks, databases, cloud providers, architecture patterns. Those decisions matter. But they are rarely the source of the most painful debt I've encountered.

The most expensive debt is usually not stored in source control at all.

It lives in the person who just gave two weeks' notice — and in every undocumented decision, every unwritten runbook, every system whose behavior only one person fully understands.

Unlike a software dependency, that kind of debt can't wait for the next sprint. When it leaves, it's gone.