Back to blog
Distributed Teams

How to Stop Answering the Same Question Twice

6 min read
stop answering the same question twicerepeated questions at workcanonical answerdeclared knowledgedistributed teams

The short version

  • To stop answering the same question twice, capture the answer once in a durable place and point everyone at it instead of re-typing it.
  • Track which questions recur, write a canonical answer with an owner and a date, and make that answer the first thing people find.
  • Route repeat questions to a representative that answers from your declared knowledge, so you are not the human lookup table.
  • When something has not been decided, say so explicitly. A clear "not decided yet" stops the question from bouncing around.

To stop answering the same question twice, write the answer down once in a place people can find, give it an owner and a date, and then send the link instead of retyping the reply. The repetition is not a personality flaw or a discipline problem. It is a routing problem: the answer lives in your head or buried in a thread, so the only path to it runs through you.

Most teams try to fix this with more documentation and end up worse off, because they document everything and canonicalize nothing. The goal is not a bigger wiki. It is a single trusted answer per recurring question, kept current, that beats every stale copy to the reader. This is the same pattern behind answering the same questions at work and the operational tactics in our guide to reduce repeated questions at work. Here we get specific about the mechanics.

The four steps to answer once

There is a repeatable loop that takes a question from "I keep getting asked this" to "nobody needs to ask me anymore." Run it in order.

  • Notice the repeat: the moment you answer something for the second time, flag it. The second time is the signal, not the tenth.
  • Write it once: capture the answer in a durable, findable location, not in a reply to one person.
  • Attach ownership: put a name and a date on the answer so readers know it is current and who to challenge if it is wrong.
  • Redirect the traffic: next time it is asked, send the link. If the question is coming through chat, let a representative answer it from the declared source.

The discipline that makes this work is answering the second occurrence differently from the first. The first time, you just answer. The second time, you answer and you canonicalize.

Find which questions actually repeat

Do not guess. The questions that feel annoying are not always the ones that cost the most. Spend a week noting every question that lands on you more than once, then sort by frequency and by how much context each answer requires. High-frequency, high-context questions are where you win the most time back.

Question type Best fix Why
Factual and stable ("what port does X use")Canonical doc entryThe answer rarely changes, so a static page is enough.
Decision-based ("did we decide to sunset Y")Decision recordPeople need the what, who, and why, not just the outcome.
Status-based ("is the migration done")Declared statusThe answer changes over time and must show its date.
Undecided ("which vendor are we picking")Explicit "not decided"Silence invites the question again; a clear no ends it.

Notice that decision-based and undecided questions are the ones plain documentation handles worst. A wiki tells you a fact; it rarely tells you what was decided, by whom, and under what authority. That gap is why the same "did we ever decide..." question keeps coming back.

Write a canonical answer that holds up

A canonical answer is not just correct today. It is legible enough that a reader trusts it without pinging you to confirm. Three properties make the difference.

  • It is dated: a reader can see when it was last confirmed and judge whether it is still current.
  • It is owned: a name is attached, so there is a clear person to challenge if reality has moved.
  • It is declared, not inferred: it states what was actually decided rather than what someone guessed from activity. This declared versus indexed distinction is the difference between an answer people trust and one they double-check.

The failure mode is a doc that is technically accurate but undated and unowned. Readers cannot tell if it is live or a fossil, so they ping you anyway, and you are back to answering by hand. Ownership and dates are what let the written answer replace you instead of merely supplementing you.

Route repeats away from your inbox

Writing the answer once only helps if people hit the answer before they hit you. That is a routing job. The strongest version puts a representative in front of the question: teammates ask in plain language, and it answers from what your team has explicitly declared, with a link back to the source.

The important property is that it does not make things up. When there is no declared answer, it says so rather than inventing one, which is the silence over speculation principle. A confident wrong answer would cost you more than the original repeat question. StandIn works this way: it answers only from declared decisions and status, and a "this has not been decided" is treated as useful information, not a failure. That is also how refusal becomes a signal instead of a dead end.

Set this up once and the loop closes. Recurring questions land on the declared answer, genuinely new questions still reach a human, and you stop being the lookup table for things everyone already agreed on.

Common Questions

Why do I keep getting asked the same question at work?

Because the answer only exists in your head or in a thread that is hard to search, so you are the shortest path to it. Move the answer into a durable, findable place with an owner and a date, and the question stops routing through you.

Is a wiki enough to stop repeat questions?

For stable facts, yes. For decisions and status it usually is not, because a wiki tells you a fact but rarely tells you what was decided, by whom, and whether it is still current. Decision records and dated status entries close that gap.

What do I do with questions that have not been answered yet?

Declare them undecided explicitly. A visible "not decided yet, owner is Priya, revisit next sprint" ends the question far better than silence, which just invites someone to ask again next week.

Can an AI answer repeat questions for me?

Yes, if it answers only from what your team has actually written down and refuses to guess when there is no declared answer. That constraint is what keeps it trustworthy. StandIn answers from declared decisions and status and stays silent rather than speculating.

Get async handoff insights in your inbox

One email per week. No spam. Unsubscribe anytime.

Ready to retire your daily standup?

Distributed teams use StandIn to start every shift with full context, no standup required. Engineers publish a 60-second brief. The next shift wakes up knowing exactly what to work on.

You might also like