Async Work Gaps: Finding the Decisions Your Team Keeps Re-Asking

Why repeated questions are a better signal than message volume

Message volume is easy to count and easy to misread. A busy channel may be healthy, with people sharing progress and reacting quickly, or it may be a stream of interruptions. Counting messages cannot tell you which is which. Repeated questions can. They point to places where information existed but did not stay accessible, or where ownership was unclear enough that nobody felt entitled to close the loop.

Start by defining a repeated question narrowly. It is a question whose answer has already been given in your team's conversation history, or was reached in a meeting and never written down, and which is raised again by someone who did not see or does not recall the answer. Pricing questions, naming conventions, who approves what, and which customer segment gets priority are typical examples. Broad topics like 'how's the launch going' do not count, because they require fresh information.

A four-week audit method for finding the gaps

Pick a single recent four-week window and export or scroll through the messages your team has sent in your main working channels. You do not need special tooling. A spreadsheet with four columns is enough: date, topic, original answer location if one exists, and whether the question was asked again later in the window. Work through the material in one sitting per week so the pattern stays visible.

When you find a topic that appears more than once, mark whether the second instance happened because the first answer was unfindable, because the answer changed and nobody announced it, or because the person asking was never in the original conversation. Each cause calls for a different fix. Unfindable answers suggest a recordkeeping problem. Changed answers suggest a decision-announcement problem. Missed conversations suggest an access or onboarding problem. Teams often discover that their gaps cluster in one of these three categories, which tells them where to focus.

Writing decisions so they survive the scroll

A decision that exists only inside a thread is fragile. Threads get buried, people leave channels, and search results depend on the words used at the time. A better pattern is to end any settled question with a short, standalone statement: what was decided, the date, who decided it, and the one or two reasons that mattered. This does not need to be long. Three sentences is often enough to prevent a month of rework.

Keep these statements in one predictable place your team agrees on. It might be a pinned note, a shared document, or a simple running list. The location matters less than the consistency. If people have to guess where decisions live, they will ask the question again instead of looking. Revisit the list at the start of each week to remove anything that has been superseded, and mark superseded items rather than deleting them so the reasoning trail remains.

Async handoffs that stop the re-asking loop

Many repeated questions happen at handoffs, when one person finishes part of a task and another person picks it up across a time zone gap. The receiving person lacks context and asks, and the sender, now offline, cannot answer quickly. A handoff note that states what is done, what is not done, what decisions were made along the way, and what the next person should not redo prevents most of these loops.

Test your handoffs by asking the receiving person afterward which questions they had to ask anyway. If the list is short and specific, the handoff is working. If it is long, the gap is probably in unstated assumptions, which are the hardest context to transfer and the most common source of re-asking.

A checklist for your next review

Before concluding your audit, answer these questions in writing. How many distinct topics were repeated in the window, and what share of total messages do they represent? Which of the three causes, unfindable answers, changed answers, or missed conversations, accounts for most repeats? For the top three repeated topics, does a standalone decision statement exist, and where? Who on the team is responsible for keeping the decision list current, and has that person agreed to it? Which handoffs in the period generated follow-up questions, and what was missing from each note?

Once you have answers, pick one change to test for two weeks rather than rebuilding everything at once. A single enforced habit, such as ending every settled thread with a decision statement, is easier to evaluate than a full process overhaul. At the end of the two weeks, repeat the audit on a new window and compare the repeated-topic count. If it has dropped, keep the change. If it has not, examine which cause still dominates and adjust.

Whatever tool your team uses, the same questions apply. Ask where decisions are recorded, who can find them, how superseded answers are marked, and whether new members can recover context without asking a person. These questions reveal far more about a team's async health than any feature list.