Only One Person Knows How That Service Works. They're in a Meeting.

Every engineering organization has at least one service like this. The code exists. The service runs. It has been running for years. But ask anyone on the team how it actually works — the edge cases, the retry behavior, the specific reason the timeout is set to what it is — and they'll say: "You should ask Alice." Alice built it. Alice understands it. Alice is the only reliable source of truth for anything nontrivial about that service. Alice is in a meeting.

This is the bus factor problem in its most common form, and it's not a failure of Alice. It's a failure of the systems around Alice. The knowledge was never captured in a way that survives her unavailability, let alone her departure. The codebase has the behavior. The reasoning, the context, the undocumented edge cases — those live in Alice's head, and the team discovered this the hard way when they needed them and Alice wasn't there.

How single-person dependencies form

Nobody decides to concentrate system knowledge in one person. It happens gradually. Someone builds a service and understands it deeply. They answer questions quickly and accurately. Other engineers learn that asking Alice is faster than reading the code. Alice becomes the first call for anything auth-related. Alice's understanding deepens while everyone else's stagnates. The knowledge gap widens until Alice is genuinely irreplaceable for that service.

The pattern accelerates under time pressure. When there's an incident, the fastest path to resolution is to page Alice, not to read the code and reason through it. When there's a design question, the fastest path is to ask Alice, not to explore the service architecture. Each shortcut is rational in the moment. In aggregate, they produce a service that one person understands and everyone else fears.

What a single-person knowledge dependency costs:

  Before Alice is available:
    -> Bug in auth service: 4-hour wait for Alice's context
    -> PR review for auth changes: Alice only, queue builds
    -> Architecture decision touching auth: scheduled around Alice
    -> On-call incident in auth: escalates to Alice regardless of hour
    -> New engineer ramp on auth: Alice's calendar, 3-week wait

  When Alice leaves:
    -> All of the above become: "nobody knows"
    -> Auth service becomes untouchable except for the bravest
    -> Incidents in auth become all-hands events
    -> New features requiring auth changes get deprioritized

  None of this is Alice's fault. The knowledge should never have lived only in her head.

The service that can't be touched

Single-person knowledge dependencies don't just create scheduling bottlenecks — they create technical conservatism. Engineers avoid changing services they don't understand. A service that only Alice understands becomes a service that only Alice changes. Other engineers route around it, build workarounds instead of touching it, and add complexity elsewhere to avoid the one service they can't confidently modify.

Over time, this produces a system that has stable core services nobody understands and fragile peripheral services built to avoid touching them. The architectural decisions that result aren't made for technical reasons — they're made to avoid knowledge dependencies that should have been resolved years ago.

What the codebase already contains

The information needed to understand a service is mostly in the codebase. The service boundaries are clear from the API surface. The dependencies are visible from the imports and call patterns. The configuration options are in the config model. The error states are in the error handling code. The recent changes and reasoning are in the commit history. Tests describe the intended behavior. None of this requires Alice.

What reading the codebase reveals about a service:
  -> Service boundaries and responsibilities
  -> External dependencies (what it calls, what calls it)
  -> Configuration options and their effects
  -> Error states and their handling
  -> Recent changes and the reasoning in commit messages
  -> Test cases that describe intended behavior
  -> CODEOWNERS and who to contact for changes

  A developer with AI codebase tools gets this in minutes.
  Everyone else waits for Alice.

What Alice provides that the codebase doesn't is the verbal context — the meeting where the timeout value was debated, the incident that shaped the retry logic, the performance constraint that drove an architectural decision. These are genuinely hard to capture. But they represent a small fraction of the questions that currently route to Alice. The majority are factual questions that have codebase answers.

Making the codebase the first call, not Alice

The pattern that produces single-person dependencies — "asking Alice is faster than reading the code" — only holds when reading the code is slow and difficult. When the codebase is queryable in plain language, asking the codebase is faster than waiting for Alice's calendar slot. An engineer who can ask "how does the auth service handle token refresh?" and get a navigable answer in seconds doesn't need to wait for Alice for that question.

Kognita makes the codebase queryable by anyone on the team — developers and non-developers alike — in plain language. Service behavior, dependencies, recent changes, ownership: all of it available directly without requiring Alice's time. Alice's expertise remains valuable for questions that require her judgment. It stops being required for questions that have codebase answers.

Final take

The Alice dependency is a symptom of a system where asking Alice was always faster than reading the code. Making the codebase as queryable as Alice changes the calculus. The questions that used to route to Alice route to the codebase instead. Alice's time goes to the decisions that actually need her expertise. The service is no longer a single-person system.

Alice isn't the problem. The fact that she's the fastest path to system knowledge is the problem. Make the codebase the faster path, and Alice stops being the bottleneck.