Answering the Same Question for the Fourth Time Is a System Failure

Everyone has three or four of them. Where the staging credentials live. Why the retry logic works the way it does. Whether the customer export is in the March release. Who owns the deployment pipeline. You have answered each of them repeatedly, to different people, in different threads, and you will answer them again this week.

"I already answered this. In a thread. Last week."

It is not the asker's fault

The reflex is mild irritation at the person asking, and it is misplaced. Consider what you are asking them to have done: remember that a question they have never asked before was asked by someone else, in a channel they may not follow, at a time they were not there, and find that specific message among thousands.

Chat search is poor at this even when you know the answer exists. It requires you to guess the words the answer used, which is exactly what you do not know when you do not know the answer. So a new person asking a previously answered question is behaving correctly. They are using the only reliable retrieval mechanism available, which is a colleague.

That reframing matters, because as long as this is understood as a behaviour problem, the interventions will be about politeness and they will not work.

Why this persists for years

Because answering again is genuinely the cheapest option at the moment you are asked. Twenty seconds of typing, and the requester is unblocked immediately. Writing a durable answer takes five minutes, requires deciding where it should live, and helps nobody visible right now.

So every individual instance resolves in favour of answering again, and the aggregate never gets addressed. The cost is spread thinly across a year and concentrated on one person, which makes it invisible to everyone except them, and they experience it as a busy week rather than as a structural problem.

There is a second reinforcing loop. The person who answers most becomes known as the person who knows, which increases the share of questions routed to them, which increases their reputation for knowing. That loop ends either when they leave or when the retrieval problem gets fixed.

Why writing it down is not enough

The standard advice is to write the answer somewhere. It is correct and insufficient, and the reason is worth stating precisely: writing solves storage and does not solve retrieval.

A written answer in a wiki is only useful to someone who thinks to look in the wiki, knows which page, and finds it before giving up. A written answer in a pinned message is useful for about a fortnight. A written answer in a document is useful to whoever remembers the document exists. In each case the person with the question has to know where the answer lives before they can use it, and if they knew that, they would probably know the answer.

This is the gap that leaves teams with both extensive documentation and constant repeated questions, a combination that is extremely common and looks contradictory until you separate storage from retrieval. It is also why internal FAQs go stale.

The eleven-second bar

Sending a colleague a message takes about eleven seconds and nearly always works. Any alternative has to beat that, and almost nothing does.

Asking someone's StandIn does. Each person confirms a ninety-second brief at the end of their day, mostly pre-drafted from the work they already did: current state, open questions, blockers, next actions, decisions made. While they are off, their StandIn answers questions from that brief in their words, with a source under every answer, clearly labelled, and it never guesses. If the answer is not in the record it says so and names who to ask, which means the asker learns in seconds whether they need a human rather than finding out in four hours.

Two consequences. The asker gets the answer during their own working day, which matters most across time zones. And the person who used to answer the same four questions every week gets their attention back while their name still appears on every answer, because it came from what they wrote. See how StandIn works.

Count it for a week

Before changing anything, get the number. For five days, note every question you answer that you have answered before, one line each: the question, who asked, and roughly how long the interruption cost including recovery.

What you find	What it means
Three or more repeats of one question	A queue is forming at you. This is the one to fix first.
Most repeats come from new joiners	An onboarding gap, not a documentation gap
Most repeats come from another time zone	They are also waiting a day for each one
Most repeats are about decisions	The decisions were made and never recorded

The count is the argument. "I answered the same four questions eleven times last week, costing roughly three hours" is a sentence that changes a manager's mind, and "we should document more" is not.

Common Questions

How do I stop answering the same questions repeatedly?

Make the answer retrievable at the moment of the question, faster than messaging you. Storage alone does not do it: a written answer nobody can find at the point of need still produces the same interruption.

Is it rude to point someone at a document instead of answering?

Not if the document actually answers their question, and this is where it usually goes wrong. Being sent to a page that does not contain the answer is worse than being told to ask someone, so check before redirecting.

Should I just answer in public so the next person finds it?

Yes, always answer in the channel rather than a direct message, and do not expect it to prevent repeats. A public answer helps whoever is watching that day and is effectively invisible a fortnight later.

What if the repeated question means something is badly designed?

That is worth checking, and it is a smaller share than people assume. Some repeats do point at confusing systems and should be fixed at the source. Most point at knowledge that exists in one head and is not reachable from anywhere else.