Why Your Team Keeps Answering the Same Questions

Your team keeps answering the same questions at work because answers are delivered into conversations rather than into a durable record. A reply in chat resolves one person's confusion for one moment. The next person who has the same question, especially in another timezone, cannot find that reply, so they ask again and someone answers again.

Why the same question keeps coming back

Repeated questions are a symptom of a missing record, not a symptom of people not paying attention. When the resolved answer to "why is the staging deploy frozen?" exists only as a message buried in a thread from three days ago, it is effectively invisible to anyone who was not in that thread at that time. The information existed; it just was not retrievable.

Distributed teams amplify this brutally. A co-located team might absorb a repeated question through proximity and overheard answers. A team spread across timezones has no overhearing. Each shift encounters the same gaps fresh, and the same questions cycle endlessly. This is one of the core components of the coordination tax distributed teams pay every day.

The chat-as-memory trap

Chat tools feel like memory because the history is technically there. But chat optimizes for the present conversation, not for future retrieval. Search returns dozens of partial matches, answers are tangled in debate, and you often cannot tell which message holds the final resolved answer versus an early wrong guess. The medium records the discussion but not the conclusion.

Dimension	Answer in chat	Answer in a record
Audience	Whoever is in the thread now	Anyone who asks later
Findability	Buried, low-signal search	Queryable, resolved state
Finality	Mixed with guesses and debate	Single declared answer
Lifespan	Effectively expires in days	Persists and stays current

Who actually pays for it

The cost concentrates on your most knowledgeable people. The engineer who understands the deploy pipeline, the ops lead who knows the vendor history, the PM who remembers why a feature was cut: these people become human lookup tables. Every repeated question is an interruption that pulls them out of deep work, and the interruptions arrive around the clock as different timezones come online.

There is a quieter cost too. Newcomers and people in less-overlapping timezones get worse, slower answers because they are reluctant to interrupt or because the expert is asleep. The team's effective knowledge becomes a function of who is awake, which is exactly the dependency distributed work was supposed to break. It also erodes accountability, a theme explored in decision accountability on distributed teams.

Answer once, read many

The structural fix is to change where answers land. When a question is answered into a durable, queryable record rather than a thread, the question is resolved once and read by everyone who needs it afterward. The London engineer answers "why is staging frozen?" into the record at 5pm, and the New York engineer reads it at 9am without anyone being interrupted.

This is the role of a system of record for decisions: it holds declared state that can be queried directly. The principle of silence over speculation matters here. The record answers only from what was actually declared, so a reader gets the real resolved answer or an honest "not yet decided," never a confident guess that sends them down the wrong path. To stop the cycle at the handoff itself, see async handoffs that actually work.

Common Questions

Won't a wiki solve the repeated-questions problem?

A wiki helps for stable reference material but decays fast for operational state, because it is updated manually and separately from the work. The answers people re-ask about are usually current decisions and statuses, which a static wiki rarely keeps fresh. A record fed at the moment of decision stays current.

Why do people re-ask even when the answer exists somewhere?

Because the cost of searching feels higher than the cost of asking. If finding the answer means scrolling threads with no guarantee of success, asking a person is rational. Make the answer trivially findable and queryable, and the re-asking stops on its own.

How is this different from just writing better documentation?

Documentation describes how things generally work. The repeated questions are usually about specific current state and decisions. The fix is to capture declared state as it happens, tied to owners and decisions, not to write more general docs after the fact.

What should happen when the record has no answer?

It should say so plainly. Silence over speculation means an absent answer returns "not declared" rather than a guess. That honesty is what makes the record trustworthy enough that people stop double-checking with a human.