Key-Person Dependency and Knowledge Capture in Large Model Product Development

1. Why Key-Person Dependency Is a Development Risk

Teams often have a small number of people who simultaneously hold architecture design, core modules, and product judgment. When those people leave, the code and documents may still be there, but the rationale, context, and trade-offs go with them. New members then need weeks or even months to rebuild that understanding. Product pace slows, and the chance of repeating old mistakes rises.

Large model products make this sharper. Model capabilities change quickly. Evaluation criteria, prompt templates, data-processing rules, and live behavior are tightly linked, and much of that experience lives only in individual memory. Without systematic records, every adjustment forces the team to rediscover the same ground.

Outside observers usually see only the outcome of staffing changes, not the real state of the organization. Treating one person’s arrival or departure as a signal of organizational health is a weak basis for judgment. The more useful question is whether the team can keep delivering through turnover. The rest of this article stays on that question.

2. Measure Dependency Before Improving It

Improvement starts with knowing where the risk sits. A common idea is the bus factor: how many core members a module can lose before no one can maintain it independently. A lower bus factor means more concentrated dependency.

Start with four indicators:

• Maintainer concentration: In the last six months of changes to a module, does one person account for more than 60 percent?
• Decision-source concentration: Are important technical decisions initiated by only a few people?
• Documentation coverage: Do core modules have a design note, a runbook, and a named owner?
• Evaluation-asset coverage: Do evaluation sets and regression cases have a clear maintainer, and can someone else reproduce the results in their own environment?

The pseudocode below shows how to compute maintainer concentration from version history:

Input: change records from the last six months, changes
       each record includes author and path
For each module M:
    count = number of changes under M by each author
    total = sum of changes across all authors
    if total is 0, skip this module
    top_share = max(count) / total
    if top_share > 0.6: mark as "high concentration"
    if number of active authors <= 1: mark as "single-point dependency"
Output: module list sorted by top_share descending

Thresholds should be adjusted for team size. In a small team, two maintainers is often normal. What matters is whether someone else can take over within a week. Alongside the numbers, team leads should regularly answer one question: if a core member is unavailable tomorrow, who takes this module? Modules with no answer are the ones to handle first.

3. Four Carriers for Capturing Knowledge

Capturing knowledge is not the same as writing more documents. A useful approach is to design different carriers for different jobs, each answering one kind of question.

1. Decision records

Every decision that affects architecture or product direction should record the context, alternatives, reasons for the choice, known costs, and a review date. The point is to record why it was done this way, not only what was done. The latter is already visible in the code. The former exists only in someone’s head.

A short template can include these fields:

Title: decision name
Status: proposed / accepted / deprecated
Context: constraints and problems that led to the decision
Options: at least two, each with pros and cons
Decision: chosen option and the reason
Cost: known limits and risks accepted
Review date: when the decision will be reassessed

2. Runbooks

A runbook explains how a service is deployed, how to troubleshoot it, what each alert means, and how to roll back. Write it for someone taking the system over for the first time. Do not assume the reader already knows the system’s history. Each troubleshooting step should include the expected symptom and the criterion for judging it. Otherwise the runbook quickly becomes a formality.

3. Context maps

Use one page to describe system boundaries, the main data flows, external dependencies, and the teams responsible for them. A context map helps new members form a whole-system view quickly and reduces rework caused by misunderstanding what a module is responsible for.

4. Self-describing code and configuration

Comments should explain intent and non-obvious constraints, not restate what the code already does. Configuration items should note the default, the allowed range, and the impact of changing them. This material is versioned with the code and evolves with it, so it is the knowledge carrier least likely to go stale.

4. Designing the Handover

Handover should not be improvised in the week before someone leaves. A more reliable approach splits it into three stages:

1. Inventory: When a move is planned, list the modules that person owns, work in progress, open risks, and external relationships they depend on.
2. Joint execution: The incoming owner follows the current owner through one real task, including requirements review, code changes, release, and production observation.
3. Independent verification: After the handover, the incoming owner completes one requirement alone, records the gaps they hit, and writes those gaps back into the documents.

A handover checklist can use this structure. Each item needs a completion mark and a confirmer:

Module: ____
Owner (outgoing): ____    Incoming owner: ____
Work in progress: [ ] task list and current status
Open risks:       [ ] risk description and response plan
External deps:    [ ] dependent parties and contacts
Runtime access:   [ ] access has been transferred
Keys and credentials: [ ] shared credentials have been rotated
Docs updated:     [ ] runbook and context map updated
Verification:     [ ] incoming owner completed one independent change

Shadowing and rotation

Every core module should have at least two people who know it. Quarterly rotation can move on-call, code review, and release ownership across different members. During review, ask the reviewer to state at least one alternative. That makes the judgment explicit.

Access and credentials

When someone leaves, revoke access under least privilege and rotate the shared secrets they could use. Secrets should not be written into code or logs. Keep them in a dedicated secrets manager and audit access. These steps are both a security requirement and part of the handover.

5. Use Engineering Practice to Reduce Tacit Knowledge

Tacit knowledge accumulates most easily in day-to-day operations. Standardizing those operations reduces dependence on personal experience.

• Version evaluation assets: Put evaluation sets, prompt templates, and configuration files under version control. Attach a note and the evaluation result to every change.
• Check that docs move with code: Add a rule to continuous integration. When code changes in a module pass a size threshold and the docs were not updated, notify the owner automatically.
• Practice on a schedule: Each quarter, pick a module and have a non-author complete a fix or an extension using only the documents. Record where they got stuck, and fill those gaps in the docs.

The doc-sync check can be expressed like this:

Input: files changed in this merge request, files
       documentation directory map, doc_map
For each changed module M:
    changed_lines = number of code lines modified in M
    if changed_lines < threshold: skip
    if the document mapped by doc_map[M] was not updated in this change:
        notify the owner of M

The point of the exercise is to test whether the documents actually work. Whether someone else can follow them matters more than whether they exist.

6. Align Strategy at the Organization Level

If product direction exists only in what a few people say, it becomes another dependency. A practical set of practices:

• Publish a direction note each quarter that states goals, priorities, and what the team will explicitly not do.
• Break goals down to modules. Each module has a named owner and a backup.
• Treat public information as reference only. Internal decisions follow the written record.

“What we will not do” often reduces misunderstanding more than “what we will do.” It draws a boundary and lets new members judge quickly whether a piece of work is inside the current direction.

7. A Rollout Path and Measures

Move in 30-day stages:

Days 1–30: Inventory module dependency, identify high-risk modules, create a decision-record index, and name a backup for every core module.

Days 31–60: Fill in runbooks and context maps for core modules, establish a handover checklist template, and start pairing and rotation.

Days 61–90: Run one assumed-departure exercise, add the doc-sync check to continuous integration, and set up a quarterly review.

Track progress with these measures:

• Whether the number of high-risk modules falls quarter by quarter
• Average days for a new member to complete a first requirement independently
• Documentation coverage of core modules
• Average time to finish shared-credential rotation
• Share of exercise fixes completed independently by a non-author

8. Common Mistakes

Mistake 1: Treating documents as knowledge. Stale documents are more dangerous than missing ones, because people trust them. Documents need to be updated with the code and checked on a regular basis.

Mistake 2: Relying on a few heroes. Strong individual ability is an asset, but if a system runs only because one person holds it together, the risk is already concentrated. Turn personal experience into reusable process and records.

Mistake 3: Making handover a formality. A handover with no real task cannot be verified. It needs both joint execution and independent verification before you can say the incoming owner can actually maintain the work.

Mistake 4: Caring about knowledge capture only when people move. Capture should be part of ordinary work. Waiting until someone is leaving to backfill documents costs more and misses more.