How much knowledge concentration can two engineers carry?

A team of two can ship an astonishing amount of software with coding agents. It can also become dangerously dependent on one engineer while every repository looks busy and every pull request looks reviewed. The right way to measure knowledge concentration is to test whether either person can understand, change, deploy, and recover each important component without the other person supplying missing context.

Commit counts will not tell you that. Neither will the number of files each engineer touched, the number of agent sessions they ran, or a cheerful answer to "does everyone know the system?" You need a monthly scorecard built from component ownership, reviewer coverage, recovery exercises, unowned services, and documentation freshness. The scorecard should expose where one absence would stop delivery or extend an incident.

I use "component" throughout this article to mean an operational unit with a clear failure boundary: an API, worker, mobile app, data pipeline, infrastructure stack, billing integration, or anything else that can break and demand a decision. Repositories are sometimes components, but often they are only containers. Measure the unit you deploy and recover, not the folder layout inherited from three architectures ago.

Knowledge concentration is access plus judgment

Knowledge concentration exists when one person holds decisions that the other person cannot reconstruct fast enough for the business. Access to source code is necessary, but it is not proof of transferable knowledge. An engineer can read every file and still not know why retries stop after four attempts, which migration must never run during settlement, or which alert can wait until morning.

That distinction matters more in an AI coding setup. An agent makes unfamiliar code easier to search and modify. It does not reliably recover unwritten intent, production history, customer promises, or the reason an apparently odd guardrail exists. If the agent sees only the repository, it can make the second engineer confidently wrong faster.

Treat knowledge as four capabilities. A second engineer must be able to locate the component, explain its important constraints, make a normal change, and restore acceptable service after a representative failure. If any capability depends on a live explanation from the primary engineer, knowledge remains concentrated.

Separate discoverability from competence. Search, repository maps, and agent transcripts can make an answer discoverable. Competence means the engineer can judge whether that answer still applies and what can go wrong when they use it. A saved prompt that produced a migration is evidence of how code was generated, but it is not evidence that the backup understands the lock behavior or rollback limit.

This is why the usual bus factor question, "How many people must disappear before the project stops?", is too crude for a team of two. The answer is almost always one, which gives you no direction. Component level measures show whether the risk sits in a low impact reporting job or in the payment path that funds the company.

Do not score both engineers as interchangeable across the entire stack. That goal wastes time and usually produces shallow familiarity. Score each important component, then decide how much backup capability its business impact deserves. A marketing page and an authentication service should not carry the same recovery target.

Build the inventory around failure boundaries

The scorecard starts with a component inventory that is small enough to review and precise enough to assign. If the inventory says "backend," it hides risk. If it lists 400 libraries, the monthly review becomes bookkeeping. Most small products land somewhere between eight and thirty operational components.

Give every component a stable name, business impact, deployment path, data store, primary owner, backup owner, and recovery target. The primary owner is the engineer who currently makes most decisions there. The backup owner is the person expected to act when the primary is unavailable. In a team of two, those labels will often alternate, but they still need to be explicit.

Use impact tiers to decide how strict the measures should be:

• Tier 1 stops revenue, blocks all users, risks data, or prevents login.
• Tier 2 breaks an important workflow while a workaround exists.
• Tier 3 causes limited inconvenience or delays internal work.
• Tier 4 can remain unavailable for several days without material harm.

Keep the tier definition tied to business consequences. Engineers tend to rate technically interesting systems as important and boring integrations as peripheral. The business often experiences the reverse.

A useful inventory row looks like this:

component,tier,primary,backup,deploy_path,data_store,recovery_target_hours
checkout-api,1,Ada,Max,ci/checkout.yml,orders-postgres,2
email-worker,2,Max,Ada,ci/workers.yml,queue-and-postgres,8
marketing-site,4,Ada,Max,ci/web.yml,none,72

This artifact prevents three common failures. It stops ownership from living only in memory, separates deployment knowledge from code familiarity, and gives recovery time a business target. Store it beside the code or operational documentation so pull requests can change it with the system.

Review the inventory against production, not against the repository list. Cloud accounts, scheduled jobs, DNS zones, certificate renewals, vendor consoles, and data exports are easy to omit because they may have little code. They still wake someone during an incident. An unlisted dependency is effectively unowned and should count against the score until somebody names it.

Ownership needs evidence from recent work

Component ownership measures who can make a safe decision today, not who wrote the first version. For each component, record a primary and a backup, then require recent evidence that both roles are real. A name in a spreadsheet without activity is an aspiration.

Count someone as an active owner only if, during the review window, that person completed at least one meaningful ownership action. Good evidence includes shipping a change, reviewing a nontrivial change, running a deployment, updating an operational decision, or leading a recovery exercise. Reading a ticket or approving a dependency bump does not prove much.

Calculate ownership coverage as:

ownership coverage =
components with active primary and active backup
/
all in-scope components

Report it by tier before you report one combined percentage. If all Tier 4 components have two active owners but the only Tier 1 service has one, an overall result can look healthy while the company carries its largest risk untouched.

I score a Tier 1 component green only when both engineers have performed an ownership action within the last 60 days. Tier 2 can use 90 days, and lower tiers can use 180 days. These are starting targets, not natural laws. A company with seasonal billing or rare regulated workflows may need a different window. Write the window down so nobody moves it to improve this month's color.

GitHub's CODEOWNERS documentation says the platform can request owners automatically when a pull request changes matching files, and repository rules can require an owner's approval. That is useful routing, but it does not solve concentration. If Ada owns checkout and GitHub sends every checkout review back to Ada, the file records the dependency instead of reducing it.

For a team of two, use ownership rules to force cross exposure. The author should not provide the only knowledgeable approval for their own component. If your hosting platform supports approval by someone other than the last person who pushed, enable that rule on protected branches. The control creates a moment for knowledge transfer; the review evidence tells you whether transfer actually happened.

Reviewer coverage reveals independent understanding

Reviewer coverage asks a narrower question than ownership: can the other engineer evaluate a meaningful change without the author narrating every decision? Measure accepted reviews across component boundaries, not raw review volume.

For each component, inspect meaningful pull requests merged during the month. Exclude mechanical formatting, generated files, dependency refreshes with no behavior change, and agent produced cleanup that carries no operational decision. Among the remaining changes, count how many received a substantive review from the backup owner.

Use this formula:

reviewer coverage =
meaningful changes reviewed by the backup
/
meaningful changes eligible for backup review

A substantive review should leave evidence of comprehension. The reviewer might question a failure mode, request a test, correct an assumption, check rollout behavior, or approve with a short explanation of what they verified. A silent approval proves identity, not understanding.

Do not set 100 percent as a universal target. It creates approval theater, especially when agents generate many small pull requests. I prefer a coverage target based on risk: every Tier 1 behavior change gets backup review, while lower tiers use a sample large enough to keep the backup familiar. If a component had no meaningful change that month, mark reviewer coverage "no sample." Do not turn absence of evidence into a perfect score.

Review latency also matters, but interpret it carefully. A backup who needs two days and a private briefing to review a small checkout change probably lacks independent understanding. Track median time from review request to first substantive response for Tier 1 and Tier 2 components. Do not punish time outside working hours or agreed leave.

The awkward case is simultaneous pair work with an agent. If both engineers shaped the prompt, inspected the plan, and followed the changes together, count the second engineer as a reviewer only when the pull request records what they checked. Conversation is useful, but invisible conversation cannot support a later scorecard or incident handoff.

Recovery time is the test that cannot be faked

Recovery time measures how long the backup engineer takes to restore a component to its agreed condition without help from the primary. It is the strongest concentration signal because it tests code, access, documentation, observability, and judgment at once.

Define a small recovery exercise for every Tier 1 component and rotate through them. The exercise can restore a database snapshot into an isolated environment, roll back a bad release, replace an expired credential, rebuild a worker from an empty queue, or diagnose a synthetic alert. Do not cause a production outage merely to collect a metric.

Measure elapsed time from the moment the backup receives the scenario until the service passes the stated verification. Pause the clock only for a dependency outside the team's control, and record the pause. If the backup asks the primary for a command, a credential location, or an undocumented safety rule, the exercise has found concentrated knowledge. Let the primary answer to protect time, but mark the run as assisted.

Separate three values:

• Target recovery time is the business limit from the inventory.
• Observed recovery time is the backup's actual elapsed time.
• Recovery confidence records whether the run was independent, assisted, or failed.

Google's Site Reliability Engineering book separates an indicator, an objective, and the action taken when a result misses the objective. Apply the same discipline here. The observed recovery time is the indicator. The inventory target is the objective. The remediation might be access repair, a better runbook, simpler deployment, or a supervised repeat.

Do not collapse recovery into "runbook exists." I have seen precise runbooks fail because the backup lacked access to the secret store. I have also seen thin notes succeed because the system was simple and the engineer understood it. Time the outcome.

A monthly exercise does not need to cover every service. Test one or two high impact components, then retain the latest result for each component on the scorecard. Add the age of that result. A 40 minute independent recovery from eleven months ago should not remain green after the architecture and agent workflow have changed.

Unowned services deserve an explicit penalty

An unowned service is any production dependency without both a current primary and a credible backup. This includes services with no owner, services assigned to a departed contractor, services owned by "the team," and services whose supposed backup lacks access.

Count them directly:

unowned rate =
in-scope components without two credible owners
/
all in-scope components

Then weight the count by impact. One unowned Tier 1 service should hurt more than four Tier 4 jobs. A simple weighting works well: multiply Tier 1 by 8, Tier 2 by 4, Tier 3 by 2, and Tier 4 by 1. The numbers express relative attention, not actuarial truth.

Some founders resist this measure because a system technically has an owner: the CTO, the agency, the vendor, or the engineer who built it two years ago. Test the claim. Can that person access production within the recovery target? Are they expected to respond? Can the other engineer proceed if they do not? A vendor support contract may reduce operational risk, but it does not create internal ownership unless the contract and escalation path match the required response.

AI agents create a newer version of the same problem. A component can be "owned by the agent" in casual speech because either engineer can ask the agent about it. Agents do not hold pager duty, account access, commercial context, or responsibility for a production decision. Assign a human primary and backup. Treat the agent's instructions, context files, and repeatable commands as part of the component's documentation.

Never hide an unowned service by removing it from scope. If the company depends on it, include it. If nobody understands it and nobody can safely change it, that is exactly the result the scorecard needs to show.

Documentation freshness needs a verification event

Documentation is fresh when a backup has used it successfully against the current system, not when somebody edited the date at the top. A "last updated" field rewards cosmetic changes. Verification rewards usefulness.

Track the latest date when someone other than the primary used the component's documentation to complete a defined task. That task might be a deployment, local setup, access request, rollback, recovery exercise, or explanation of a data flow. Record the task and the verifier, not just the date.

Calculate freshness as the percentage of in-scope components with verified documentation inside their tier window. I use 60 days for Tier 1, 90 for Tier 2, and 180 for the rest. Documentation can pass only if it covers the component's purpose, deploy path, dependencies, observability, rollback or recovery action, access location, and the decisions that would surprise a capable engineer.

DORA's documentation quality guidance focuses on clarity, findability, and reliability rather than document volume. I agree with that emphasis, but a team of two needs one extra property: executability. The backup must be able to do something important with the document while the primary stays silent.

Do not ask agents to generate large runbooks from the code and call the job done. An agent can produce a helpful first draft, especially for commands and dependency maps. It cannot verify that a console permission works, that a migration takes longer than the maintenance window, or that the founder promised a customer a special recovery sequence. The backup verifies those details by running the procedure.

Fresh documentation also includes agent context. If the team relies on repository instruction files, saved prompts, tool permissions, or command aliases, test them from the backup engineer's account. A perfect README does not help when the actual workflow depends on a private shell function or an agent connection only one person configured.

Combine signals without hiding a red component

A combined knowledge concentration score helps show trend, but it must never average away a severe gap. Keep the component rows visible and apply a hard cap when a high impact component fails a basic condition.

Use five normalized measures:

ownership_score      = active dual-owner components / all components
review_score         = covered eligible changes / eligible changes
recovery_score       = independent tests within target / completed tests
documentation_score  = components verified inside freshness window / all components
unowned_score        = 1 - weighted_unowned_points / weighted_total_points

monthly_score =
100 * (
  0.25 * ownership_score +
  0.20 * review_score +
  0.30 * recovery_score +
  0.15 * documentation_score +
  0.10 * unowned_score
)

Recovery carries the most weight because it tests the whole chain. Ownership and review show routine distribution. Documentation supports both. The unowned measure overlaps ownership, but I keep it because an explicit penalty prevents an awkward service from disappearing inside an average.

Apply two caps. If any Tier 1 component lacks a credible backup, the monthly result cannot exceed 49. If a Tier 1 recovery test fails or needs primary assistance, it cannot exceed 69 until a repeat passes. Those caps turn a serious dependency into a visible management decision.

Use colors sparingly. Green can mean 85 or above with no cap, amber 70 to 84, and red below 70. The thresholds are useful only if they trigger action. Green means maintain the rotations. Amber reserves capacity for the largest gap in the next month. Red stops discretionary architecture work until the team restores basic coverage on the exposed component.

Here is the minimum monthly record:

month: 2026-07
score: 67
cap_reason: "checkout recovery required primary help"
largest_gap: "backup cannot rotate payment credential"
owner: "Max"
due: 2026-08-07
repeat_test: 2026-08-12
evidence:
  inventory_commit: "abc123"
  recovery_record: "ops/recovery/checkout-2026-07.md"

Do not turn the score into a performance rating for either engineer. People will game any measure tied to compensation or blame. This score rates the operating system of the team. The founder or CTO owns the conditions that allow knowledge to move: time for review, shared access, smaller components, and practice during normal hours.

Run the monthly review in ninety minutes

The monthly review should update evidence, choose one risk to reduce, and schedule a test. Ninety focused minutes is enough for a team of two if the inventory is already maintained with normal engineering work.

Use this sequence:

1. Reconcile the component inventory with production and add anything missing.
2. Pull ownership and review evidence from merged changes, deployments, and operational records.
3. Update recovery results and documentation verification dates.
4. Calculate the scores, apply caps, and inspect Tier 1 rows before the total.
5. Assign one remediation with an owner, due date, and repeat test.

Choose one remediation because two engineers have limited capacity. Fixing access to checkout may matter more than refreshing six low impact documents. The scorecard keeps the other gaps visible for later months.

Automation can collect file changes, reviewers, deployment actors, and document dates. Keep human judgment for whether a change was meaningful, whether a review showed comprehension, and whether a recovery was independent. An agent is good at assembling evidence and spotting stale rows. It should not mark its own generated documentation as verified.

Keep the evidence cheap enough to sustain. Link each scorecard row to a pull request, deployment record, recovery note, or document verification rather than copying the full history into a monthly report. If collecting the evidence takes longer than discussing the risk, simplify the collection. The team needs an operational control, not a reporting department.

Watch the direction across three months instead of arguing over a single point. A score can fall after the team splits one large service into three honest components, because the inventory now exposes missing backups. That decline is useful. Conversely, a rising score with longer recovery times deserves inspection. Metrics should direct a question, not overrule what happened during the exercise.

If a month had no eligible reviews or recovery exercises, show "no sample" for that measure and carry the previous result with its age. Do not substitute zero, which implies failure, or 100, which implies proof. After the allowed window expires, the stale result fails the freshness rule and lowers the score.

At oleg.is, the Team & AI Audit can examine this scorecard alongside delivery flow and engineering cost when a founder wants an outside view. The scorecard still works without any advisory service: its value comes from the evidence and the repeated recovery tests, not from who facilitates the meeting.

The review ends when the repeat test is on the calendar. A documentation task without a test often produces more text and leaves the dependency unchanged.

A passing score must survive one engineer's absence

The most common failure starts quietly. Ada builds checkout with an agent, Max reviews the first pull requests, and both names appear in CODEOWNERS. Over the next three months, Ada handles every payment change because she is faster. Max approves small diffs between other work. The scorecard shows two owners and high review volume.

Then Ada takes a week off. A payment credential expires after a vendor policy change. Max finds the rotation note, but it names an old console menu. His account can read the secret but cannot replace it. The deployment pipeline also expects a checksum command stored in Ada's private shell configuration. The agent correctly finds where the application loads the credential, yet it cannot repair permissions or infer the missing release command.

This failure exposes four different gaps. Ownership evidence was too weak because approvals counted as active ownership. Reviewer coverage measured clicks instead of independent reasoning. Documentation freshness used an edit date instead of a verification task. No recovery exercise had tested access from Max's account.

The remediation is equally specific. Grant and test the required role, move the checksum command into the repository, have Max rotate a test credential, deploy it, and record the elapsed time. Ada stays silent unless the exercise reaches its safety limit. A passing repeat changes the evidence; another rewrite of the runbook does not.

There is a popular recommendation to rotate primary ownership every sprint. I do not use it as a default. Frequent rotation sounds fair, but it can produce constant context switching and two shallow owners. Rotate meaningful actions instead: the backup handles the next deployment, reviews the risky change, and runs the recovery exercise. Keep a stable primary until business needs or concentration evidence justify a switch.

A strong team of two does not know everything twice. It can keep shipping when either person is unavailable because important decisions are visible, access works, and recovery has been practiced. If the scorecard cannot demonstrate that condition component by component, the apparent speed of the AI coding setup is borrowing from a future incident.