Everyone Knows Who to Ask. That Is the Problem.

The person everyone knows to ask

Every team has one. When someone needs to know what was decided about pricing last quarter, why the integration got scoped the way it did, who actually owns the renewal, or where the real version of the deck lives, they do not open a search box. They message one person. That person almost always knows, or knows exactly who does, and answers in a sentence.

This looks like the system working. The answer comes back fast and correct, and it costs nothing to get. The person is helpful and obviously valuable. Nobody files a ticket about it, because nothing is broken. The cost is real, but it does not show up on any dashboard, and it gets paid a few minutes at a time by the one person who has become the team's memory.

The pattern is quiet, and it compounds. The more reliably that person answers, the more they get asked, and the less anyone else bothers to write the answer down, because asking is faster than searching and the person is right there. Every answered question makes the next one more likely to route to the same place. Over a year or two, the team's memory of its own decisions has settled into one or two heads without anyone ever deciding it should.

Why asking a person wins, right up until it costs you

Asking a colleague is a good instinct. It is faster than searching, it comes with the context and judgment a document does not carry, and it usually hands back the one answer you needed instead of ten that are close. People reach for the human source for sound reasons, and no amount of telling them to check the wiki first will change that.

The trouble is what the habit does over time. Each time the answer comes from a person instead of a record, the record does not get made, or the one that exists stays stale because nobody needs it. The knowledge lives entirely in memory and conversation, kept fresh by being asked, and it never turns into anything a new person could read. The team gets faster at retrieving from one brain and worse at retrieving from anything else.

So the convenience is real and the dependency is real, and they turn out to be the same thing. The reason it works so well day to day is the reason it becomes fragile. You have optimized for the case where that person is around and remembers, and you have quietly removed every other route to the answer.

Software teams already put a number on this

Software teams have measured a version of this for years, because in code you can see who wrote what. They call it the bus factor, a term credited to Jim Coplien: the smallest number of people who would have to leave before the work stalls, because the knowledge needed to keep it going left with them. A low bus factor means the project's memory sits in very few heads, and it is treated as a real risk rather than a curiosity.

A 2022 study titled "Bus Factor In Practice" surveyed 269 engineers and found the bus factor is widely perceived as an important problem in team development, not a theoretical one. A 2024 tool paper, "Knowledge Islands," describes the same shape as areas where knowledge is concentrated in a small number of people, a single point of failure whose departure can make a project hard to continue, and it notes that remote work makes this worse by cutting the informal contact that used to spread knowledge around.

The most useful finding for everyone outside engineering is about where the knowledge forms. The Bus Factor In Practice authors point out that expertise is created and shared in far more places than the code itself, in code reviews, chats, and meetings, so a picture drawn from written artifacts alone undercounts who really holds it. Read that across to an operating team and it lands exactly: your documents show who typed something up, while the person everyone asks holds what was settled in the room. Your files cannot see them.

The costs arrive together, not one at a time

The first cost is paid by the holder. Every question is an interruption, and an interruption does not cost only the minute it takes to answer. It lands in the middle of the focused work that is presumably why you value this person, and getting back into that work takes far longer than the question did. The person who knows the most ends up with the least uninterrupted time, and rarely says so, because answering feels like part of being helpful.

The second cost is the team's ceiling. When the answer to what did we decide lives in one person, everyone else moves at the speed of that person's availability and recall. Work waits for them to be online, out of their own meeting, back from leave. A question that should take ten seconds against a record takes half a day, because the record is a human being who is busy.

The third cost shows up all at once, on the day that person is out. A sick week, a vacation, a resignation, and the questions that used to get answered in a sentence suddenly have no path at all. This is the bus factor made concrete. The team does not degrade gently, because there was never a second route to the answer, only the one that just walked out the door.

More documentation is not the fix people expect

The obvious response is to write everything down. Start a wiki, keep a decision log, ask people to document as they go. Teams try this all the time, and it rarely holds, for reasons that have little to do with willpower.

Documentation written on the side competes with the actual work and loses. A record made after the fact is thinner than the moment it describes, because the specifics have already faded by the time anyone sits down to write. A page written once goes stale the first time a decision changes and nobody updates it. And the thing you most need is the hardest to write ahead of time, since you cannot document the answer to a question no one has asked yet.

So the wiki fills up with whatever was easy to write and misses what people actually come asking for, and the person everyone asks stays the fastest path, which means the wiki keeps losing. Discipline is not the missing ingredient here. A capture step that does not depend on someone remembering to do it is.

What the fix looks like in practice

The goal here is straightforward. Make the answers a helpful colleague holds reachable without having to route every question through the colleague. That means capturing decisions, context, and ownership as the work happens, so a teammate with a question can pull the answer from a shared memory instead of a shoulder tap.

Practically, the record has to form in the flow of the work rather than in a separate documentation chore. What was decided, who owns it, what it depends on, what changed, captured from the meetings and screens where those things actually get settled, without a bot sitting in the call announcing itself. This is where botless capture of work context earns its place. It builds the record from where decisions happen, not from someone's willingness to write a recap later.

When that memory exists and can be searched by meaning, the dynamic shifts. The person who used to be the only source becomes one source among several, and the fast one is now the record. They still field the hard, judgment-heavy questions that genuinely need them. They stop getting interrupted for the tenth what did we decide about X, because anyone can find that in a few seconds. The knowledge stops being a single point of failure, and nobody had to keep a wiki current on the side to get there.

Memory of the work, not monitoring of the person

A system that captures what a team decides sits close to a system that watches what people do, and the difference is the whole point. What you want is a memory of the work, not surveillance of the people doing it. What earns capture is the decision, the owner, and the context that makes a record trustworthy later, scoped to the work and pointed at the people who need to act on it.

That makes control over scope and destination part of the design rather than a setting bolted on afterward. Who can see a given record, where it goes, what gets captured at all. A team adopts this to stop depending on one person's memory, and it should be able to do that without turning the tool into something people feel watched by. Memory that people trust gets used. Memory that feels like monitoring gets worked around, which puts you right back to quietly asking the one person who remembers.

How to tell if a tool actually solves this

If you are weighing something to break the one-person dependency, the real question is whether it removes the reasons people ask a human in the first place. A few things worth checking before you commit:

• Does it capture the answer without anyone remembering to write it up, or does it just give you a nicer place to type notes you still have to write?
• Can someone find a decision by what it was about, in their own words, rather than by knowing the exact title or which doc it landed in?
• Does it keep the context that makes an answer trustworthy later, the why and the owner and what changed, or only a raw transcript?
• Does the person who used to field every question get interrupted less after a month, which is the only outcome that proves it worked?
• Can you control what is captured and who sees it, so adopting it does not feel like surveillance to the team?

A check you can run this week

For one week, notice every time a question routes to your team's designated rememberer. The ask Priya, she will know moments. Keep a rough tally, nothing formal.

Then for each one, ask a plain question: if that person had been on a plane with no signal, could anyone else have gotten the answer, and how long would it have taken? Count how many answers existed nowhere but in one person's memory. That number is your real exposure, and it is usually higher than anyone guessed, because the setup feels like it is working right up until the day it is not.

You do not fix this by asking that person to write more down. You fix it by making the record form as the work happens, so the next time someone needs to know what was decided, the fastest answer is one everybody can reach.