The Engineer Who Knows Everything Is a Project Risk

When “ask John” becomes part of the engineering process, the project has already developed a single point of failure.

The integration build fails at 9:17 on Tuesday morning.

Nothing dramatic. No smoke. No destroyed hardware. One subsystem simply refuses to initialize unless another unit is powered first.

The interface control document says nothing about a startup sequence.

The requirement says nothing about a dependency.

The test procedure assumes both units are already running.

After 20 minutes of searching through old meeting notes, someone finally says the three words everyone expected:

“Ask John.”

John joins the call. He remembers that the original supplier firmware had a timing issue. He remembers that the team agreed to handle it through the power-up sequence rather than change the hardware. He remembers which test exposed it, who accepted the workaround, and why nobody wanted to reopen the interface.

There is no decision record. No trace to the affected requirement. No explanation in the design description.

But John remembers.

The problem is solved in five minutes.

Everyone moves on.

And the project becomes a little more dependent on John than it was the day before.

John Is Not the Problem

Let us be clear: John is probably an excellent engineer.

He has been with the project since the early architecture studies. He knows which requirements were inherited from the customer, which were derived during design, and which were written after something went wrong in testing.

He knows that a value shown as 100 ms in one specification is really approximately 100 ms, provided the system is already thermally stable. He knows why one apparently redundant interface must remain. He knows which supplier drawing cannot be trusted without checking the accompanying email thread.

When a difficult question appears, John saves time.

That is exactly why the risk remains hidden.

The project does not feel vulnerable while John is available. Questions get answered. Reviews keep moving. Integration problems get resolved. The schedule survives.

On the surface, this looks like expertise.

Underneath, it is an unmanaged dependency.

Software teams sometimes describe this using the “truck factor”: the minimum number of people whose sudden departure would leave a project unable to continue. In a study of 133 popular GitHub projects, researchers estimated that 65 percent had a truck factor of two or less.[1]

The phrase is deliberately uncomfortable, but the underlying question is useful:

How many people could become unavailable before this project stopped understanding its own system?

They do not have to leave the company. They could retire, transfer to another program, take parental leave, become ill, accept a promotion, or simply be consumed by a higher-priority crisis.

Sometimes John is still sitting in the same building.

He is just no longer available when the project needs him.

The Human API

When knowledge is concentrated in one engineer, that person gradually becomes a human application programming interface.

Need to know why a requirement exists? Ask John.

Need to understand a strange piece of legacy logic? Ask John.

Need to know whether a proposed interface change will break the test equipment? Ask John.

Need to find the analysis supporting a design limit? John probably knows where it is.

The team begins routing more questions through him because it is faster than searching incomplete documentation. That gives John even more context, which makes him even more valuable, which causes still more questions to be routed through him.

It is a reinforcing loop.

Eventually, John is invited to every review. He becomes the mandatory reviewer for changes outside his formal responsibility. Junior engineers wait for him rather than making decisions. Managers protect his time while simultaneously making him essential to more activities.

His expertise becomes a bottleneck disguised as productivity.

This is not only a turnover risk. It is already a schedule risk.

If eight engineers need John’s interpretation before they can proceed, the project is operating at the speed of John’s calendar.

How Tribal Knowledge Accumulates

Tribal knowledge rarely appears because engineers are careless.

It usually forms for understandable reasons.

A decision must be made before the next design review. The team discusses it in a meeting, reaches agreement, and updates the drawing—but not the rationale.

A requirement changes. The specification captures the new value, but the analysis behind it remains in someone’s personal folder.

An interface issue is resolved during a call with the supplier. Everyone on the call understands the outcome, so documenting the conversation feels less urgent than completing the design.

A test exposes an edge case. The team creates a workaround, verifies that it works, and promises to update the system description after the test campaign.

Then the next problem arrives.

This is how projects end up with documents that describe what the system is, while the reasoning that explains why it became that way remains scattered across memories, emails, chat messages, notebooks, review comments, and obsolete presentations.

The danger is not merely that information is missing.

It is that nobody can tell which information is missing.

The Most Valuable Knowledge Is Often the Least Visible

Engineering documents usually capture the final answer:

• The selected architecture
• The approved requirement
• The released interface
• The accepted risk
• The qualified component
• The verification result

What they often omit is the path to that answer:

• Which alternatives were considered?
• Which assumptions made the analysis valid?
• What evidence caused one option to be rejected?
• Which stakeholder accepted the remaining risk?
• What would need to change before the old decision should be reconsidered?
• Which failure mode was almost overlooked?
• Which part of the design is intentionally conservative?

That context is design knowledge.

Without it, a future engineer may see a constraint and assume it is arbitrary. They may “simplify” an interface that contains a hard-earned protection. They may repeat a trade study without knowing that one alternative was already disqualified by a test result. They may change a requirement without understanding the downstream verification or safety implications.

A 2023 systematic review of 91 empirical studies found that employee turnover is a widely reported cause of organizational knowledge loss. The review also notes that losing tacit knowledge—the experience and judgment that are difficult to formalize—can be more damaging than losing information that has already been codified.[2]

A drawing can be transferred.

Judgment is harder.

Turnover Does Not Create the Knowledge Problem

When a key employee resigns, the organization often treats the following weeks as a knowledge-transfer emergency.

Meetings are scheduled. Documents are requested. A successor begins shadowing the departing engineer. Someone creates a spreadsheet titled “handover plan.”

But the resignation did not create the knowledge risk.

It exposed it.

If ten years of engineering rationale must be reconstructed during a two-week notice period, the organization is not conducting knowledge transfer. It is attempting knowledge recovery.

Some information will be captured. Much of it will not, because experts do not carry a neatly indexed inventory of everything they know. They remember knowledge in context—when they see a drawing, encounter a failure, hear a familiar question, or return to a particular test setup.

“Document everything you know before Friday” is not a realistic request.

NASA’s knowledge-continuity guidance therefore recommends more than a final handover meeting. It includes overlap, shadowing, mentoring, talking through thought processes, identifying essential references, documenting recurring problems, preserving lessons learned, and cross-training another person when a direct successor is unavailable.[3]

The best time to transfer critical knowledge is while it is being used—not after the person holding it has announced a departure.

Stale Knowledge Can Be as Dangerous as Missing Knowledge

Capturing information once is not enough.

Knowledge must remain connected to the current design.

A U.S. Department of Energy audit at Sandia National Laboratories illustrates the issue. The audit found that formal documents used to track nuclear-safety concerns had not always been updated with knowledge gained through later testing and analysis. The report warned that information needed for future decisions might not be readily accessible and explicitly identified employee turnover and loss of institutional knowledge as reasons to maintain a current, configuration-managed repository.[4]

The important lesson is not specific to nuclear engineering.

A repository full of obsolete information does not preserve knowledge. It preserves uncertainty.

The project needs to know:

• What is current?
• What has been superseded?
• Who approved it?
• What evidence supports it?
• Which artifacts depend on it?
• What changed, and why?

Without configuration control and traceability, documentation becomes another source engineers must interpret—and that interpretation often sends them back to John.

Documentation Alone Will Not Fix It

The usual response to knowledge silos is: “We need better documentation.”

True, but incomplete.

Teams can produce enormous amounts of documentation and still depend on tribal knowledge. The problem is often not the absence of documents. It is that the documents are disconnected, difficult to search, inconsistently maintained, and stripped of decision context.

NASA learned a similar lesson with its agency-wide lessons-learned system. A U.S. Government Accountability Office review found that having processes and repositories did not ensure lessons would be used. Lack of time, cultural resistance, weak incentives, and difficulty accessing relevant information all limited effective knowledge sharing.[5]

Knowledge management is not the construction of a larger document graveyard.

It is the deliberate practice of making important knowledge:

• Capturable
• Findable
• Understandable
• Connected
• Current
• Reusable
• Owned by the organization rather than one individual

That is why ISO 30401 treats knowledge management as a management system that must be established, implemented, maintained, reviewed, and continually improved—not as a one-time documentation exercise.[6]

What Good Engineering Knowledge Management Looks Like

There is no need to document every conversation or preserve every intermediate calculation forever.

The goal is to identify knowledge whose loss would materially affect the product or project.

A practical approach begins with five changes.

1. Identify knowledge concentration as a project risk

Ask which decisions, components, interfaces, tools, suppliers, and test methods depend heavily on one person.

Put those dependencies in the risk register.

“John knows it” is not a mitigation.

A real mitigation has an owner, an action, a completion criterion, and evidence that another person can perform the work.

2. Capture rationale when decisions are made

A useful decision record does not need to be a 20-page report.

It should capture:

• The problem
• The options considered
• The decision
• The reason for the decision
• The assumptions and evidence used
• The people involved
• The affected artifacts
• The conditions that would justify revisiting it

Five disciplined minutes at the time of the decision can prevent weeks of archaeology later.

3. Connect knowledge to the engineering baseline

Do not leave a critical decision isolated in meeting minutes.

Link it to the requirement it affects, the interface it constrains, the risk it accepts, the architecture element it shapes, and the test evidence that supports it.

Traceability is not useful only for compliance. It preserves context across the lifecycle and allows teams to follow relationships from needs through requirements, design, implementation, verification, and future changes.[7]

4. Build operational redundancy

A backup engineer named on an organization chart is not necessarily a backup.

Can that person diagnose the problem?

Can they approve a change?

Can they explain the design to a reviewer?

Can they operate the test equipment without calling the primary engineer?

Design reviews, paired work, mentoring, role rotation, cross-training, and joint troubleshooting are how tacit knowledge moves between people.

The transfer must be demonstrated through work.

5. Test whether the knowledge is usable

Choose a subsystem and ask an engineer who did not create it to answer:

• Why does this requirement exist?
• What assumptions constrain the design?
• Which alternatives were rejected?
• What else changes if this interface changes?
• Where is the verification evidence?
• Which unresolved risks remain?

If the answers require a call to one specific person, the organization has found a knowledge gap.

That is useful information—provided it acts before the gap becomes an emergency.

Where Ngenaire Helps

This is one of the problems Ngenaire is designed to address.

Engineering knowledge is difficult to preserve when requirements live in one tool, risks in another, test evidence in spreadsheets, architecture in diagrams, and design rationale in email. Even when every artifact exists, the relationships between them remain inside the engineers who understand the whole picture.

Ngenaire provides an AI-assisted systems-engineering workspace organized around defining, modelling, verifying, tracking, and reporting the system. Its project structure brings requirements, baselines, engineering changes, trade studies, diagrams, risks, issues, test artifacts, verification evidence, and durable project memory into a connected environment.[8]

The Network View helps teams see relationships among artifacts such as requirements, risks, tests, the Statement of Work, the CONOPS, and diagrams. Project Memory provides durable notes that the AI assistant can use as project context. Traceability makes it possible to move from an engineering statement to the artifacts that justify, implement, or verify it.

That matters because the goal is not simply to store John’s documents.

It is to preserve enough structured context that another engineer can determine:

• What was decided
• Why it was decided
• What it affects
• What evidence supports it
• Whether it is still current
• What must be reconsidered if it changes

AI can also help teams interrogate the project record, find gaps, draft missing artifacts, compare information, and surface possible inconsistencies. But it cannot recover a decision that was never captured or manufacture context that nobody recorded.

Human review still matters. Configuration control still matters. Technical authority still matters.

Ngenaire is most valuable when it helps engineers preserve knowledge as part of the engineering workflow—not as a desperate cleanup activity before someone leaves.

The Goal Is Not to Make John Less Valuable

Good knowledge management does not diminish experts.

It gives them leverage.

Instead of answering the same historical questions repeatedly, John can work on the next difficult problem. Instead of being the only person who can approve a change, he can develop others who understand the system well enough to challenge and improve it. Instead of functioning as the project’s memory, he can contribute to a technical memory that survives him.

That is better for the project.

It is also better for John.

Being indispensable sounds flattering until it means you cannot take a vacation, change roles, or focus on new work because the old system cannot function without you.

The strongest engineering organization is not the one with a hero who knows everything.

It is the one where deep expertise becomes shared capability, important decisions remain traceable, and the project can keep thinking even when one person is not in the room.

So here is the uncomfortable question:

If one engineer disappeared from your project tomorrow, which part of the system would stop making sense?

Whatever your answer is, that is where your knowledge-management work should begin.

References

[1] G. Avelino, L. Passos, A. Hora, and M. T. Valente, “A Novel Approach for Estimating Truck Factors,” in Proc. 24th IEEE International Conference on Program Comprehension, 2016, doi: 10.1109/ICPC.2016.7503718.

[2] N. Galan, “Knowledge Loss Induced by Organizational Member Turnover: A Review of Empirical Literature, Synthesis and Future Research Directions—Part I,” The Learning Organization, vol. 30, no. 2, pp. 117–136, 2023, doi: 10.1108/TLO-09-2022-0107.

[3] National Aeronautics and Space Administration, “NASA Knowledge Continuity: A Guide for the Departee,” NASA, 2025. Accessed: Aug. 18, 2026.

[4] U.S. Department of Energy, Office of Inspector General, “Followup on Sandia National Laboratories’ Nuclear Weapons Safety Program,” Audit Rep. OAI-M-16-16, Aug. 2016.

[5] U.S. Government Accountability Office, “NASA: Better Mechanisms Needed for Sharing Lessons Learned,” Rep. GAO-02-195, Jan. 2002.

[6] International Organization for Standardization, “ISO 30401:2018—Knowledge Management Systems—Requirements,” Geneva, Switzerland, 2018.

[7] Federal Highway Administration, “Systems Engineering for Intelligent Transportation Systems: Traceability,” U.S. Department of Transportation. Accessed: Aug. 18, 2026.

[8] Ngenaire, “Ngenaire Documentation,” 2026. Accessed: Aug. 18, 2026.